Hallo Hotti,

Ich kenne einige Programierer, die entwerfen die kühnsten Klassenhierarchien und wenn es um den Datenaustausch geht, wird dann mit allen Regeln der OOP gebrochen; beispielsweise werden dann ohne Not Instanzen von Klassen an Konstruktoren anderer Klassen übergeben.link:

Inwiefern stellt das für Dich einen Bruch mit OOP dar? Das, was Du beschreibst, ist das Prinzip der Dependency Injection (genauer Constructor Injection) und kann verwendet werden, die Abhängigkeiten von einer Klasse zu anderen Klassen zu reduzieren.

Klar. Nur halt andersherum, dann ist das OK: Nicht die Instanz übergeben, sondern in einer _eigenen_ Methode die Instanz einer anderen Klasse erstellen und erst dann die eigene Methode aufrufen.

Gerade für Unit-Tests ist sowas m.E. elementar wichtig, wenn man z.b. mit Mock-Objekten arbeiten will/muss - in solchen Fällen sind Klassen, die selbständig andere Klassen instanzieren, die Hölle (da nur schwierig einzeln, d.h. ohne die Infrastrukur der anderen Klassen, testbar).

Auch klar.  Meine Units kannste alle mocken, wenn fremde Klassen im Spiel sind oder deren Instanzen, lagere ich den Code aus in die Factory. Der Aufruf mit einer Attrappe (über eine Instanz oder den Namen einer Klasse) ist ja die Grundlage dafür, dass der Code wiederverwendbar ist, letztendlich ist er von der aufrufenden Instanz unabhängig.

Ob das im Einzelfall sinnvoll ist, muss man natürlich abwägen, einen grundsätzlichen Bruch mit OOP kann ich da aber nicht erkennen.

Streitfrage ;) Auf jeden Fall wird das Debugging erschwert wenn Instanzen einer Klasse als Argumente in Konstruktoren anderer Klasse übergeben werden. Per Factory wird das viel übersichtlicher, da sind auch fremde Klassen austauschbar, ein Griff in die Datei, fertig.

Was ist, wenn Du irgendwann man Sessions anders implementierst? Z.b. weil Du das DBS zur Verwaltung der Sessions wechselst?

Kein Problem, die Datenstruktur bleibt dieselbe. Stichwort Data Abstraktion Layer und der ist austauschbar.

Oder weil Du Memcached-Server einsetzen möchtest, die bestimmte Informationen der Session zwischen-cachen, um sie schneller im Zugriff zu machen? Oder...

Oh Vorsicht. In der Session liegen Userdaten und in dem Moment, wenn die Response raus ist, haben die im Hauptspeicher nichts mehr zu suchen. Dasselbe gilt für den Request, auch hier sind Userdaten enthalten. EINE Instanz, _ein_ Destruktor und _eine_ Stelle im Code, wo klar wird, dass es keine Referenzen mehr gibt auf Userdaten. Umso wichtiger, wenn der Prozess im Hauptspeicher verbleibt (FastCGI).

-> Einfacher (und in vielen Fällen sicher auch völlig ausreichend) ist eine einfache Referenz auf das darunter liegende Objekt vielleicht, architektonisch kann es aber schon Sinn machen, die Applikationslogik von der Session-Verwaltung sauber zu trennen.

Klar, wegen der Übersicht. EIN DESTROY und _das_ vererben wir gerne ;)

Datenkapselung ist hierzu das Stichwort und eine Klasse allein bewegt noch gar nichts
Doch, wenn sie sauber entworfen wurde, eledigt sie exakt eine einzige, wohl definierte Aufgabe.

Methoden bewegen die Daten. Methoden im eigenen Namespace und weg mit globalen Variablen. Schlimm genug, dass es überhaupt welche gibt ;)

Vordergründig ist ein überschaubarer CODE der über Jahre verständlich bleibt, wachsen und gepflegt werden kann.

Hierzu (und zu dem Rest Deines Posts) FULL ACK - Design Prinzipien sind, wie auch Programmiersprachen und Technologien, Werkzeuge, die man dann - und nur dann- nutzen kann und sollte, wenn es Sinn ergibt - nicht einfach nur, weil sie existieren :)

Herzlichen Dank für Dein Feedback,

schöne Grüße.