✔ Factory Klassen

[dg87]

@saftmeister: das ist ein wahnsinnig guter Tipp dieser Spruch. Vielen dank.
Ja da habt ihr recht ich les das halt weil ich einfach mal sehen will was es gibt, aber ich glaube ich verkrampf mich da zu fest. Ich werde jetzt auch mal kleinere Projekte umsetzen, aber ich denke es ist gut wenn man einfach schon ein paar Muster kennt
BTW ich hab's jetzt verstanden - danke euch

Eine letzte Frage noch: was heist gegen Schnittstellen und nicht gegen implementierungen zu programmieren? Ich versteh da immer gegen Interface zu programmieren und eben keine direkte kopplungen der einzelnen Klassen zuzulassen?

Also vielen dank nochmal

Edit:
Das grundlegende kann ich ja aber ich dachte das Buch zeigt mir praxisnahe Beispiele für OOP. Und es hat mir auch schon sehr geholfen! Ich will einfach ma die Möglichkeiten von OOP sehen deshalb das Buch.

 

[saftmeister]

Achja und zu guter letzt steht da noch es fördert die Programmierung gegen Schnittstellen ...

Das ist definitiv richtig, denn wie ich schon geschrieben habe, ist es durch die Verwendung des Interfaces "Database_Interface" dann völlig egal, welche konkrete Datenbank sich dann hinter der Schnittstelle befindet.

Schnittstellen sind wichtige Aspekte der objekt-orientierten Programmierung. Denn dadurch wird die Implementierung einer Bibliothek (oder eines Rahmenwerks [Framework]) unwichtig für die eigene Implementierung.

Ein weiteres Beispiel wäre:

Ausgabe des Webseiten-Inhalts als

- HTML (originär über den Browser)
- RDF (News-Reader) => XML
- Email
- PDF
- sonstige denkbare Ausgabe-Methoden

Da kommt dann der User und sagt: "Och, coole Info, die hätte ich jetzt gern als druckbares Medium" > Inhalt wird statt als HTML als PDF ausgegeben. Die Fabrik wäre hier "InhaltDarsteller", welche eine Schnittstelle "Medium" und eine konkrete Klasse wäre "HTMLWebsite" oder auch eine weitere "PDFRenderer". Dich als Entwickler interessant nur noch "Medium", was du bekommst, wenn du die Fabrik anrufst und sagst "User hätte gerne $AusgabeMedium" und bekommst <versteckt> dann eben entweder "HTMLWebsite" oder auch "PDFRenderer" geliefert. Diese beiden Klassen bieten dann eine Methode "jetztDarstellen" an, in der das konkrete dann erledigt wird.

Ich hoffe, das war jetzt nicht zu kompliziert.

 

[saftmeister]

was heist gegen Schnittstellen und nicht gegen implementierungen zu programmieren? Ich versteh da immer gegen Interface zu programmieren und eben keine direkte kopplungen der einzelnen Klassen zuzulassen?

Genau dein zweiter Satz beschreibt es recht treffend. Eine Schnittstelle verbirgt die Implementierung dahinter. Das hat den enormen Vorteil, das du die Implementierung hinter der Schnittstelle gegen irgendwas anderes austauschen kannst, was auch diese Schnittstellen implementiert - nehmen wir hier ruhig mal das wort "kennt".

Ich kenne folgende Methoden

- Lernen
- Programmieren
- Autofahren
- Musik hören

einfach nur crack kennt

- Lernen
- Programmieren
- Fahradfahren
- Schwimmen

Eine Schnittstelle "Programmierer" hat die Methoden

- Lernen
- Programmieren

Wir als Personen erfüllen also beide diese Schnittstelle.

Du willst eine Person, die die Schnittstelle "Programmierer" unterstützt. Folglich ist es für dich egal, ob die "Implementierung" hinter der Schnittstelle "saftmeister" oder "einfach nur crack" ist.

Ich denke mal, ich habe grade die abstrakteste Art und Weise genommen, das Konzept zu erklären...

 

[bn]

Eventuell hilft dir ja folgendes Bespiel weiter (auch wenn es nur bereits Geschriebenes untermalt):

Angenommen deine Firma betreibt eine Software, mittels welcher fakturiert wird. Zu diesem Zweck hast du sauber objektorientiert eine Abrechnung implementiert. Nun tritt der Zustand ein, dass dein Cheff das Abrechnungsmodell grundlegend geändert haben möchte (kommt nicht selten vor^^).

Du stehst vor der Aufgabe, dass du
a) die bisher gültige Fakturierung nicht einfach "wegschmeißen" kannst, da z.B. mit Stornos zu rechnen ist und das alte Abrechnungsmodell für derartige Vorgänge weiterhin greifen muss und
b) das neue Abrechnungsmodell zu einem festen Stichtag (z.B. ab 2011-09-01) greifen soll.

Hier bietet sich eine Factory an - und zwar überlässt du der Factory, ob sie dir die Instanz der bisher gültigen Fakturierung oder eben der zukünftigen Fakturierung zurück gibt. Zu diesem Zweck übergibst du der Factory z.B. den Beginn des Leistungszeitraumes der Abrechnung.

beispielhaft angedeutete Factory:

class FacturaFactory
{
   public static function getInstance ($date)
   {
      if ($date >= '2011-09-01')
      {
          return new FakturaNeu ();
      }
      
      return new FakturaAlt ();
   }
}

$Faktura = FakturaFactory::getInstance ($date);

Damit dabei kein Gewusel entsteht, sollten beiden Faktura-Klassen von einer abstrakten Klasse erben (z.B. FakturaNeu extends FakturaAbstract), welche die grundlegende Implementierung manifestiert. Alternativ lohnt sich hier ein Blick auf Interfaces ;-).

beispielhaft angedeutete abstrakte Klasse:

abstract class FakturaAbstract
{
   abstract public function createBill ();
   abstract public function cancelBill ($bill_id);
   // u.s.w.
}

Damit wäre dann sicher gestellt, dass beide Faktura-Klassen auf die gleiche Art und Weise eingesetzt werden können:

// Erstellen einer Rechnung
$Faktura->createBill ();
// Stornieren einer Rechnung
$Faktura->cancelBill ($bill_id);

Hoffentlich hilft dir diese Beispiel weiter ;-)

Grüße BN

 

[dg87]

So hatte gerade Zeit mir das alles durchzulesen.
Erstmal muss ich hier nochmal ganz deutlich sagen, dass man bei euch super aufgehoben ist. Vielen Vielen Dank.
In diesen einzigen Thread, hab ich jetzt so viel gelernt.
Ich habs verstanden - Vielen Dank.
Was mir aber am meisten hängen geblieben ist und was ich total genial find ist der Satz: OOP entsteht nicht im Code, sondern im Kopf des Entwicklers.
Aber die letzten Beispiele von euch, haben es mir nochmal richtig gegeben - hihi
Man ihr seid super.
Danke