Moin!

ich versuche mir MVC zu erarbeiten und dabei OOP zu verstehen.

Zu MVC könnte ich direkt einen längeren Beitrag schreiben, der im Endeffekt dazu kommt, dass man im Webumfeld keinerlei MVC machen kann.

Das geht mir ganz ähnlich. Diesen ganzen Hype um MVC, Design Patterns und GoF sehe ich allenfalls als ein Henne-Ei-Problem und was Webanwendungen betrifft, da passt das Zustandsmodell (im Wiki unter EA, Endlicher Automat zu finden) viel besser, weil es praxisorientiert ist.

Das hat mit objektorientierter Programmierung allerdings alles nicht zwingend zu tun. Im Gegenteil wirst du beim Versuch, OOP zu verstehen, durch Betrachtung von MVC vermutlich eher "versaut" - zumindest wenn du schlechte Tutorials liest, oder unkritisch Frameworks benutzt.

OOP ist kein Selbstzweck, sondern eine praktische Angelegenheit. 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.

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.). Denn nur dann kennt der Programmierer zuverlässig den Zeitpunkt, wann das Zurückschreiben der Daten spätestens fällig ist, nämlich in Destruktor seiner eigenen Instanz.

Datenkapselung ist hierzu das Stichwort und eine Klasse allein bewegt noch gar nichts (danke für die Beispiele mit Sinus und Cosinüssen), genausowenig wie Vererbung immer sinnvoll ist. Vordergründig ist ein überschaubarer CODE der über Jahre verständlich bleibt, wachsen und gepflegt werden kann.

Schöne Grüße.