23. Single-Responsibility-Prinzip

Themen

Das Single-Responsibility-Prinzip

Beispiele für seinen Einsatz

Bedeutung im Gesamtkontext der Software-Architektur

Folien

PDF

Glossar

PDF

Video

MP4

Hinweis: Der Webcast wurde mit Tiny Webcasts for Lecture(r)s erstellt.

• 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.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, werden aber nicht separat in der Vorlesung besprochen.

• 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?

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