nicht angemeldet
Hi,
Dein Ravioli/Spaghettivergleich ist nicht schlecht 😉
Auf jeden Fall verfolgt man mit der Aufteilung in Funktionseinheiten völlig andere Ziele als SRP definiert, nämlich diese hier:
- Übersichtlicher code
- wartbarer Code
- Teamarbeit
- Effizienz
- Debugging
- Vermeidung von Coderedundanzen
- Skalierbarkeit
(ohne Anspruch auf Vollständigkeit)
SRP ist kein GOF Design Pattern, sondern ein Grundprinzip der OOP.
Natürlich kann kann OOP auch zum Selbstzweck betreiben, das ist jedoch der Praxis ferner denn je. Den Hauptgrund überhaupt OOP einzusetzen, fand ich bei Eric Foster Johnson in einem Buch über Perlmodule: Der Hauptvorteil von OOP besteht darin, daß sie besser mit Veränderungen umgehen kann (7). Und genau das hat sich in meiner Praxis täglich bis stündlich bewahrheitet.
Ebensowenig zeigen Patterns der GOF Wege bzw. Vorgehensweisen die zielführend sind. Es sind vielmehr Muster die man sogar nebeneinander in Programmen vorfinden kann, ohne daß die Programmierer jemals die Absicht hatten, nach einem Muster der GOF vorgehen zu wollen. Beispiel Dependency Injection:
Eine Instanz der Klasse Session wird dem Konstruktor der Responseklasse übergeben. Das macht man aber nicht weil man DI verwenden möchte, sondern einfach nur deswegen, weil die Sessioninstanz noch vor dem Erstellen des Response-Objekts vorliegen muss.
Den Einbau der CGI Klasseninstanz hingegen kann man auch später vornehmen, also nachdem das Responseobjekt bereits vorliegt. Z.B. erst in dem Moment, wenn eine CGI-Methode aufgerufen wird. Und auch das ist keine Frage des Entwurfsmusters sondern eine Frage des Deployments und Softwareverteilung und der übrigen Punkte siehe obenstehend.
Schöne Grüße.
Rolf B