In seinem Werk „Agile Software Development: Principles, Patterns, and Practices“ (ISBN: 978-0135974445) stellt Robert C. Martin eine Liste Prinzipien für Kopplung und Kohäsion von Softwarepaketen auf, die bis heute einen zentralen Eckpfeiler für die Entwicklung von modularer Softwarearchitektur darstellen. Im folgenden werden diese Prinzipien kurz dargestellt.
Ein Softwarepaket sei eine Menge von Klassen. Die Klasse A besitzt zur Klasse B eine Abhängigkeit, wenn B Teil der Schnittstelle von A ist oder aus der Implementierung von A eine Methode von B aufgerufen wird. Befindet sich Klasse A in Paket P und Klasse B in Paket Q, so hat P eine Abhängigkeit zu Q. Es gibt zahlreiche weitere Möglichkeiten, wie Abhängigkeiten entstehen können, die für die folgende Betrachtung jedoch nicht relevant sind.
Die folgenden drei Prinzipien beziehen sich auf die Koppelung von Paketen:
- Acyclic Dependencies Principle – „The dependencies betwen packages must not form cycles“: Es liegt auf der Hand, dass man zyklische Abhängigkeiten zwischen Paketen unbedingt vermeiden sollte, da sie das Bauen und Testen der Software erheblich erschweren.
- Stable Dependencies Principle – „Depend in the direction of stability“: Es ist klar, dass man Abhängigkeiten zu Paketen bevorzugen sollte, die sich nur selten ändern. Umgekehrt bedeutet das auch, dass man Abhängigkeiten zu Paketen präferieren sollte, zu denen viele anderen Pakete eine Abhängigkeit haben. Der Gedanke dahinter ist, dass Pakete seltener geändert werden und damit stabiler, wenn sie viele Benutzer haben.
- Stable Abstractions Principle – „Stable packages should be abstract packages“: Nach dem obigen Punkt sind Paket stabiler, wenn sie viele Benutzer haben. Solche Pakete sollten auch möglichst abstrakt sein, d.h. nur generische Abstraktionen, Schnittstellen und wenig konkrete Implementierungen enthalten, die ohne Modifikation des Paket selbst von anderen Paketen erweiterbar sind. Die Hoffnung ist, dass sich dadurch wenige Gründe zur Änderung des Pakets ergeben.
Die weiteren drei Prinzipien beziehen sich auf die Kohäsion von Paketen:
- Common Closure Principle – „Classes that change together, belong together“: Ein einziger Änderungsgrund sollte möglichst wenige Pakete betreffen. Daher sollten mehrere Klassen, die immer gemeinsam geändert werden müssen, im selben Paket liegen.
- Common Reuse Principle – „Classes that aren’t reused together should not be grouped together“: Je mehr Klassen ein Paket hat, desto wahrscheinlicher wird es, dass es geändert werden muss. Wird ein Paket geändert, so werden die Benutzer gezwungen auf die neue Version hochzuziehen und zu testen, da häufig unklar ist, ob die Änderungen für sie wichtig sind oder nicht. Hat das Paket weitere Abhängigkeiten, müssen auch diese hochgezogen werden. Betreffen die Änderungen nur Klassen, die ein Benutzer gar nicht verwendet, so erzeugt dies viel unnötige Arbeit.
- Release Reuse Equivalency Principle – „The granule of reuse is the granule of release“: Echte Wiederverwendung geschieht nur, wenn der Code released wird. Dies beinhaltet, dass die Versionen getestet und auf bestimmte Zeit supported werden. Ist dies nicht der Fall, werden Benutzer das Paket kaum verwenden.
Das „Release Reuse Equivalency Principle“ ist besonders hervorzuheben, da man häufig zwei Antipatterns beobachten kann, durch die Code nur scheinbar wiederverwendet wird:
- Das erste Vorgehen besteht darin Code zu kopieren und diese Kopie für seine Zwecke anzupassen. Dies erzeugt zwei unabhängige Stände die gepflegt werden müssen und ist somit genau das Gegenteil von Wiederverwendung.
- Im zweiten Fall ziehen mehrere Teams ein gemeinsames „Common“-Repository aus ihren Projekten an. Da Common niemals released wird, arbeiten alle Projekte mit Common auf dem main-Branch oder auf einem eigenen Tag bzw. Branch. Als Resultat findet sich über alle Projekte und deren Releases hinweg keine gleiche Softwareversion von Common. Vielmehr existieren in jedem Produkt und jeder Produktversion andere Stände, die im Falle einer Schwachstelle separat gepatched werden müssen.
Uncle Bobs Package Principles gelten heute noch wie vor zwanzig Jahren und sollten beim Design jedes Softwaresystems berücksichtigt werden.