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. 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). Ich habe  schon für Kunden gearbeitet, bei denen daher ein breiter Einsatz von Dependency Injection sogar eine Coding Guideline war.
Ob das im Einzelfall sinnvoll ist, muss man natürlich abwägen, einen grundsätzlichen Bruch mit OOP kann ich da aber nicht erkennen.

Und, um ein anderes Beispiel zu nennen, wozu in aller Welt sollte eine Class "Session" gut sein, wo es doch viel einfacher ist, in der Instanz, welche für das Ausliefern der Response zuständig ist, eine Referenz (Attribut) zu haben auf eine zweckmäßige Datenstruktur (Login-Tabelle, Warenkorb usw.).

Was ist, wenn Du irgendwann man Sessions anders implementierst? Z.b. weil Du das DBS zur Verwaltung der Sessions wechselst? Oder weil Du Memcached-Server einsetzen möchtest, die bestimmte Informationen der Session zwischen-cachen, um sie schneller im Zugriff zu machen? Oder...
-> 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.

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.

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 :)

Viele Grüße,
Jörg