In diesem Artikel wird erläutert, wie abgeleitete Klassen ihre Konstruktoren verwenden können, um geeignete Objekte zu erstellen.

Was ist es?

Eine Softwarefabrik erstellt Objekte, und eine Fabrik, die reale Güter produziert, produziert Güter. Das Erstellen von Objekten in Java geschieht beispielsweise normalerweise wie folgt:

Das Problem bei diesem Ansatz besteht darin, dass der Code, der das SomeClass- Objekt verwendet, plötzlich von der konkreten Implementierung von SomeClass abhängig wird . Es ist nichts falsch daran, neue Objekte zu erstellen, aber dieser Ansatz kann dazu führen, dass unser Code eng an die konkrete Implementierungsklasse gekoppelt wird. Dies verstößt gegen Code-to-an-interface und not-to-an-implementation.

Die Factory-Methode ist ein Klassenentwurfsmuster, das eine Schnittstelle zum Erstellen von Objekten bereitstellt, aber Unterklassen entscheiden lässt, welche Klasse instanziiert werden soll.

Klassen Diagramm

Das Klassendiagramm enthält die folgenden Elemente:

• Produkt
• Konkretes Produkt
• Schöpfer
• Konkreter Schöpfer

Um mit unserem Flugzeugbeispiel fortzufahren, nehmen wir an, wir versuchen, den Kampfjet F-16 zu modellieren. Der Client-Code muss ein Triebwerksobjekt für dieses Flugzeug konstruieren und es fliegen. Eine naive Implementierung für diese Klasse wäre etwa die folgende:

Im obigen Code haben wir uns verpflichtet, eine konkrete Implementierung der F16-Klasse zu verwenden. Was ist, wenn das Unternehmen mit neueren Versionen des Flugzeugs aufwartet und wir diese in unserem Programm vertreten müssen? Das würde bedeuten, den Client-Code zu ändern, in dem wir eine F16-Instanz erstellen. Ein Ausweg besteht darin, die Objekterstellung in einem anderen Objekt einzukapseln, das ausschließlich für die Erstellung angeforderter Varianten des F-16 verantwortlich ist. Nehmen wir für den Anfang an, wir wollen die A- und B-Varianten von F16 darstellen; Unser Code könnte so aussehen:

Eine einfache Fabrik ist eine einfache Programmiersprache, die kein Fabrikobjekt erstellt. Die make-Methode kann statisch gemacht werden, um zu vermeiden, dass ein unnötiges Objekt erstellt wird. Da jedoch statische Methoden in Unterklassen nicht überschrieben werden können, können wir diese Simple Factory nicht als Grundlage für eine abstrakte Klassenhierarchie verwenden.

Wir möchten jedoch die Erstellung von F16-Objektteilen innerhalb derselben Klasse halten und dennoch in der Lage sein, neue F16-Varianten einzuführen, sobald sie auftauchen. In diesem Fall könnten wir F16 unterklassen und die Erstellung des richtigen F16-Variantenobjekts an die Unterklasse delegieren, die diese Variante behandelt. Genau so funktioniert das Muster der Fabrikmethode! Die Fabrikmethode hier ist makeF16(), die eine neue F16-Variante erstellt, wenn sie aufgerufen wird. Im Folgenden führen wir zwei Unterklassen wie folgt ein

Wir haben das Engine-Objekt mithilfe von Vererbung in Unterklassen unterteilt und spezialisiert. Eine Factory-Methode kann eine standardmäßige oder generische Implementierung bereitstellen oder auch nicht; Wir können es jedoch immer noch in Unterklassen überschreiben, um das Produkt zu spezialisieren oder zu modifizieren. Unser Beispiel hat zwei Variantenmodelle, jedes mit einem anderen Motor, aber dem gleichen Cockpit. Client-Code kann jetzt die neueren Modelle wie folgt verwenden:

Beachten Sie, dass das Factory-Methodenentwurfsmuster einen abstrakten Typ zurückgibt, entweder eine Java-Schnittstelle oder eine abstrakte Java-Klasse. Die Oberklasse, in unserem Fall F16, weiß nicht, welche Art von F16 sie von der Methode makeF16() zurückgegeben wurde. Im Allgemeinen ist eine create-Methode entweder abstrakt oder wird mit einer Standardimplementierung geliefert, die von den anderen Methoden der Oberklasse aufgerufen wird. Es liegt also an Unterklassen, bestimmte Arten von Objekten zu erstellen.

Unterschiede zu Simple/Static Factory

Das Factory-Methodenmuster ähnelt der einfachen oder statischen Factory, zu den Unterschieden gehört jedoch, dass einfache Fabriken keine unterschiedlichen Produkte durch Vererbung produzieren können, wie dies bei einem Factory-Methodenmuster der Fall ist.

Andere Beispiele

Das Factory-Methodenmuster ist in Toolkits und Frameworks allgegenwärtig. Das Muster kann immer dann verwendet werden, wenn eine Klasse nicht im Voraus weiß, welche Unterklassenobjekte sie instanziieren müsste. Dies geschieht häufig beim Framework-Design, bei dem von den Verbrauchern des Frameworks erwartet wird, dass sie vom Framework bereitgestellte abstrakte Klassen und Hook-In-Funktionen oder Objekterstellungen erweitern.

Die Java-API stellt mehrere Factory-Methoden zur Verfügung:

java.util.Calendar.getInstance()

java.util.ResourceBundle.getBundle()

java.text.NumberFormat.getInstance()

Vorbehalte

• Das Muster kann dazu führen, dass zu viele Unterklassen mit nur geringfügigen Unterschieden zwischen ihnen vorhanden sind.
• Wenn eine Unterklasse einer Oberklasse Funktionalität hinzufügt, kann sie die neuen Methoden nicht verwenden, es sei denn, sie wandelt das Objekt in seinen konkreten Typ um. Leider kann Downcasting zur Laufzeit fehlschlagen.

• Schöpfungsmuster: Singleton
• Schöpfungsmuster: Prototyp
• Schöpfungsmuster: Erbauer
• Schöpfungsmuster: Abstrakte Fabrik