Montag, 7. April 2014

Stabilität - die Übertragung auf Software-Elemente

Im vorhergehenden Blogartikel wurde erläutert, dass Martins Begriff der Stabilität aus einer physikalischen Intuition abgeleitet ist. In physikalischen Systemen stützen sich oftmals weniger stabile (z. B. flexiblere, leichtere) Elemente auf stabilere (z. B. größere, schwerere) Elemente. Für Software-Systeme scheint es vernünftig zu sein, in ähnlicher Weise vorgehen zu wollen.

Es wurde jedoch auch bereits dargestellt, dass es gar nicht so klar ist, was "Stabilität" für Software-Elemente eigentlich bedeuten soll. Während physikalischen Elementen ihre Stabilität z. B. durch Bauweise, Festigkeit, Größe usw. relativ einfach angesehen werden kann, existieren für Software-Elemente keine solch einfach wahrnehmbaren Eigenschaften. Wie also soll das Stabilitätskonzept auf Software übertragen werden?

Stabilität = Änderungskosten

Martins erster Schritt zur Operationalisierung der Stabilität für Software-Elemente besteht darin, Stabilität als den Aufwand zu definieren, der mit einer Änderung des jeweiligen Elements einhergehen würde. (Der zweite Schritt wird im nächsten Blogartikel betrachtet.) Martin schreibt explizit:
"Stabilität ist kein Maß für die Wahrscheinlichkeit, mit der sich ein Modul ändern wird; es ist eher ein Maß für die Schwierigkeit, ein Modul zu ändern." [MartinStability1996]
Selbst wenn dies für sich genommen plausibel klingt, so muss doch festgehalten werden, dass dies eine sehr willkürliche Interpretation ist. Stabilität wird hier ganz speziell an Kostenerwägungen gekoppelt. Es bleibt nicht nur der Nutzenaspekt (von Änderungen) außer Acht - auch ganz andere denkbare Dimensionen werden nicht berücksichtigt. Martin schließt sogar explizit die "Wahrscheinlichkeit, mit der sich ein Modul ändern wird" aus, obwohl solche Änderungserwartungen für zahlreiche andere Prinzipien (z. B. das Single Responsibility Prinzip) durchaus eine relevante Dimension sind.

Änderungskosten sind nicht immer relevant

Halten wir uns vor Augen, was es bedeutet, ein System verstärkt von solchen Elementen abhängig zu machen, die nur mit hohen Kosten änderbar sind: Anforderungen, die Änderungen an den stabilen Teilen des Systems erfordern würden, werden dann tendentiell gar nicht erst durchgeführt. Implizit wird damit der Nutzen des Systems weitgehend auf den Nutzen eingeschränkt, der bei der Konzeption der stabilen Elemente des Systems vorgesehen war. Indem man besonders stabile Elemente in ein System einführt und davon viele andere Elemente abhängig macht, wächst die Bedeutung der stabilen Elemente. Wurden sie falsch angelegt, steht die Überlebensfähigkeit des gesamten Systems in Frage.

Gegen diese Argumentation lässt sich einwenden, dass es gleichgültig ist, mittels welchen Kriteriums ich meine stabilen Systemelemente bestimme: Ist dieses Kriterium durch einen äußeren Einfluss nicht mehr gültig, so führt dies automatisch zu einem Überlebensproblem des Gesamtsystems, dessen gesamte Konstruktion auf diesem Kriterium fusst. Damit wird aber auch klar, dass dem gewählten Kriterium entscheidende Bedeutung dafür zukommt, ob der ganze Denkansatz erfolgversprechend ist oder nicht. 

Vor diesem Hintergrund erscheint die Auswahl der Änderungskosten als Stabilitäts-Kriterium zumindest als einseitig. Dominieren in einem System die Nutzen-Aspekte gegenüber den Kosten, oder kommen gar Anforderungen ist Spiel, die von Kosten/Nutzen-Erwägungen unabhängig sind (z. B. gesetzliche Erfordernisse, Sicherheitsaspekte usw.), so dürfte die Martin'sche Operationalisierung eher kontraproduktiv wirken.

Quellen

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