Separation of Concerns

Lesetipps

1. Six Degrees of Separation (friend of a friend)
2. Premature Optimization
3. Ein “kluger” Satz über Code Reviews

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.

6 Kommentare »

• 
  

  Rudi

  am 3. Februar 2010 um 09:54 Uhr

  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.

• 
  

  Julian

  am 3. Februar 2010 um 12:27 Uhr

  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!

• 
  

  Nils Langner

  am 3. Februar 2010 um 12:34 Uhr

  @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.

• 
  

  Rudi

  am 3. Februar 2010 um 13:20 Uhr

  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.

• 
  

  Nils Langner

  am 3. Februar 2010 um 13:22 Uhr

  @Rudi: Finde ich auch einen sehr netten Ansatz.

• 
  

  Julian

  am 3. Februar 2010 um 15:31 Uhr

  @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.

RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

Einen Kommentar hinterlassen