Mittwoch, 30. April 2014

Das Stable Abstractions Prinzip

In den vorangehenden Blogartikeln wurden die Konzept der Stabilität und Abstraktheit ausführlich vorgestellt:
Hier folgt nun der Katalogeintrag für das Stable Abstractions Prinzip, das auf diesen beiden Konzepten beruht.

Name, Kurzform Stable Abstractions Prinzip
Synonyme Stable Abstractions Principle, SAP
Beschreibung Eine Komponente sollte so abstrakt sein, wie sie stabil ist.“ [Martin2002]
Erläuterung
Die Stabilität einer Komponente ist in der Regel gegeben. Unser Handlungsspielraum betrifft also die Abstraktheit:
  • Je stabiler eine Komponente ist, desto abstakter sollte sie sein, um so erweiterbar wie möglich zu bleiben. 
  • Das Prinzip fordert aber auch das Umgekehrte: Je instabiler eine Komponente ist, desto weniger abstrakt sollte sie sein.
Die Bedeutung des Prinzips lässt sich mittels des folgenden Diagrammtyps (engl. distance chart) veranschaulichen, der Instabilität und Abstraktheit in ein Verhältnis setzt.
(Dieses Diagramm ohne konkrete Datenpunkte eines Projekts wurde mit dem Werkzeug STAN erzeugt.)

Befinden sich die Eigenschaften Instablität und Abstraktheit auf der eingezeichneten Ideallinie (engl. Main Sequence), so ist nach Martin die Abstraktheit der Stabilität angemessen (und umgekehrt).

Wenn Instabilität und Abstraktheit tatsächlich als Werte zwischen 0 und 1 gemessen werden können (siehe Instability-Metrik und Abstraktheits-Metrik), so lässt sich auch der Grad der Abweichung von der Ideallinie messen. Martin nennt diese abgeleitete Metrik Distanz. Ihre Berechnung erfolgt nach der folgenden Formel:


Das Prinzip besagt, dass das Verhältnis zwischen Stabilität und Abstraktheit ungefähr im roten Bereich des Distanzdiagramms liegen sollte:
Martin erkennt selbst, dass hierbei insbesondere der mittlere Diagrammbereich problematisch ist. Er schreibt:
Die wünschenswertesten Positionen für ein Package sind die beiden Endpunkte der Ideallinie. Nach meiner Erfahrung können jedoch nur etwa die Hälfte aller Packages eins Projekts diese idealen Eigenschaften haben.“ [MartinStability1996]
Auch dies ließe sich als Funktion darstellen. Die wünschenswerten Bereiche sind hier wieder rot eingefärbt:
In seinem Blogartikel Alternative distance function for the Stable Abstractions Principle gibt Tim Wood diese Funktion wie folgt an:


(Thanks to Tim for allowing to quote the formula and the above diagrams!)

Mir ist allerdings bislang kein Analysewerkzeug bekannt, das diese Formel umsetzt.
Beispiel(e)
Die positiven Beispiele, die Martin selbst angibt, zeigen leider nur einzelne Klassen an Stelle von Komponenten. Sie taugen daher nicht, um das Prinzip zu plausibilisieren.

Beispiel eines maximal stabilen Packages:
  • Die Einhaltung des Prinzips bei maximal stabilen Packages ergibt sich von selbst, wenn die abstrakte öffentliche Schnittstelle von einem anderen Team bereitgestellt wird als die Implementierung. Diese Situation ist auch ein Beispiel dafür, warum unterschiedliche Deployment-Anforderungen an Abstraktion und Implementierung dazu führen können, dem Stable Abstractions Prinzip gewissermaßen "auf natürliche Weise" zu folgen.
  • Eine andere Situation entsteht dann, wenn Abstraktion und Implementierung vom selben Entwicklerteam bereitgestellt werden und es auch keine separaten Deployment-Prozesse gibt. Betrachtet man beispielsweise das Package java.util der Java-Klassenbibliothek, so zeigt sich, dass dort Interfaces wie Set, Map oder List gemeinsam mit Implementierungen wie HashSet, HashMap oder ArrayList liegen. Es ist nicht bekannt, dass dies jemals zu Nachteilen geführt hätte, obwohl dieser Funktionsbereich als vergleichsweise stabil gelten kann.
  • Martin bringt selbst das Gegenbeispiel eines String-Packages: Nach Martin'scher Logik hat ein solches Package maximale Stabilität, da es von zahlreichen Komponenten verwendet wird, ohne selbst andere Komponenten zu verwenden. Dennoch können die Klassen darin vollständig konkret sein, ohne dass ein Nachteil entsteht. Der Grund ist hier, dass die Manipulation von Zeichenketten kein volatiler Funktionsbereich ist.
Historie
Die Historie des Stable Abstractions Prinzips ist eng mit der des Stable Dependencies Prinzips verbunden.
  • Erstmals stellt Martin das Prinzip 1994 in seinem Artikel „OO Design Quality Metrics“ vor, gibt ihm hier jedoch noch nicht den späteren Namen. Auch ist noch nicht von Packages oder Komponenten die Rede, sondern von Kategorien. Martin unterscheidet jedoch bereits zwischen „guten“ und „schlechten“ Abhängigkeiten, stellt die Konzepte Stabilität und Abstraktheit sowie die Distanz-Metrik vor. [Martin1994]
  • Die Ausformulierung unter der Bezeichnung „Stable Abstractions Principle“ folgt dann (wie für das Stable Dependencies Prinzip) in [MartinStability1996] innerhalb der C++-Report-Artikelserie. Die Rede ist hier nun von Packages.
  • In [Martin2002] wird dann noch allgemeiner von Packages und Komponenten gesprochen.
Art des Prinzips
  • Grundlegende Einteilung: Produkt.
  • Technologiebezug: Spezifisch. (Objektorientierung).
  • Entwurfsgüte: Strukturprinzip.
  • Handlungsbezug: Erleichterung von Änderung, Verteilung.
  • Kognitionsbezug: Abstraktion.
(Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation Analog zum Stable Dependencies Prinzip.
Vorteile
  • Das Prinzip kann als Einstieg in die Fragestellung dienen, in welchen Fällen die Wahl von abstrakten Klassen oder Interfaces an Stelle von konkreten Klassen angemessen ist. Leider hilft es bei dieser Entscheidung aber nicht sonderlich gut weiter.
  • Der Versuch, derart komplexe Konzepte wie Stabilität und Abstraktheit in Beziehung zu setzen und sogar metrisch zu untermauern, muss gewürdigt werden.
Nachteile
  • Das Konzept der Abstraktheit weist etliche schwerwiegende Schwächen auf:
    • Die Übertragbarkeit der (qualitativ positiven) Eigenschaften von einzelnen abstrakten Klassen oder Interfaces auf Grade von Abstraktheit ganzer Komponenten ist nicht nachvollziehbar.
    • Die Abstraktheits-Metrik selbst ist in der vorgeschlagenen Form schwach.
  • Eine empirische Fundierung ist nicht gegeben.
Übergeordnete Prinzipien
Abgleitete Prinzipien -
Qualitätsmerkmale (+) Änderbarkeit

Quellen

[Martin1994] - OO Design Quality Metrics, Robert C. Martin (1994)

[Martin2002] - Agile Principles, Patterns, and Practices in C#, Robert C. Martin (2002)

[MartinStability1996] - Stability, Robert C. Martin (1996), http://www.objectmentor.com/resources/articles/stability.pdf