SWE Single Responsibility
Trenne, was getrennt gehört.
In der Softwareentwicklung ist das Single Responsibility Principle (SRP) Gesetz. Robert C. Martin formuliert es so: Eine Klasse sollte einen und nur einen Grund haben, sich zu ändern (Martin, 2003)1.
Wenn eine Komponente Drucken und Berechnen erledigt, musst du sie anfassen, wenn sich das Druckformat ändert. Du riskierst dabei, dass du das Berechnen zerstörst. Martin schreibt: Sammle zusammen, was sich aus denselben Gründen ändert. Trenne, was sich aus verschiedenen Gründen ändert (Martin, 2003)2.
Das Prinzip gilt isomorph für den Zettelkasten. Wenn ein Zettel ›Luhmanns Biografie‹ und ›Luhmanns Theorie‹ behandelt, hat er zwei Gründe zur Änderung. Findest du neue Details zur Biografie, musst du den Theorie-Text anfassen. Willst du die Theorie verlinken, schleppst du unnötigen Ballast mit.
Die Lösung ist radikale Trennung. Ein Zettel für die Biografie, einer für die Theorie, verbunden durch einen Link. So bleiben beide Teile unabhängig wartbar.
Anknüpfungspunkte
ZK Atomizität - SRP ist die technische Begründung für Atomizität. ZK Konnektivität - Wer trennt, muss verbinden. Lose Kopplung - SRP trennt Verantwortungen; lose Kopplung trennt Abhängigkeiten.
Bestätigung
Die ›Unixphilosophie‹ demonstriert SRP in Reinform: Jedes Programm soll eine Sache gut machen.3 grep sucht nur Text, sort sortiert nur. Wenn du suchen und sortieren willst, baust du kein riesiges Programm. Du verbindest beide mit einer Pipe (|).
Widerspruch
Kritiker warnen vor ›Ravioli Code‹. Wenn du alles in winzige Schnipsel zerlegst, verlierst du den Überblick. Zu viele kleine Klassen führen zu Fragmentierung; der Kontrollfluss wird schwer nachvollziehbar.4 Im Zettelkasten löst du das durch Strukturzettel (Hubs), die die Teile wieder zusammenführen.
Beispiel
Unix Tools: grep sucht, sort sortiert, uniq entfernt Duplikate. Jedes Tool hat eine einzige Verantwortung. Komplexe Operationen entstehen durch Kombination (grep | sort | uniq). Sie entstehen niemals durch Monolithen.
Genealogie
Der Urvater ist David Parnas (1972). Er beschrieb Information Hiding, Informationen verbergen.5 Ein Modul sollte ein ›Geheimnis‹ vor anderen verbergen (Parnas, 1972). SRP ist die moderne Anwendung dieses Denkens.
Vertiefung
Ein noch allgemeineres Konzept ist Separation of Concerns (SoC), geprägt von Edsger W. Dijkstra.6 Verschiedene Aspekte eines Problems, Logik vs. Darstellung, müssen strikt getrennt werden, um sie intellektuell beherrschbar zu machen (Dijkstra, 1974).
Blick über den Rand
Im Journalismus: Ein Artikel behandelt ein Thema. Ein Kommentar behandelt die Meinung dazu. Eine Reportage behandelt das Erlebnis. Vermischt man Nachricht und Meinung, leidet die Glaubwürdigkeit. SRP schafft Klarheit in Textgattungen.
Footnotes
-
Originalzitat: »A class should have one, and only one, reason to change.« (Martin, 2003) ↩
-
Originalzitat: »Gather together the things that change for the same reasons. Separate those things that change for different reasons.« (Martin, 2003) ↩
-
Originalzitat: »Make each program do one thing well.« (McIlroy et al., 1978) ↩
-
Kontrollfluss: Der Weg, den ein Programm bei der Ausführung nimmt. Zu viele kleine Teile machen den Pfad unübersichtlich (›Spaghetti-Code‹ oder ›Ravioli-Code‹). ↩
-
Information Hiding: David Parnas’ Prinzip (1972). Ein Modul verbirgt seine internen Entscheidungen. Nur das Interface ist sichtbar. (Parnas, 1972) ↩
-
Separation of Concerns (SoC): Edsger W. Dijkstra. Verschiedene Aspekte eines Problems müssen getrennt werden. (Dijkstra, 1974) ↩