Separation of Concerns

Den heutigen Tag widmen wir mal wieder einem Programmierparadigma. Separation of Concerns. Klingt es komisch, wenn ich sage, dass es wahrscheinlich das einfachste und zugleich schwierigste Paradigma ist? Ich denke schon.

Fangen wir mal mit der einfachen Seite an. Separation of Concencs (SOC) bedeutet eigentlich nur, dass Funktionalitäten klar voneinander getrennt sind. Konsequenz daraus ist zum Beispiel, dass jede Methode nur genau eine Sache macht. Wenn man diesen Ansatz konsequent verfolgt, steigt auch die Wiederverwendbarkeit der Komponenten. Klingt einach? Finde ich auch. Nur warum zum Teufel beachtet das niemand?

Fast immer wenn ich fremden Code reviewe, finde ich Stellen, an denen es nicht beherzigt wurde kleine Trennungen von Aufgaben zu gewährleisten. Scheint also doch nicht so einfach zu sein ein Gespür dafür zu entwickeln, wann ich denn jetzt SOC betreiben sollte. Mein Fluchen von vorhin war übrigens eher theatralisch gemeint, ich habe früher ja selbst das „Gespür“ dafür nicht gehabt. Einigen wir uns also drauf, dass es vielleicht doch nicht so einfach ist.

Was mir immer geholfen hat bei diesem Thema ist eine ganz spezielle Frage. Wo würdest du diese Funktionität vermuten, wenn du sie noch mal brauchen würdest? Am besten dabei in einen anderen Entwickler versetzen. Wenn du ganz bestimmt nicht an der Stelle danach Ausschau halten würdest, an der du es jetzt programmiert hast, dann ist es mit Sicherheit die falsche Position.

Separation of concerns

Den heutigen Tag widmen wir mal wieder einem Programmierparadigma widmen. Separation of

Concerns. Klingt es komisch, wenn ich sage, dass es wahrscheinlich das einfachste und

zugleich Schwierigste Paradigma ist? Ich denke schon.

Fangen wir mal mit der einfachen Seite an. Separation of Concencs (SOC) bedeutet eigentlich

nur, dass Funktionalitäten klar voneinander getrennt sind. Konsequenz daraus ist zum

Beispiel, dass jede Methode nur genau eine Sache macht. Wenn man diesen Ansatz konsequnt

verfolgt, steigt auch die Wiederverwendbarkeit der Komponenten. Klingt einach? Finde ich

auch. Nur warum zum Teufel beachtet das niemand?

Fast immer wenn ich fremden Code reviewe finde ich stellen, an denen es nicht beherzigt

wurde kleine Trennungen von Aufgaben zu gewährleisten. Scheint also doch gar nicht so

einfach zu sein ein Gespür dafür zu entwickeln, wann ich denn jetzt SOC betreiben sollte.

Mein Fluchen von vorhin war übrigens eher theatralisch gemeint, ich habe früher ja selbst

das „Gespür“ dafür nicht gehabt. Einigen wir uns also drauf, dass es vielleicht doch nicht

so einfach ist.

Was mir immer geholfen hat bei diesem Thema ist eine ganz spezielle Frage. Wo würdest du

diese Funktionität vermuten, wenn du sie noch mal brauchen würdest? Am besten dabei in einen anderen Entwickler versetzen. Wenn du ganz bestimmt nicht an der Stelle danach ausschau halten würdest, an der du es jetzt programmiert hast, dann ist es mit Sicherheit die falsche Position.

6 Comments

Die Schwierigkeit liegt meiner Meinung darin, den goldenen Mittelweg zu finden, denn wenn man es übertreibt (was auch nicht schwer ist), hat man schnell viel zu viele Klassen und/oder Methoden.

An dieser Stelle hätte ich ein lustiges Diskussionsthema:

Wenn ich den Ansatz: „Eine Methode erledigt nur genau eine Aufgabe“ durchgehend verfolge, wie ist es dann mit Funktionen, die Kombinationen aus diesen einzelnen Methoden verwenden? Ist das schon ein kleiner Verstoß?
(Mir ist klar, dass die Aussage eigentlich != eine Methode ruft nur eine weitere Methode auf ist, das hier ist nur ein Einstiegspunkt ;))

Also nehmen wir als Beispiel eine Reihe von Verarbeitungen von einem Wert aus der Datenbank, der dann mein komplexes Modul durchläuft und irgendwann an der Oberfläche landet.

Hier hätte ich mehrere Möglichkeiten:
1) Die Methoden bilden eine Kette, an deren Ende die Ausgabe steht –> Problem: man kommt schlecht dazwischen

2) Es gibt eine „Master“-Methode, welche diese Funktionen verknüpft –> Problem: Man kommt zwar gut zentral dazwischen, aber was ist in Sonderfällen? (Dies kann man auch dadurch erweitern, dass es mehrere kleinere „Master“-Methoden gibt).

3) ???

Ich werde gleich vermutlich gelüncht, weil ich ein Problem anspreche, das man so generell nicht lösen kann, sondern nur im Einzelfall. Dennoch würde mich eure Vorgehensweise bei soetwas schon interessieren, da mich das doch recht häufig bei komplexen Anwendungen quält.

Also, lasst eure Meinung und best practices hören! 🙂

@Julian: Einzelnen Methoden verwenden ist natürlich kein Verstoss, denn wir verwenden ja nur. Eine Multiplikation ist ja auch nur eine Operation, auch wenn sie vielleicht über viele Additionen gelöst ist.

Im eine Lösung auf der Problem zu finden, müsste man wohl eine konkrete Angabe bekommen. In den meisten Fällen läuft das ja alles im Controller zusammen und wahrscheinlich darf der mehr als eine Aufgabe lösen. Wobei, eigentlich ist seine Aufgabe „Stelle alles zur Verfügung um die View zu füllen“. Das wäre auch nur eine Aufgabe. Also ich denke man muss erst mal definieren, was „genau eine Aufgabe“ ist und dann kommt man ziemlich schnell zu dem Schluss, dass es gar nicht so schwer ist.

Eine andere (von mir beliebte) Herangehensweise ist die, dass ich in einer Methode nur das mache, was der Methodenname (oder auch der Methodenkopf) beschreibt und anders rum der Methodenname beschreiben soll, was die Methode macht.
Ist mein Methodenname zu lang (oder zu ungenau), macht die Methode zu viel. 🙂

@Rudi: Finde ich auch einen sehr netten Ansatz.

@Rudi: Guter Ansatz, so gehe ich das auch an.
@Nils: Ich wollte letztendlich auch auf das Problem hinaus, dass es immer schwer ist zu sagen, eine Methode macht nur genau eine Sache… diese Sache kann auch so komplex sein, dass die Regel nicht direkt zutrifft. Hier hilft dann wohl nur teilen und herrschen… naja, in komplexen Abläufen auf jeden Fall eine der schwierigsten Dinge in solche Prozesse einzugreifen, wie ich finde.