Design Pattern | Factory Method

  • Montag, 07. März 2016 19:30
Artikel bewerten
(0 Stimmen)

Das Factory Method Entwurfsmuster dient der Entkopplung des Clients von der konkreten Instanziierung einer Klasse. Das erstellte Objekt kann elegant ausgetauscht werden. Oft wird es zur Trennung von (zentraler) Objektverarbeitung und (individueller) Objektherstellung verwendet. Das Factory Method Design Pattern kann der Kategorie: "Creational Patterns" zugeordnet werden. Factory-Methoden sind statische Methoden zur Erzeugung von Objekten des eigenen Klassentyps. Ein Singleton kann zum Beispiel als Spezialfall einer Klasse mit einer Factory-Methode angesehen werden.

Der Erstellungscode eines Objektes (Product genannt) wird in einer eigenen Klasse (Creator, Factory) ausgelagert. Dieser Creator ist abstrakt und delegiert die konkrete Objektinstanziierung wiederrum an seiner Unterklasse. Erst die Unterklasse entscheidet welches Product erstellt wird. Da der Client sich komplett auf Abstraktion stützt (sowohl beim Creator als auch bei den Products), ist er vollkommen von den Implementierungen entkoppelt und unabhängig.

Der Creator ist abstrakt, und kennt nur die abstrakte Schnittstelle vom Product und instanziiert nicht ein konkretes Productobjekt, sondern lässt seine Unterklassen entscheiden, welches konkrete Product erzeugt werden soll. Dazu definiert es eine abstrakte Methode (die namensgebende factoryMethod()), die es in seiner createProduct()-Methode aufruft und die seine Unterklassen implementieren müssen. Unterklassen (ConcreateCreators) implementieren diese Methode und geben ein ConcreteProduct zurück.

Nachdem die Unterklasse des Creators das konkrete Product an den Creator zurückgegeben hat, kann der Creator noch allgemeinen Herstellungscode enthalten, die auf jedes Product angewandt werden muss, bevor es an den Client geliefert wird.

UML:

a) Klassendiagramm:

b) Sequenzdiagramm: 

 

 

Anwendungsfälle:

  • Trennung der Objektverarbeitung (Wie?) von der konkreten Objekterstellung (Instanziierung; Was?). Delegation der Objektinstanziierung an Unterklasse.
    • Authentifizierungssysteme. Für jeden User wird nach dem Login ein Ticket erstellt, das seine Rechte im System repräsentiert. Statt eine universelle Ticketklasse mit duzenden, je nach Userrechten gesetzten Attributen zu nutzen, werden spezielle Tickets erstellt. Dies geschieht mittels einer TicketFactory und einer createTicket()-Methode, die mit den nötigen Informationen parametrisiert wird. Anhand dieser Parameter wird entschieden, welches Ticket erstellt wird. Verschiedene Erzeugungsprozesse werden durch mehrfaches Ableiten dieser Factory ermöglicht (InternetTicketFactory, IntranetTicketFactory). ([PK], Seite 27f.)
  • Fälle, in denen mit einer wachsenden Anzahl und Ausformung von Produkten zu rechnen ist. Sowie Szenarien in denen alle Produkte einen allgemeinen Herstellungsprozess durchlaufen müssen, egal was für ein Produkt sie konkret sind.
    • Eine Pizzeria erstellt je nach Parameter verschiedene Pizzen (Salami, Hawaii, Calzone, Quattro Stagioni), die immer gleich zubereitet werden (backen, schneiden, einpacken). Um den regionalen Wünschen der Menschen in Berlin, Hamburg und Rostock zu genügen, müssen spezielle Pizzen für eben diese Städte erstellt werden. Diese Erstellung geschieht in den speziellen Unterklassen der Pizzeria (BerlinPizzeria, HamburgPizzeria, RostockPizzeria), die die speziellen Pizzen erstellen (BerlinSalami, RostockCalzone etc.). Die Verarbeitung ist in allen Fällen gleich und erfolgt in der abstrakten Pizzeriaklasse, die nur die abstrahierte Pizzaschnittstelle kennt. Schnell können somit neue Pizzasorten und Pizzerias ins System integriert werden. ([VKBF], Seite 118ff.)
  • Wenn die konkret zu erstellenden Produkte nicht bekannt sind oder nicht von vorne herein festgelegt werden sollen.
    • Frameworks und Klassenbibliotheken.

Vorteile:

  • Herstellungsprozess ist von einer konkreten Implementierung getrennt und unterschiedliche Produktimplementierungen können denselben Produktionsvorgang durchlaufen.
  • Wiederverwendbarkeit und Konsistenz durch
    • Kapselung des Objekterstellungscodes in eigener Klasse. Dadurch entsteht eine einheitliche und zentrale Schnittstelle für den Client. Die Produktimplementierung ist von seiner Verwendung entkoppelt. Außerdem entsteht ein zentraler Punkt der Wartung (geringerer Änderungsaufwand).
    • Kapselung des allgemeinen Herstellungscodes in die Superklasse Creator, die auf jedem Produkt vor Auslieferung an den Client durchgeführt wird.
  • Erweiterbarkeit, Austauschbarkeit und Flexibilität durch problemlose Einführung neuer Products und ConcreteCreators (bzw. Modifizierung oder Auswechseln bestehender) ohne Brechen des Clientcodes, dank konsistenter Schnittstelle. So kann ein neuer ConcreteCreator in das System integriert werden und dabei bestehenden Creatorcode wiederverwenden ohne Änderungen am bestehenden Client nötig zu machen.

Nachteile:

  • Enge Kopplung eines konkreten Creators an ein konkretes Produkt. Für jedes neue Produkt muss ein neuer ConcreteCreator geschrieben werden und den abstrakte Creator ableiten. Unser Gesamtsystem hat damit nur wegen der Fabrikmethode einen weiteren Evolutionsast. Bei der parametrisierten Variante des Patterns ist dies weniger problematisch, da oft nur ein bestehender konkreter Creator angepasst werden muss.

Fazit:

Letzte Änderung am Dienstag, 12 April 2016 22:36
Kommentare einblenden

Copyright © 2017 ABAP-Workbench.de