Nachdem in den vorausgehenden Blogartikeln (eins, zwei, drei und vier) ausführliche Vorbemerkungen zum Stabilitäts-Konzept gemacht wurden, folgt hier der Katalogeintrag zum Stable Dependencies Prinzip.
Name, Kurzform |
Stable
Dependencies Prinzip |
Synonyme |
Stable Dependencies
Principle,
Prinzip der stabilen Abhängigkeiten,
SDP |
Beschreibung |
„Abhängigkeiten
sollten in der Richtung der Stabilität verlaufen.“ [Martin2002]
|
Erläuterung |
In
der ursprünglichen Martin'schen Version war das Prinzip noch auf den
Package-Begriff bezogen:
„Die
Abhängigkeiten zwischen Packages sollten in derselben Richtung
wie die Stabilität verlaufen. Ein Package sollte nur von Packages
abhängen, welche stabiler als es selbst sind.“
[MartinStability1996]
In
[Martin2002] spricht Martin allgemeiner von „Principles of
Package and Component Design“ und meint somit jegliche
Zusammenfassung von Klassen zu einer höherwertigen Einheit. Die
ursprüngliche, auf Packages eingeschränkte Formulierung sollte
demgemäß heute nicht mehr verwendet werden.
Das
Prinzip kann allgemein auf jede Form von Architektur-Baustein
angewandt werden, wie z. B. Packages, Module, Komponenten und
Services. In spezielleren technischen Umgebungen kann es auch auf
konkretere Realisierungen wie z. B. Jarfiles, OSGi-Bundles oder
Ähnliches bezogen sein. |
Beispiel(e) |
Schichtenmodelle
basieren z. T. auf dem SDP. Höhere Schichten dürfen auf niedere
Schichten zugreifen, aber nicht umgekehrt. In den niederen
Schichten befinden sich oftmals tendentiell stabile Komponenten
wie z. B. die Repräsentation des Datenmodells oder niedere
Dienstklassen.
Die
Verwendung von Bibliotheken basiert neben dem offensichtlichen
Aspekt der Wiederverwendung auch auf dem SDP. In Bibliotheken
werden meist sehr stabile Funktionsbereiche aufgenommen.
Beispiele
für stabile Elemente gemäß [Champaign2003]:
Kerndatenstrukturen, Interface-Module.
- Beispiele
für instabile Elemente gemäß [Champaign2003]:
Customizing-Module, Realisierung von Business Rules.
|
Historie |
Auch
wenn die Intuition, Software-Elemente tendentiell auf möglichst
stabilen anderen Software-Elementen aufzubauen, sicherlich schon
älter ist, so sind die Anfänge des explizit formulierten
Prinzips im Artikel „OO Design Quality Metrics“ [Martin1994]
zu finden. Hier erläutert Martin den Begriff der Stabilität und
entwickelt die Instability-Metrik. Es ist noch nicht von Packages
die Rede, sondern von „Kategorien“ (engl. categories).
Das Prinzip ist noch nicht namentlich formuliert, aber es wird
eine Unterscheidung zwischen guten und schlechten Abhängigkeiten
gemacht: „We can say that a 'Good Dependency' is a dependency
upon something that is very stable.“.
Die
Ausformulierung unter der Bezeichnung „Stable Dependencies
Principle“ folgt dann in [MartinStability1996] innerhalb der
C++-Report-Artikelserie. Es handelt sich um den letzten dieser
Artikel. An Stelle von Kategorien wird jetzt explizit auf
Packages Bezug genommen.
In
[Martin2002] wird dann noch allgemeiner von Packages und
Komponenten gesprochen.
- Mit dem Clean
Code-Buch [Martin2008] beginnt allmählich die Clean
Code-Bewegung, welche zwar eine Reihe von Martin-Prinzipien
(Stichwort S.O.L.I.D.) aufgreift, interessanterweise aber nicht die
Packaging-/Komponenten-Prinzipien. Nichtsdestotrotz hat diese Bewegung auch Robert C. Martin bekannter gemacht und zu einem höheren Bekanntheitsgrad der Packaging-Prinzipien geführt.
|
Art des Prinzips |
Grundlegende
Einteilung: Produkt.
Technologiebezug:
Übergreifend.
Entwurfsgüte:
Strukturprinzip.
Handlungsbezug:
Erleichterung von Änderung.
- Kognitionsbezug:
Hierarchisierung.
(Siehe
Kategorisierung
der Prinzipien.)
|
Grad der formalen
Spezifikation |
-
- In der
allgemeinen, nicht auf die Instability-Metrik bezogenen Version
ist die Formalisierbarkeit schwach, da hier auch
Änderungswahrscheinlichkeiten und systemexterne Aspekte
einbezogen werden müssen, um die Stabilität eines
Software-Elements zu beurteilen.
|
Vorteile |
Das
Prinzip drückt eine weit verbreitete Intuition aus und macht
diese präziser fassbar.
Es
ist kaum abzustreiten, dass es problematisch wäre, viele
Software-Elemente von Elementen abhängig zu machen, die sich
häufig ändern werden. Umgekehrt muss akzeptiert werden, dass es
positiv ist, Software-Elemente von Elementen abhängig zu machen,
die sich nie oder sehr selten ändern werden. Ein wahrer Kern des
Prinzips in seiner allgemeinen Form ist daher unzweifelhaft.
- Der Versuch,
das Konzept der Stabilität durch eine Metrik fassbar zu machen,
muss als positiv bewertet werden, auch wenn die
Instability-Metrik in der vorgeschlagenen Version vermutlich
wenig hilfreich ist (siehe Kritik der Instability-Metrik).
|
Nachteile |
Der
Begriff „Stabilität“ ist mehrdeutig und daher problematisch.
[Champaign2003] bemängelt insbesondere seine suggestive Wirkung
hinsichtlich der Software-Qualität: „Stabil“ scheint eine
positive Software-Eigenschaft zu sein, obwohl sie in Martin's
Sinne für sich genommen weder positiv noch negativ zu werden
ist. In Kritik der Instability-Metrik habe ich ausgeführt, warum ein eingeschränkter Begriff wie "strukturelle Stabilität" hier angemessener wäre. [Champaign2003] schlägt die Verwendung der Skala hart-weich (engl. hard vs. soft) vor.
- Die Anwendung
des Prinzips auf die problematische Instability-Metrik
erscheint zweifelhaft.
|
Übergeordnete
Prinzipien |
Prinzip der losen
Kopplung, Modularisierungsprinzip |
Abgleitete
Prinzipien |
-
|
Qualitätsmerkmale |
(+) Änderbarkeit,
(+) Wiederverwendbarkeit |
Quellen
[Champaign2003] - An Empirical Study of Software Packaging Stability, Champaign, John C. (2003), http://web.mit.edu/~jchampai/www/MastersThesis.pdf
[Martin1994] - OO Design Quality Metrics, Robert C. Martin (1994)
[Martin2002] - Agile Principles, Patterns, and Practices in C#, Robert C. Martin (2002)
[Martin2008] - Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin (2008)
[MartinStability1996] - Stability, Robert C. Martin (1996), http://www.objectmentor.com/resources/articles/stability.pdf