Das Single-Responsibility Prinzip

Verdoppelung des Katalogumfangs: 

Name, Kurzform	Single-Responsibility Prinzip
Synonyme	Eine-Verantwortlichkeit Prinzip, Prinzip einer einzigen Verantwortung, SRP
Beschreibung	Unter dem Namen Single-Responsibility Prinzip findet man häufig fälschlicherweise die Bedeutung eines anderen Prinzips, und zwar „Separation of Concerns“ (SoC). Alle Formulierungen der Art „Jedes Modul soll genau eine Verantwortung übernehmen, und jede Verantwortung soll genau einem Modul zugeordnet werden.“ sind jedoch nicht das SRP, da dieses ansonsten nur ein leicht modifiziertes SoC wäre. Die Bezeichnung Single-Responsibility Prinzip wurde jedoch erstmalig von Robert C. Martin eingeführt und setzt einen anderen Schwerpunkt: „Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern.“ [Martin2002]
Erläuterung	Das Besondere an Martins Definition ist die Definition der Verantwortung als „reason for change“. Die Modularisierung erfolgt nicht nach den realweltlichen Entitäten, sondern auf der Basis von Änderungserwartungen. In dieser Form ist das SRP deutlich näher mit dem Prinzip der hohen Kohäsion verwandt.    Das Prinzip drückt demnach eine Beziehung zwischen einer Software-Entität und einer außerhalb der Software liegenden Eigenschaft (einer Annahme über künftige Anforderungsänderungen) aus.    Es postuliert als Idealbild, dass die Änderung einer Anforderung innerhalb eines Software-Systems nur in einem eng umgrenzten Bereich zu Software-Änderungen führt.    Insgesamt wird durch diesen Ansatz das Prinzip der hohen Kohäsion auf der Basis von Änderungserwartungen präzisiert.
Beispiele	Verantwortlichkeiten nach [Larman 2002]: Etwas wissen: Zusammengehörige Daten oder Informationen kennen. Etwas können: Steuerungs- oder Kontrollverantwortung. Etwas erzeugen. Architektonisch: Die heute etablierte Trennung von Anwendungslogik und Anzeige wird durch ähnliche Motive gerechtfertigt wie das SRP. Bei gewünschten Änderungen im View sollte die Anwendungslogik unverändert bleiben und umgekehrt. Klassischer Bruch mit diesem Prinzip (Gegenbeispiel): Die Anwendung benötigt ein neues Eingabefeld. Aus Benutzersicht ist dies ein einziger Änderungsgrund. Betroffen sind aber View, Anwendungslogik und Persistenz. Die Schichtenarchitektur (ihrerseits fundiert durch zahlreiche Prinzipien) führt hier also zu einem Verstoß gegen das SRP.
Historie	Die Einführung des Konzepts der Kohäsion erfolgte bereits in den 1970er Jahren durch Yourdan und Constantine, siehe [Yourdan 1979]. Martin selbst gibt als Ursprung des Konzepts die Arbeiten [DeMarco79] von Tom DeMarco und [PageJones88] von Meilir Page-Jones an. Das Prinzip wurde im Gegensatz zu den anderen S.O.L.I.D.-Prinzipien nicht im Rahmen der Robert C. Martin-Artikelserie aus "The C++ Report" in 1996 veröffentlicht, sondern von Martin erst in [Martin2002] formuliert. Die Einführung des Akronyms "S.O.L.I.D." geht laut einigen, nicht notwendigerweise zuverlässigen Quellen (darunter Wikipedia) auf Michael Feathers Anfang der 2000er Jahre zurück.
Art des Prinzips	Grundlegende Einteilung: Produktprinzip. Technologiebezug: Allgemeingültig. Entwurfsgüte: Zerlegungskriterium. Handlungsbezug: Erleichterung von Änderung, Verstehen, Wiederverwendung. Kognitionsbezug: Komplexitätsreduktion. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Gering auf Grund des starken Anteils außerhalb der Software liegender Eigenschaften (Änderungserwartungen).
Vorteile	Liefert eine Operationalisierung des ansonsten nur schwer fassbaren Prinzips der hohen Kohäsion. Die Frage: „Was macht Software-Elemente zusammengehörig?“ wird auf neue Weise beantwortet.
Nachteile	Die Quelle künftiger Änderungen ist oftmals schwer vorhersehbar. Das Prinzip lässt sich nur in solchen Fällen anwenden, in denen ausnahmsweise in dieser Hinsicht Klarheit besteht. Eine übertriebene Anwendung des Prinzips könnte zu übermäßiger Modularisierung führen. Andere Aspekte hoher Kohäsion werden ausgeblendet. Die Zerlegung eines Systems auf der Basis von Änderungserwartungen kann gegen das Prinzip der minimalen intellektuellen Distanz verstoßen, nach welchem die Distanz zwischen dem realweltlichen Problem und der Software-Lösung möglichst gering bleiben sollte. Ein Änderungsdruck ist keine Entität der realen Welt. Auf diese Weise können Klassen entstehen, deren Existenzberechtigung nicht mehr intuitiv nachvollziehbar ist.
Übergeordnete Prinzipien	Prinzip der hohen Kohäsion Separation of Concerns Prinzip der Änderungsnotwendigkeit Lokalitätsprinzip
Abgleitete Prinzipien	-
Qualitätsmerkmale	Änderbarkeit (+), Erweiterbarkeit (+) Verständlichkeit (-), Einfachheit (-)

Links

Robert C. Martins Blog Principles of OOD

Quellen

[DeMarco79]: Structured Analysis and System Specification, Tom DeMarco, Yourdon Press Computing Series (1979)

[Larman 2002] – Applying UML and Patterns, Second Edition, frei verfügbar unter http://www.cs.bgu.ac.il/~oosd051/uploads/stuff/ApplyingUMLandPatterns.pdf, Larman, C. (2002)

[Martin 2002] – Agile Software Development. Principles, Patterns, and Practices, Robert C. Martin (2002)

[PageJones88]: The Practical Guide to Structured Systems Design, 2d. ed., Meilir Page-
Jones, Yourdon Press Computing Series (1988)

[Yourdon 1979] -  Structured design. Fundamentals of a discipline of computer program and systems design, Yourdon, E., Constantine, L. (1979)