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