Abstrakte Pakete sichern Flexibiltät

Abstraktion ist ein fundamentales Prinzip in der Objektorientierung. Abstraktion kann ein wenig verwirrend sein, weil sie sich sowohl auf einen Prozess als auch auf das Produkt bezieht, das der Prozess hervorbringt. Wenn der Abstraktionsprozess durchgeführt wird, muss man sich darauf konzentrieren, die wichtigen Eigenschaften eines Elements herauszustellen und die weniger wichtigen zu ignorieren. Wenn Abstraktion richtig angewendet wird, dann repräsentieren die resultierenden Produkte jene Abstraktionen, die äußerlich die wesentlichen Eigenschaften dieser Elemente darstellen und die weniger wichtigen Eigenschaften unterdrücken. Eine der besten Methoden, die Vorteile der Abstraktion umzusetzen, ist es, die Zuständigkeiten eines Pakets von der Implementierung zu trennen. Das heißt im Prinzip, dass man die Vorschriften wie etwas gemacht werden soll (Spezifizierung) von der tatsächlichen Umsetzung dieser Vorschriften trennt (Implementierung).

Bei der Objektorientierung werden häufig Vererbung und Polymorphismus benutzt, um die Spezifizierung von der Implementierung zu trennen. Dadurch, dass man abstrakte Klassen definiert, kann man von diesen Abstraktionen übernehmen und eine spezielle Implementierung durchführen. Dadurch kann man Klassen mit einem Interface verbinden und nicht mit einer Implementierung. Die folgende heuristische Methode wendet dieses Konzept auf Pakete an: Pakete, auf die man am stärksten angewiesen ist, sollten so abstrakt wie möglich sein.

Abstrakte Pakete bestehen hauptsächlich aus abstrakten Klassen oder Interfaces. Eine Abhängigkeit von abstrakten Klassen oder Interfaces statt von einer Implementierung ermöglicht es, die Implementierung zu modifizieren, ohne die Spezifizierung zu beeinflussen. Für Pakete, auf die man stark angewiesen ist, sollte man sicherstellen, dass man von abstrakten und nicht von konkreten Komponenten abhängt. Von abstrakten Komponenten abhängig zu sein, erhöht die Flexibilität bei der Architektur.

In dem oben besprochenen Logging-Beispiel fesselt uns die direkte Abhängigkeit vom Logging-Paket an die Implementierung, die vom Paket bereitgestellt wird. Dadurch, dass das logfacade-Paket verwendet wurde, wurde das Risiko von Veränderungen beim Logging verkleinert. Das Risiko wurde jedoch nur auf die LoggingFacade-Klasse übertragen, nicht aber vollständig beseitigt. Um die Auswirkungen von Veränderungen weiter zu verkleinern, wird ein LoggerInterface im logfacade-Paket benutzt. Die LoggingFacade implementiert dieses LoggerInterface. Abbildung B illustriert das neue LoggerInterface, welches das ursprüngliche Design aus Abbildung A erweitert. Es zeigt darüber hinaus auch, wie man die neue Logging-Funktion von Java 2 v.1.4 unterstützen kann.

Abbildung B: Die neue LoggerInterface-Klasse (Abbildung vergrößern)