Das scheint am Anfang immer sinnlos, bis man an eine Stelle kommt, wo man merkt, dass man haufen ändern muss ;)
Hatte mal bei einer Seite, wo es auch um Creational Patterns ging, also Patterns, die zur Objekterzeugung geeignet sind, gelesen, dass es Ziel ist kein new-Operator in einem Script zu haben Aber ich denke das ist dann immer Sache der Projektgröße. Aber du darfst nicht nur an das hier und jetzt denken. Wenn du zum Beispiel ein Konstruktor änderst, dann musste auf die Änderung nur in der Factory drauf eingehen und da dann vielleicht nen Default-Wert setzen.
Deswegen auch das Zitat. Grundsätzlich kannst du sagen die Schweine stammen eigentlich alle voneinander ab. Nur leider sind sie doch unterschiedlich, weil sie andere Module an sich haben. Die CyberPigFactory dient bei deinen Scripten, die von aussen zugreifen einfach nur als Schnittstelle, um das, was dahinter passiert zu verstecken. Diese newPig()-Funktion kann ja auch überladen mit anderen Parametern existieren. Also einmal nur stinknormal als CyberPigFactory::newPig() oder auch als CyberPigFactory::newPig(id).
Bei der ersten Variante scheint es recht simpel, was dahinter passiert. es wird new CyberPig() aufgerufen. Aber es könnte ja auch new CyberPig(0, "Hausschwein") aufgerufen werden, wenn dein System innerhalb ein Cyberschwein mit den Namen "Hausschwein" als undefiniert betrachtet. Also ohne weitere Spezialisierung und ohne Module.
Die zweite Variante versteckt dem ausführenden Programm lediglich, wie er denn, und vorallem wo er die Daten hernimmt und zusammenbaut. Wo die Factory die Daten herbekommt weiß sie vielleicht selber nicht, sondern schickt einfach nur ein Query an eine Klasse, die halt auf einer Persistenzschicht hängt - also deine DB zb.
Theoretisch wäre es dumm in meinem Model, dass die Factory am Anfang alle Daten bekommt. Also auch die von den Modulen, obwohl sie es nicht brauch. Theoretisch könnte es dann, mit ein wenig umbau, eine Anfrage an die ModuleFactory erstellen, doch mal bitte ein Modul mit der id x zu erstellen. Wie die das dann macht ist ja auch erstmal wieder egal. Aber da ein Modul nie alleine existieren kann, weil es immer an irgendein Objekt gebunden ist, habe ich dann halt Methoden benannt, die ein assoziatives Array (Map) bekommen und sich ihre benötigten Werte rauspicken. Denn ihre Felder kennen sie ja - die Factories.
So hatte ich mir den Ablauf vorgestellt. die serializeXXX und deserializeXXX Funktionen dienen in erster Linie dazu, dass aus dem assoziativen Array ein Objekt wird. Zumindest in dem Beispiel. Wie die Deserialisierung/Serialisierung auszusehen hat liegt in der Obhut der ModuleFactories. Da leitet der Service nur die Daten weiter. wobei der Service schon im groben wissen sollte, was ihn da erwartet. Aber wenn, dann macht der nur ein oberflächigen Check und muss nicht verstehen, wie du Zusammenhänge sind. Das Cachen ist zwar derzeit nicht mit drin, aber das Modell lässt sich ja erweitern. Man könnte den CyberModuleService noch mit einer Cache-Funktion dekorieren (Decorator Pattern). Das gezeigte Modell hat aber derzeit nur einen Sinn:
Wie bekomme ich die unstruktierten Daten aus der Datenbank und wieder zurück.
Was soll denn dein Requester machen? Also die Informationen sind ein wenig dürftig ;) Also soll der vorgefertige Query-Templates haben oder wie meinste das? Man könnte zum Beispiel so ne Art Proxy um die geladenen Klassen machen und die checken immer, ob sich das Objekt geändert hat (nur in php sicherlich nicht gerade so einfach zu erledigen) und dann am Ende des Scriptablaufes wird dann jedes Objekt, wo der Proxy meint, dass es sich geändert hat, zurück in die DB geschrieben. Nur müssteste dann die Objekte den ganzen Scriptablauf irgendwo zwischenspeichern, damit du am Ende noch weißt, welche denn überprüft werden müssen ;)
Ob du dein DataHandler nun Service nennst ist eigentlich geal. Kommt ja drauf an was er macht ;) Und du sollst ja nicht immer einem Pattern folgen, was auch Mist ist, sondern du sollst für das Problem das passende Pattern finden und dies umsetzen. Ich glaube da gibts auch ein Antipattern dafür, der das falsche verwenden der Design Patterns beschreibt
