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

SRP: The Single Responsibility Principle

ArticleS.UncleBob.PrinciplesOfOod

Single-Responsibility-Prinzip