Freitag, 11. Januar 2013

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
Abgleitete Prinzipien -
Qualitätsmerkmale
Änderbarkeit (+), Erweiterbarkeit (+)
Verständlichkeit (-), Einfachheit (-)

Links

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)

Keine Kommentare:

Kommentar veröffentlichen