Single Responsibility Principle (SRP) – Wissenshäppchen #3

Mein drittes Wissenshäppchen hat das Single Responsibility Principle zum Thema. Inhalt Das SRP ist das erste der sogenannten SOLID-Prinzipien. Robert „Uncle Bob“ Martin definiert es so: There should never be more than one reason for a class to change. Jede Klasse sollte genau einen einzigen Grund haben, um geändert zu werden. Man kann das Prinzip aber auch auf anderen Ebenen (z.B. Variablen, Methoden oder ganze Komponenten) berücksichtigen. Erklärung * Nur Dinge, die zusammengehören, werden auch zusammen abgebildet. Jedes Ding (Variable, Methode, Klasse, Komponente) darf nur eine Aufgabe haben. Die Kohäsion der Dinge sollte hoch sein. * Verletzung ist erkennbar an Wörtern wie und oder oder. Unklare Namen wie z.B. Manager oder Verwaltung sind auch häufig ein Anzeichen für die Verletzung des Prinzips. * Wenn viele Abhängigkeiten und Dinge, die nichts miteinander zu tun haben, in einer Klasse zusammengefasst werden, kann beim Anpassen einer (Teil-)Implementierung eventuell eine damit gar nicht in Zusammenhang stehende Implementierung negativ beeinträchtigt werden. * Praxisbeispiel: Klasse, die Daten aus der Datenbank liest und diese direkt in der Oberfläche anzeigt. Klasse hat nicht nur eine Aufgabe, sondern drei verschiedene: Geschäftslogik, Datenzugriff, Anzeige. Ein Test der Logik ohne Datenbank und/oder Oberfläche ist nun unmöglich. Die Wiederverwendbarkeit der Klasse leidet auch, da die Logik nun nicht mehr ohne Datenbank und/oder Oberfläche aufgerufen werden kann. Das ist oft ein großes Problem in Legacy-Anwendungen. * Ein krasses Gegenbeispiel/Antipattern zum SRP wäre eine Gott-Klasse, die alles Mögliche macht. Vorteile * Die Klassen, Methoden und Variablen sind insgesamt kürzer und besser verständlich. * Entwickler können Anpassungen durchführen, ohne dabei Fehler an anderer Stelle einzubauen. * Komponenten sind einfacher testbar. Das Test-Setup ist kleiner, weil unnötige Abhängigkeiten nicht bereitgestellt werden müssen. Probleme bei der Testbarkeit und Verständlichkeit entstehen häufig, wenn zu viel auf einmal passiert. Zu wenig ist meistens kein Problem. Nachteile * Durch viele kleine Methoden und Klassen leidet evtl. die Übersicht über das Gesamtsystem und man findet sich schwieriger zurecht. Dem kann man aber entgegenwirken und es ist erstmal nicht schlimm, viele kleine Klassen anzulegen, anstatt eine große. Dateien kosten nichts. Dateien/Klassen können in IDEs mit Shortcuts schnell gefunden/geöffnet werden. Wenn auf eine vernünftige (einheitliche) Benennung geachtet wird, sind Klassen auch so gut auffindbar. Weitere Konventionen (z.B. die Einordnung in Package-Strukturen) helfen auch bei der Organisation. * Wenn Klassen nur eine einzige Aufgabe haben dürfen, steigt automatisch die nötige Kopplung zu anderen Klassen, weil deren Funktionalität benötigt wird, um die Gesamtaufgabe zu erfüllen. Hier gilt es, einen guten Mittelweg zu finden, der eine möglichst hohe Kohäsion bei gleichzeitg geringer Kopplung ermöglicht. Literaturempfehlungen Wie zu fast jedem Wissenshäppchen kann ich jeder/m Anwendungsentwickler/in nur wärmstens Clean Code* von Uncle Bob ans Herz legen. Das SRP wird hier auch erklärt und gleich praktisch angewendet. * Links * Permalink zu dieser Podcast-Episode * RSS-Feed des Podcasts