Themen

Das Single-Responsibility-Prinzip

Beispiele für seinen Einsatz

Bedeutung im Gesamtkontext der Software-Architektur

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_23

• Ein Modul sollte nur Verantwortung
  gegenüber genau einem Akteur haben.
• Jede Verantwortlichkeit ist eine
  (potentielle) Quelle für Veränderungen.
• Verantwortlichkeiten richtig zu trennen,
  ist ein zentraler Aspekt jeglicher Softwarearchitektur.
• Trennung der Verantwortlichkeiten ist nur dann wichtig,
  wenn unabhängige Änderungen real auftreten.
• Eines der einfachsten Prinzipien für Softwarearchitektur –
  und eines der am schwersten korrekt umzusetzenden.

Ein Modul einer Software sollte nur Verantwortung gegenüber genau einem Akteur haben. Warum? Weil jede Verantwortlichkeit eine potentielle Quelle für Veränderungen ist. Die richtige Auftrennung dieser Verantwortlichkeiten ist ein zentraler Aspekt jeglicher Software- und Systemarchitektur und entscheidet maßgeblich über Flexibilität, Modularität, Wiederverwendbarkeit und Wartbarkeit, kurz über die Qualität des Gesamtsystems.

So einfach das Prinzip daher kommt und so leicht es intellektuell zu verstehen ist, so schwer ist es in der Praxis umzusetzen. Zwei Symptome sind klare Hinweise auf eine Verletzung des Single-Responsibility-Prinzips: Starrheit und Zerbrechlichkeit. Im ersten Fall zieht jede Änderung an einer Stelle viele Änderungen an anderen Stellen nach sich, während im zweiten Fall Änderungen zu Fehlern in konzeptionell getrennten Bereichen des Systems führen. Nichts zu ändern ist aber keine Option, weil die Daseinsberechtigung von Software gerade ihre (einfache) Veränderbarkeit ist – abgesehen davon, dass der (persönliche) Erkenntnisfortschritt im wissenschaftlichen Kontext eine weitere Quelle ständiger Veränderungen ist.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Was ist die Kernaussage des Single-Responsibility-Prinzips? Worin unterscheidet es sich z.B. vom Unix-Prinzip?
• Definieren Sie den Begriff „Verantwortlichkeit“ im Kontext des Single-Responsibility-Prinzips.
• Wie lautet die Verallgemeinerung des Single-Responsibility-Prinzips auf der Ebene der Komponenten bzw. darüber hinaus?
• Welches der Entwurfsmuster der „Gang of Four“ spielt eine wesentliche Rolle bei einer möglichen Umsetzung des Single-Responsibility-Prinzips?
• Wie könnte allgemeine Regel für den Einsatz des (bzw. Verzicht auf das) SRP lauten?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Das SRP wurde in dieser Form von Robert C. Martin formuliert, entsprechend findet es sich in seinen Büchern, vgl. dazu Kapitel 8 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey]. Eine leicht unformulierte und mit (in meinen Augen) deutlich zugänglicheren Beispielen versehene Fassung findet sich in Kapitel 7 in [Martin, 2018Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston].

Der Artikel, in dem „Conways Gesetz“ formuliert wurde, stammt aus dem Jahr 1968: [Conway, 1968Conway, Melvin E. (1968): How do committees invent?, Datamation 14:28-31].

• Conway, Melvin E. (1968): How do committees invent?, Datamation 14:28-31
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston