Das Singleton- und das Registry-Muster waren sehr einfach und leicht für mich, um es sofort zu verstehen, aber das Factory-Muster war etwas, das ich noch nicht in der Lage war, mein Gehirn zu 100% zu interpretieren. Ich denke, ich könnte es jetzt verstehen, ich habe unten einen Beispielcode geschrieben, bitte überprüfen Sie und sagen Sie mir, ob dies die richtige Verwendung des Factory-Patterns ist. Beispiel ist in PHP ...
%Vor%Im Grunde werden die Datenbank-, Cache- und Sitzungsobjekte erstellt (hier nicht gezeigt) und dann zum Factory-Objekt hinzugefügt. Ich kann eine Methode in der Factory-Klasse für jedes Objekt erstellen, das eines dieser 3 Abhängigkeiten benötigt und ich kann festlegen, welche sie auch bekommen. Dies macht es auch dort möglich, wo die einzelnen Klassen noch etwas tragbar sein können, da ich dort Abhängigkeiten direkt einspeisen kann, wenn ich ohne das Factory-Objekt möchte. Klingt das richtig? Wenn das richtig ist, klingt das wirklich nützlich
UPDATE # 1
Dies basiert hier auf einem Blog-Post, den ich hier Ссылка gelesen habe Bezeichne es als "Fabrik", ich benutze ein Register und viele Leute sagen mir immer wieder, ich solle in eine "Fabrik" schauen und alles, was ich darüber lese, klickte mir nicht in den Kopf, bis ich diesen Artikel gelesen habe wie es ist keine "Fabrik"?
UPDATE # 2
Von Wikipedia http://en.wikipedia.org/wiki/Factory_object
In der objektorientierten Computerprogrammierung ist ein Factory-Objekt ein Objekt zum Erzeugen anderer Objekte. Es ist eine Abstraktion eines Konstruktors und kann verwendet werden, um verschiedene Zuweisungsschemata zu implementieren, beispielsweise das Singleton-Muster.
Ein Factory-Objekt verfügt normalerweise über eine Methode für alle Arten von Objekten, die es erstellen kann. Diese Methoden akzeptieren optional Parameter, die definieren, wie das Objekt erstellt wird, und geben dann das erstellte Objekt zurück.
Factory-Objekte werden in Situationen verwendet, in denen das Erfassen eines Objekts einer bestimmten Art ein komplexerer Prozess ist als das einfache Erstellen eines neuen Objekts. Das Factory-Objekt könnte entscheiden, die Klasse des Objekts (falls zutreffend) dynamisch zu erstellen, sie aus einem Objekt-Pool zurückzugeben, eine komplexe Konfiguration für das Objekt durchzuführen oder andere Dinge.
Vielleicht ist das auf irgendeine Weise ein "Factory-Objekt" ...
Zusammengefasst und erweitert meine Kommentare von unterhalb der Frage hier
Wie andere gesagt haben, ist es keine Factory , einfach weil ein Muster mit diesem Namen nicht existiert. Es ist entweder eine AbstractFactory oder eine FactoryMethod , obwohl sich Leute oft pragmatisch auf beides beziehen oder einfach Factory sagen, und das ist für mich in Ordnung.
>Session, Cache und DB sind normalerweise etwas, was Sie früh in Ihrem Bewerbungsablauf initialisieren, also ist das im Grunde Bootstrap-Arbeit. Ich habe den Eindruck, wonach Sie suchen, ist nicht so sehr die Schöpfung von Objekten, sondern ihre Handhabung in der gesamten Anwendung. Das ist etwas anderes als was ein FactoryWhate tut.
Wie ich in den Kommentaren gesagt habe, nur weil es nicht genau ein FactoryWhatever ist, heißt das nicht, dass Ihr Code schlecht ist. Wenn es dein Problem löst, ist es cool. Aber ich denke immer noch, was du versuchst, z. Das Erstellen von und Ressourcen zur Laufzeit wird am besten mit DI Service Container .
Wenn Sie keinen DI Container now dafür verwenden möchten, können Sie sich Zend_Application und wie sie Ressourcen hochladen . Es ist eine Alternative und lässt die Möglichkeit, später DI-Container hinzuzufügen.
Tatsächlich wurde eine ganze Menge der Themen in Ihren vorherigen Fragen bereits im Zend Framework gelöst, z. Config Klassen. Ich sage nicht, benutze ZF, aber du könntest es überprüfen, um zu sehen, wie sie Dinge machen. Natürlich können Sie sich die anderen Frameworks ansehen auch.
Einige Pattern-Sites mit PHP-Beispielen:
Das Factory-Muster ist in Ordnung, aber Sie benötigen möglicherweise eine bessere Namenskonvention als nur den Aufruf von Factory . Es enthält auch Spuren der Abhängigkeitsinjektion.
Obwohl Sie es technisch das Fabrikmuster nennen könnten, ist es wahrscheinlich keine gute Verwendung des Musters. Factory ist ein kreatives Muster, das Ihren Code einkapselt, indem direkt auf Klassennamen und Objekterstellung verwiesen wird, wie in genauen Konstruktorparametern usw. Um die besten Ergebnisse zu erzielen, sollten Sie dies beim Entwerfen Ihrer Klassen und Fabriken berücksichtigen.
Zum Beispiel StackOverflow gibt es unterschiedliche Benutzer Rechte in Abhängigkeit von ihrem Reputationswert. Hypothetisch könnte es die folgenden Arten von Benutzern haben:
%Vor%und ein Benutzer könnte erstellt werden, indem man seine Repräsentation nachschlägt. und Instanziieren des entsprechenden Benutzerobjekts durch direktes Referenzieren der Klasse. Jon Skeet erscheint in keiner Kategorie, falls Sie sich fragen. Hier ist eine beschissene Implementierung mit direkter Instanziierung:
%Vor%Wenn wir später die Klassennamen oder die Art und Weise ändern sollten, wie Benutzer instanziiert wurden, müsste jede solche Instanz, in der das Objekt erstellt wurde, gefunden und geändert werden. Ziemlich viel Arbeit, wenn du mich fragst. Wenn wir stattdessen das Factory-Muster verwendet hätten, würde die Änderung in einer einzigen Methode innerhalb der Factory-Klasse erfolgen.
%Vor%Sieht für mich nicht wie eine Fabrik aus - könnte ein Inside-Out-Builder sein?; 0)
Factory ist eine Möglichkeit, Implementierung und Instanziierung zu verbergen. Und es wird gewöhnlich etwas zusammengebaut, aber kurz gesagt ....
%Vor%Da es so aussieht, als ob Sie einfach einen Benutzer erstellen möchten, sehe ich keinen Bedarf für einen abstrakten Faktor, der fortan einfach als Fabrik bezeichnet wird. Die Idee von Fabriken besteht darin, Objekte zu erstellen, die eine bestimmte Schnittstelle implementieren. Sie möchten in der Lage sein, zwei verschiedene Implementierungen derselben Schnittstelle zu instanziieren. Der Punkt ist, dass Sie diese Objekte möglicherweise immer und immer wieder neu erstellen müssen, und das Ändern von ObjectA nach ObjectB über den gesamten Code ist umständlich. Der Austausch der Fabrik ist einfach, weil es oft ein Singleton ist.
Die Idee der Factory-Methode bezieht sich auf Frameworks: Sie möchten eine Verwendung in einem Framework-Code erstellen, aber die eigentliche Benutzerimplementierung ist in abgeleiteten Klassen, dh es gibt Benutzer Ihres Frameworks, die ihre eigene App schreiben - das ist, wenn Sie brauchen Um dem Benutzer Ihres Frameworks mitzuteilen, "erstellen Sie jetzt ein Benutzerobjekt", was ein Aufruf der Factory-Methode ist. Der Benutzer muss dies umsetzen. Es wird auch ein virtueller Konstruktor nach GoF genannt.
Der Builder wird normalerweise verwendet, wenn verschiedene Darstellungen des Objekts vorhanden sind, was hier nicht der Fall ist. In meinen Augen könnten Cache, Datenbank und Sitzung als Singletons implementiert werden, was die damit verbundenen Feinheiten erleichtert. Andernfalls würde ich vorschlagen, einen ServiceLocator zu verwenden, der GetDatabase , GetSession usw. erlaubt. Dann müssten Sie den Locator beim Erstellen an ein Benutzerobjekt (und viele andere Objekte) übergeben. Der Vorteil ist, dass dieser Locator für verschiedene Klassen wiederverwendet werden kann.
Tags und Links php design-patterns factory-pattern