Sonntag, 1. Dezember 2013

Packaging-Prinzipien

Neben den S.O.L.I.D.-Prinzipien formulierte Robert C. Martin 1996/97 auch einige Prinzipien, die heute als "Packaging-Prinzipien" (auch: Package-Prinzipien, engl. package principles) einige Bekanntheit erlangt haben. Der vorliegende Artikel behandelt diese Prinzipien nicht im Detail, sondern dient einigen Vorbemerkungen, bevor diese Packaging-Prinzipien in folgenden Artikeln ausführlich besprochen und in den Prinzipienkatalog aufgenommen werden.

Historischer Kontext des Package-Begriffs

Zunächst soll an den historischen Kontext erinnert werden, in dem Martin seine Artikel schrieb. Dies ist schon deshalb erforderlich, um den Begriff des Packages angemessen einzuordnen, den Martin hier im Blick hatte.

Die UML existierte damals in der Version 0.9.x. Die Version 1.0 wurde erst gegen Ende 1997 verabschiedet. Ebenfalls existierte auch Java erst seit 1996 in Version 1.0. Das JAR-Dateiformat wurde erst 1997 mit Version 1.1 veröffentlicht. C++ hingegen existierte in einer erweiterten Version (2.0), die auch abstrakte Klassen einführte, bereits seit 1989. Robert C. Martin veröffentlichte seine Prinzipien-Artikel in dem Journal C++ Report und hatte damals primär die objektorientierte Entwicklung in C++ im Blick. Dass er dennoch von Packages und nicht von Namespaces sprach, führt er selbst in [MartinStability1996] auf die UML zurück.

Martin hatte demnach bei der Ausarbeitung der Packaging-Prinzipien nicht den Package-Mechanismus von Java vor Augen. Man darf auch davon ausgehen, dass er nicht Module im Sinne von Jarfiles im Hinterkopf hatte. Das Package-Diagramm der UML kommt seinem Package-Begriff wohl am nächsten: Packages als Container für (abstrakte und konkrete) Klassen, ergänzt um einen Import-Mechanismus, dürften seiner Vorstellung am nächsten kommen.

Erwähnenswert ist auch, dass wesentliche Elemente von Martins Gedankengängen bereits 1994 im Artikel "OO Design Quality Metrics. An Analysis of Dependencies" [Martin1994] vorgetragen wurden, damals aber noch ohne den dann später verwendeten Package-Begriff. Martin nutzte anscheinend später diesen Begriff, um sich damit von der Klassen-Ebene deutlicher abzulösen und der Entwurfs-Ebene anzunähern.

Packages = Komponenten?

Zwar wurde mit der UML 1.0 bereits die Komponenten-Notation von Grady Booch eingeführt, doch Komponentendiagramme in der heutigen Form stellte die UML erst mit der Version 2.0 ab 2005 zur Verfügung. Es ist fraglich, ob Martin die Komponenten der UML bereits bekannt waren, als er seine Artikel schrieb. Die UML-Packages, die den Namespaces aus C++ entfernt ähnlich waren, dürften für Martin der einzige bekannte Mechanismus gewesen sein, um Klassen in einer Ordnung auf hörerer Ebene zusammenzufassen und ihnen eine übergreifende Struktur aufzuprägen. In seinem Artikel [MartinGranularity1996] stellt Martin die folgenden Fragen in Bezug auf Packages:
  • Welches sind die besten Zerlegungskriterien?
  • Welche Beziehungen existieren zwischen Packages, und welche Entwurfsprinzipien leiten ihre Verwendung?
  • Sollten Packages vor Klassen entworfen werden (top-down)? Oder sollten Klassen vor Packages entworfen werden (bottom-up)?
  • Wie werden Package physisch repräsentiert? In C++? In der Entwicklungs-Umgebung?
Offensichtlich geht es hier noch um sehr grundsätzliche Fragen der Realisierung und Nutzung von Packages, die sich auch noch in keiner Weise auf Schnittstellen und eher komponentenorientierte Ansätze beziehen. Es geht Martin weniger um Modularisierung als um Strukturierung.

Zusammenfassung: Heutige Einordnung

Seit Formulierung der Packaging-Prinzipien sind inzwischen fast 20 Jahre vergangen. Die Erfolgsgeschichte von Java und der von dort bekannte Package-Begriff, das Verständnis von Komponenten als Modulen höherer Ordnung und neuere Modularisierungs-Ansätze wie OSGi oder serviceorientierte Architekturen lassen Martins Sicht auf Packages heute etwas in die Jahre gekommen erscheinen. Wie sich zeigen wird, können viele Details seiner Prinzipien heute nicht in der ursprünglichen Form aufrecht erhalten werden. Martin hat dies wohl damals schon geahnt und schließt in [MartinStability1996] mit folgenden Worten:
"Es ist sicher möglich, dass der Standard, der in diesem Artikel gewählt wurde, nur auf bestimmte Applikationen angewendet werden kann. Es ist ebenfalls möglich, dass weit bessere Metriken genutzt werden können, um die Qualität eines Entwurfs zu bewerten."

Quellen

[Martin1994] - OO Design Quality Metrics. An Analysis of Dependencies, Robert C. Martin (1994), http://www.cin.ufpe.br/~alt/mestrado/oodmetrc.pdf
[MartinGranularity1996] - Granularity, Robert C. Martin (1996), http://www.objectmentor.com/resources/articles/granularity.pdf
[MartinStability1996] - Stability, Robert C. Martin (1996), http://www.objectmentor.com/resources/articles/stability.pdf