Objektorientierte Entwurfsmuster - Architektur und Entwurfsmuster der Softwaretechnik - page 249

produkt.print();
}
}

Hier das Protokoll des Programmlaufs:

Hallo
x = A
x = B

Bei diesem Client handelt es sich, wie der Name schon sagt, um einen Test. Bei einer
"richtigen" Anwendung wäre es eher untypisch, dass sie sich ihre Erzeuger nach
Belieben selbst erzeugt. Die Anwendung sollte ja gerade in der Erzeugung von Pro-
dukten flexibel bleiben. In der Regel besitzt ein Client nur eine Referenz vom Typ der
abstrakten Erzeuger-Klasse. Das Muster lässt offen, wie diese Referenz so gesetzt
werden kann, dass sie auf ein Objekt einer konkreten Erzeuger-Klasse zeigt. Hier kann
beispielsweise die Technik der Dependency Injection (siehe Kapitel 1.10.2) einge-
setzt werden.

4.18.4 Bewertung

4.18.4.1 Vorteile

Folgende Vorteile werden gesehen:

x Eine Klasse muss die Klassen der Objekte, die sie erzeugen muss, nicht von vorn-
herein kennen. Transparent für das Programm können durch Austausch der unab-
hängigen konkreten Erzeuger andere konkrete Produkte erzeugt werden, d. h., es
können verschiedenartige konkrete Produkte generiert werden. Eine explizite Erzeu-
gung der konkreten Produkte ist nicht in der Anwendung enthalten. Der Einsatz von
Fabrikmethoden ist damit flexibler als explizite Erzeugungsanweisungen.
x Sollen die Basisklassen nicht nur abstrakte Methoden enthalten, kann man in der
Basisklasse Erzeuger eine Default-Erzeugung definieren. Dadurch sind die Unter-
klassen frei, ob sie eine eigene überschreibende Fabrikmethode bereitstellen oder
nicht.
x Durch die Verwendung von Schnittstellen (Interfaces bzw. abstrakte Klassen) für
Produkte kann das Einbinden von "falschen" anwendungsspezifischen Klassen ver-
hindert werden.
x Basierend auf den Schnittstellen (Interfaces bzw. abstrakten Klassen) für Produkte
kann ein Framework bzw. eine Klassenbibliothek entwickelt werden, welches bzw.
welche Produkte bearbeitet, auch wenn noch gar keine konkreten Produktklassen
vorhanden sind. Eine Anwendung des Frameworks kann dann konkrete Produkte,
die die abstrakten Schnittstellen implementieren, in eigenen spezifischen Unter-
klassen erzeugen, ohne Operationen der Oberklassen des Frameworks abändern
zu müssen (Dependency Inversion). Ein solches Framework ist also unabhängig
von der Ausprägung der konkreten Produkte.