Innere Werte, Teil 2: Ordnung & Separation
Zu den inneren Werten eines Softwaresystems gehören auch Ordnung und Separation. Wie also sind Komponenten und Schnittstellen geschnitten? Und wie bilden sich Verantwortlichkeiten auf Komponenten und Schnittstellen ab?
- Dr. Michael Stal
Zu den inneren Werten eines Softwaresystems gehören auch Ordnung und Separation. Wie also sind Komponenten und Schnittstellen geschnitten? Und wie bilden sich Verantwortlichkeiten auf Komponenten und Schnittstellen ab?
Die Banana und der Gorilla
Wer kennt das nicht, ĂĽbergewichtige Komponenten, die von A bis Z alle erdenklichen Verantwortlichkeiten an sich reiĂźen? Will man die Banane, bekommt man immer den Gorilla mit dazu. Das Ă„ndern solcher Komponenten fĂĽhlt sich nach stressigem Abenteuerurlaub an. Von Verstehen kann erst gar nicht die Rede sein.
Separation of Concerns und Single Responsibility
Zwei Prinzipien, die in diesem Kontext greifen, sind Trennung der Verantwortlichkeiten und Eine-Verantwortlichkeit-pro-Komponente.
- Ersteres bedeutet zum Beispiel, dass Fachlogik, Infrastrukturlogik, Hilfsfunktionen nie in einer einzigen Komponente vereint sein dürfen. Würde dies zugelassen, müsste bei Änderung eines Aspekts immer die gesamte Komponente angefasst werden. Abgesehen davon führt dies auch häufiger zu Änderungsbedarf bei Nutzern der Komponente.
- Zweiteres bedeutet, dass jede Komponente genau eine Verantwortlichkeit ĂĽbernehmen sollte. Und diese Verantwortlichkeit sollte sie dann auch voll und ganz erfĂĽllen, nicht nur halb.
Verwendet der Architekt/Entwickler beide Prinzipien konsequent, sind die daraus resultierenden Systeme sowohl leichter verständlich als auch leichter veränderbar.
Guter Schnitt
Was für Komponenten gilt, macht auch für Schnittstellen Sinn. Maximalistisch aufgeblähte Schnittstellen wirken wie die zahlreichen Bedienelemente in einem Flugzeugcockpit, nämlich völlig unübersichtlich. So gab es in der Iterator-Klasse von CORBA Dutzende von Methoden. Diese Fülle erschlägt Entwickler. Eine Iteratorklasse mit wenigen Methoden für den Normalgebrauch, dazu weitere übersichtliche Schnittstellen für ausgefeiltere Aufgaben, ist der bessere Ansatz.
Jede Schnittstelle hat also eine kleingeschnittene Rolle oder Verantwortlichkeit. Komplexere Komponenten können dafür auch mehrere Schnittstellen besitzen.
Wer Schnittstellen mit massenhaft Deklarationen vor sich hat, dazu Methoden mit unübersichtlich vielen Parametern, kann also guten Gewissens von schlechter interner Qualität ausgehen.
Nicht nur der Code
Und solche Analysen lassen sich auch schon im konzeptionellen Entwurf oder in der Anforderungsspezifikation durchführen. Wenn sich eine UML-Klasse erst nach sekundenlangem Scrollen erschließt oder eine Anforderung seitenlange Elaborate enthält, ist es mit der Trennung der Verantwortlichkeiten garantiert nicht gut bestellt.
Indiz und kein Beweis
Allerdings ist auch "Ordnung & Separation" nur ein Qualitätsindikator, kein Beweis.
Wer nämlich die Verantwortlichkeiten zu klein schneidet, erzeugt einen Ozean von Minimalkomponenten. Die Komplexität wandert dann von den Komponenten immer mehr in ihre gegenseitigen Abhängigkeiten. Ergebnis ist dann ein dichtes Geflecht von Komponenten, das man in seiner extremsten Form auch als Gestrüpp bezeichnen könnte. Eine Änderung kann in diesem Fall sehr viele Komponenten betreffen. Das ist insbesondere die Gefahr von sehr feingranularen Microservices-basierten Architekturen. ()
