SOLID Controller

[Silverdark]

Hallo Community,

ich habe mich in den letzten Tagen ein wenig mit dem SOLID Prinzipien auseinandergesetzt.
Meine Frage ist nun, verstoßen Controller, die Seitenrequests annehmen, nicht gegen das erste Prinzip ("A class should have only one reason to change")?

Note: Hoffe ist der richtige Bereich, konnte mich nicht entscheiden zwischen hier und Software-Design.

Liebe Grüße

[rkr]

Nicht per se. Es kommt drauf an, wie man die Frage stellt, bzw. was diese eine Sache ist, weswegen man eine Klasse ändern muss. Die Aufgabe einer Klasse kann sein, zwischen verschiedenen Komponenten zu vermitteln.

[Silverdark]

Das heißt, wenn ein Controller für z. B. Artikel verschiedene Actions bereitstellen soll und dann eine Action bearbeitet werden muss (Beispiel: Das Ändern eines Artikel wird geändert), dann wird das Prinzip nicht verletzt, da nur diese eine Stelle bearbeitet werden muss?

[rkr]

Das gilt natürlich nur, wenn ein Controller für nicht mehr als eine Action steht. Sobald ein Controller mehr als eine Action kapselt, tut er automatisch mehr als eine Sache.

Grundsätzlich finde ich den Prinzipienbruch auf dieser Ebene aber nicht besonders problematisch. Bei den Domänen-Objekten ist die Einhaltung der SOLID-Prinzipien ungleich wichtiger.

[jack88]

Das gilt natürlich nur, wenn ein Controller für nicht mehr als eine Action steht. Sobald ein Controller mehr als eine Action kapselt, tut er automatisch mehr als eine Sache.

Demnach würde also schon ein findBy() und save() in einer DataMapper-Klasse oder ein add() und sub() in einer Taschenrechner-Klasse oder ein setXyz() und getXyz() in irgendeiner Klasse genügen um das S im SOLIDzu verletzen

VG
Jack

[rkr]

Demnach würde also schon ein findBy() und save() in einer DataMapper-Klasse oder ein add() und sub() in einer Taschenrechner-Klasse oder ein setXyz() und getXyz() in irgendeiner Klasse genügen um das S im SOLIDzu verletzen

Wenn man die Prinzipien salafistisch auslegt, dann ja. Ein Controller ist ja eigentlich eine Facade (nicht im Sinne der reinen Definition, sondern im Sinne des Ducktypes). Ein Controller kapselt ein komplexeres Subsystem und stellt es über ein simples Interface dar.

Das gilt auch für einen DataMapper, der weder etwas mit findBy oder save zu tun hat, sondern mit mapFrom oder mapTo (wenn gleich das Muster oftmals mit ORMs wie Hibernate assoziiert wird). Und diese beiden Methoden kapseln jeweils eine Strategie für eine Richtung, die jeweils auch als eigene Klasse dargestellt werden kann. Ebenso findBy und save.

[jack88]

Wenn man die Prinzipien salafistisch auslegt, dann ja. Ein Controller ist ja eigentlich eine Facade (nicht im Sinne der reinen Definition, sondern im Sinne des Ducktypes). Ein Controller kapselt ein komplexeres Subsystem und stellt es über ein simples Interface dar.

Meiner Auffasung nach ist ein Controller eine Komponente der Applikationslogik, deren Aufgabe/Verantwortung darin besteht zwischen der View und dem Model zu vermitteln. Solange diese Verantwortung nicht verletzt wird ist alle OK. Entscheidend dabei ist die Funktionalität der View, da diese letztendlich die Verantwortung (Die "Verantwortung" einer Klasse im SRP ist als "Grund zur Änderung" definiert.) des Controllers definiert. Die Veranwortung/Grund zur Änderung wäre in diesem Fallalso eine Änderung der View. Die Anzahl der Methoden/Actions ist deshalb unerheblich und verletzt nicht automatisch das SRP.

VG
Jack

[rkr]

Meiner Auffasung nach ist ein Controller eine Komponente der Applikationslogik, deren Aufgabe/Verantwortung darin besteht zwischen der View und dem Model zu vermitteln.

Das hängt ganz vom Kontext ab. Ein Controller kann sich durchaus auch an anderer Stelle wiederfinden und beispielsweise den Ablauf eines komplexen Kopiervorgangs ordnen. Da wäre dann nicht unbedingt ein View involviert - allenfalls ein Logger. Im Kontext MVC vermittelt der Controller zwischen der Anwendungsdomäne (Model) und der Darstellungsdomäne (View). In meinen jüngeren Projekten kümmern sich die Controller nicht mal mehr um die Darstellungsebene. Das passiert im Frontcontroller.

Solange diese Verantwortung nicht verletzt wird ist alle OK. Entscheidend dabei ist die Funktionalität der View, da diese letztendlich die Verantwortung (Die "Verantwortung" einer Klasse im SRP ist als "Grund zur Änderung" definiert.) des Controllers definiert. Die Veranwortung/Grund zur Änderung wäre in diesem Fallalso eine Änderung der View. Die Anzahl der Methoden/Actions ist deshalb unerheblich und verletzt nicht automatisch das SRP.

Genau, es hängt immer davon ab, wie man die Frage stellt, bzw. wie man die Zuständigkeit der im Projekt einbezogenen Komponenten definiert. Klare Begriffsdefinitionen sind schwierig. Das merkt man schon, wenn man versucht, echtes MVC mit PHP abzubilden.