Tach!
Also um nochmal auf die Factory zurückzukommen: Das wäre auch eine Möglichkeit Objekte zu aggregieren. Heißt daß der Konstruktor von Class Proof zunächst gar keine Daten aus DB liest.
Das was du letztlich erreichen möchtest, ist das, was wir mit dem Repository erreichen wollen. Es holt einen angefragten Datensatz aus dem DBMS und erstellt eine POxO-Klasse, die es mit den Daten befüllt und gibt diese zurück. Wenn du so willst, ist das eine Art Factory.
Erst wenn die Proofinstanz $pro erstellt wird, ruft $pro eine Methode data($id) und in dieser Methode wird dann gebrüft ob es in $this eine Instanz der Klasse DB gibt die für die Datenbeschaffung zuständig ist. Wenn nicht wird sie erstellt.
Das entspräche nicht der DI-Philosophie, dass sich jemand einen Service selbst instantiiert, anstatt reingereicht zu bekommen. Und es entspräche auch nicht dem POxO-Prinzip, dass die Datenklasse mit artfremden Dingen wie Persistierung angereichert wird.
Wir versuchen die Dinge nach Aufgabenbereich zu trennen. Danach hat die fachliche Datenklasse nur ihre fachliche Aufgabe zu erfüllen. Nichtfachliche Nebentätigkeiten wie Persistierung werden von anderen Komponenten des Systems ausgeführt.
PS: Perl tie() wäre hier auch noch interessant.
Das finde ich nicht. Ich hab zwar nicht komplett verstanden, was das tie() macht (ist mir auch egal), aber zur Laufzeit Dinge zusammenzubasteln, ist nicht der Weg, den man in PHP (oder .NET) geht.
dedlfix.