Das hat mich eine Weile gestört, und ich habe keine Hinweise, ob das ein Mythos ist.
Es scheint so zu sein, dass ein Factory-Muster den Schmerz beim Hinzufügen einer Abhängigkeit für eine Klasse lindern kann.
Zum Beispiel hat es in einem Buch so etwas wie
Angenommen, Sie haben eine Klasse namens Order. Anfangs war es von nichts abhängig. Deshalb haben Sie sich nicht die Mühe gemacht, eine Factory zu verwenden, um Order-Objekte zu erstellen, und Sie haben einfach nur Neu verwendet, um die Objekte zu instanziieren. Sie haben jetzt jedoch eine Anforderung, dass der Auftrag in Verbindung mit einem Kunden erstellt werden muss. Es gibt Millionen Stellen, die Sie ändern müssen, um diesen zusätzlichen Parameter hinzuzufügen. Wenn Sie nur eine Fabrik für die Ordensklasse definiert hätten, hätten Sie die neue Anforderung ohne den gleichen Schmerz erfüllt.
Wie ist das nicht der gleiche Schmerz wie das Hinzufügen eines zusätzlichen Parameters zum Konstruktor? Ich meine, du würdest immer noch ein zusätzliches Argument für die Fabrik geben müssen, und das wird auch von Millionen Orten benutzt, oder?
Wenn der Benutzer nur zu der Zeit bekannt ist, zu der der Auftrag erstellt wurde, können Sie eine getCurrentUser() -Funktion implementieren, die von der Factory aufgerufen wird.
Wenn das möglich ist, gewinnt offensichtlich die Fabrikfunktion. Wenn nicht, dann gibt es keinen Gewinn.
Wenn Sie in der Vergangenheit nicht gewusst haben, dass ein Kunde benötigt wird, wissen Sie wahrscheinlich auch nicht, ob es möglich ist, eine getCurrentUser() -Funktion zu implementieren. Die Chancen, dass sich die Fabrikmethode auszahlt, sind möglicherweise nicht sehr gut, aber sie sind nicht immer gleich 0.
Der wahre Vorteil einer Factory besteht darin, dass sie eine Fassade ist, die genau verbirgt, wie Sie ein Objekt erstellen, das die Order-Rolle erfüllt. Genauer gesagt weiß die Factory, dass du wirklich einen FooBarOrder erstellst, und nichts anderes muss geändert werden, um von einem FooBarOrder zu einem BarFooOrder zu wechseln. (Wenn Java es erlaubt, new abzufangen und stattdessen eine Unterklasse zu erstellen, gäbe es keine Fabriken. Aber es ist nicht - ziemlich vernünftig, fair zu sein -, also müssen Sie sie haben. Objektsysteme, die es ermöglichen, die Klasse zu untergliedern Klassen sind in dieser Hinsicht flexibler.)
Nein, weil die Abhängigkeit für die Factory über den Factory-Konstruktor eingegeben werden soll. Sie erstellen die Factory nur an einem Ort, aber übergeben sie als die Abhängigkeit an alles, was zur Erstellung eines Auftrags benötigt wird. Die Dinge, die Befehle von der Fabrik erhalten, rufen immer noch dieselbe Methode, CreateOrder () oder was auch immer, auf, so dass der Code unverändert ist.
Die Abhängigkeiten sollten alle an einem Ort verdrahtet sein, die Kompositionswurzel , und das sollte der einzige Ort sein, der geändert werden muss, um die neue Abhängigkeit zur Factory hinzuzufügen
Das Fabrikmuster kann den Schmerz beim Hinzufügen einer Abhängigkeit lindern, weil es sich um eine Fabrik handelt contain state und kann tatsächlich mehrere Abhängigkeiten kapseln (z. B. anstatt drei Abhängigkeiten bereitzustellen, die alle zum Aufrufen des Konstruktors eines Objekts benötigt werden), stellen Sie jetzt nur ein einzelnes Factory-Objekt bereit, wobei die Factory diese drei benötigten Objekte enthält dem Konstruktor zur Verfügung gestellt werden).
Um ein Beispiel zu geben, vergleiche:
%Vor%Und:
%Vor% Beachten Sie, dass die zweite Version weniger Abhängigkeiten zur Methode "DoIt" benötigt. Dies bedeutet nicht, dass diese Abhängigkeiten nicht im gesamten Programm benötigt werden (tatsächlich verwendet das Programm weiterhin DependencyA und DependencyB in der Implementierung der Factory). Durch die Strukturierung dieser Abhängigkeit kann diese Abhängigkeit jedoch nur auf den Factory-Code isoliert werden, was anderen Code einfacher macht und es einfacher macht, die Abhängigkeiten von DependencyC zu ändern (jetzt muss nur die Factory selbst aktualisiert werden) Jeder Ort, der DependencyC instanziiert, und kann sogar bestimmte Sicherheitsvorteile haben (z. B. wenn DependencyA und DependencyB sensibel sind, wie Datenbankkennwörter oder API-Schlüssel), verringert die Verwendung der Fabrik die Wahrscheinlichkeit falscher Handhabung. im Vergleich zu Fällen, in denen Sie diese überall hin weitergeben, wo Sie beispielsweise die Datenbank oder die API verwenden müssen.)
In dem Beispiel, das in dem Buch gegeben wurde, wäre der Grund, warum eine Fabrik für die Order geholfen hätte, darin zu sehen, dass es die Anzahl der Stellen verringert hätte, an denen der Konstruktor direkt verwendet wird; nur der eine Ort, der die Fabrik geschaffen hat, müsste modifiziert werden, um Customer als zusätzliches Feld der Fabrik zu speichern; Keine der anderen Nutzungen der Fabrik müsste geändert werden. Im Vergleich dazu gibt es direkte Verwendung des Konstruktors ohne die Verwendung der Factory, und jeder von ihnen muss aktualisiert werden, um irgendwie Zugriff auf das Customer -Objekt zu erhalten.
Tags und Links factory-pattern