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 SRP: The
Single Responsibility Principle ArticleS.UncleBob.PrinciplesOfOod
Single-Responsibility-Prinzip
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.