Donnerstag, 17. April 2014

Das Stable Dependencies Prinzip

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]
Im Blogartikel über Packaging-Prinzipien habe ich bereits erläutert, dass der Package-Begriff von Martin eher der damaligen Zeit geschuldet ist.

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
  • Martin bietet eine stark formalisierte Variante des Prinzips auf der Basis der Instability-Metrik an. Die Probleme dieses Ansatzes wurden in folgendem Blogartikel behandelt.
  • 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