3.4 Prinzip 4: Offen für Erweiterung, geschlossen für Änderung  

Ein Softwaremodul sollte sich anpassen lassen, um in veränderten Situationen verwendbar zu sein. Eine offensichtliche Möglichkeit besteht darin, den Quelltext des Moduls zu ändern. Das ist eine vernünftige Vorgehensweise, wenn die ursprüngliche Funktionalität des Moduls nur genau an einer Stelle gebraucht wird und absehbar ist, dass das auch so bleiben wird.

Module in verschiedenen Umgebungen

Ganz anders sieht es aber aus, wenn das Modul in verschiedenen Umgebungen und Anwendungen verwendet werden soll. Sicher, auch hier können Sie den Quelltext des Moduls ändern, oder, besser gesagt, Sie können den Quelltext des Moduls kopieren, die Kopie anpassen und eine neue Variante des Moduls erstellen. Doch möchten wir jeden warnen, diesen Weg zu gehen, denn er führt direkt in die Hölle. [Nein, wir meinen nicht die Hölle der ewigen Verdammnis, die nach der christlichen Religion die Sünder nach dem Tod erwartet. Zu der können wir uns (noch) nicht kompetent genug äußern. Wir meinen die Hölle der Programmierer, in der wir unsere traurigen Überstunden hier auf der Erde fristen. ]

Wir werden nämlich auf das folgende Problem stoßen: Die neue Variante des Moduls wird sehr viele Gemeinsamkeiten mit dem ursprünglichen Modul haben. Ergibt sich später die Notwendigkeit, die gemeinsame Funktionalität zu ändern, müssen Sie die Änderung in allen Varianten des Moduls vornehmen.

Änderungen vermeiden

Wie können Sie die Notwendigkeit vermeiden, das Modul ändern zu müssen, wenn es in anderen Kontexten verwendet werden soll?

Betrachten wir kurz ein Beispiel aus dem realen Leben. Um gute digitale Fotos zu machen, reicht normalerweise eine einfache Kompaktkamera aus. Sie ist einfach zu handhaben, handlich und für ihren Zweck, spontan ein paar Schnappschüsse zu schießen, ausreichend. Doch sie ist nicht erweiterbar. In bestimmten Situationen, in denen ihr Bildsensor ausreichen würde, schaffen Sie es nicht, ein gutes Bild zu machen, weil das Objektiv oder das eingebaute Blitzgerät der Lage nicht gewachsen sind. Sie können Objektiv und Blitzgerät aber auch nicht auswechseln.

Eine Spiegelreflexkamera dagegen ist für Anpassungen gebaut. Reicht das gerade angeschlossene Objektiv nicht aus? Dann können Sie ein Weitwinkel- oder ein Teleobjektiv anschließen. Ist das eingebaute Blitzgerät zu schwach? Ein anderes lässt sich einfach aufsetzen.

Doch diese Erweiterungsmöglichkeiten haben ihren Preis – statt das Objektiv und den Body einfach als eine Einheit herzustellen, müssen sie z. B. mit einem Bajonettanschluss ausgestattet werden. Abbildung 3.5 stellt die beiden Varianten gegenüber.

Abbildung 3.5    Eine kompakte und eine erweiterbare Fotokamera

Erweiterbarkeit eines Moduls

Auch Softwaremodule können so konstruiert werden, dass sie anpassbar bleiben, ohne auseinander gebaut werden zu müssen. Man muss sie nur mit den »Bajonettanschlüssen« an den richtigen Stellen ausstatten. Ein Modul muss also erweiterbar gemacht werden.

Das Modul kann so strukturiert werden, dass die Funktionalität, die für eine Variante spezifisch ist, sich durch eine andere Funktionalität leicht ersetzen lässt. Die Funktionalität der Standardvariante muss dabei nicht unbedingt in ein separates Modul ausgelagert werden – genauso wie das eingebaute Blitzgerät nicht stört, wenn man ein externes anschließt.

Die Erweiterbarkeit eines Moduls lässt sich mit dem Prinzip Offen für Erweiterung, geschlossen für Änderung ausdrücken.

Offen für Erweiterung, geschlossen für Änderung (Open-Closed-Principle)

Ein Modul soll für Erweiterungen offen sein. Das bedeutet, dass sich durch die Verwendung des Moduls zusammen mit Erweiterungsmodulen die ursprüngliche Funktionalität des Moduls anpassen lässt. Dabei enthalten die Erweiterungsmodule nur die Abweichungen der gewünschten von der ursprünglichen Funktionalität. Ein Modul soll für Änderungen geschlossen sein. Das bedeutet, dass keine Änderungen des Moduls nötig sind, um es erweitern zu können. Das Modul soll also definierte Erweiterungspunkte bieten, an die sich die Erweiterungsmodule anknüpfen lassen.

Definierte Erweiterungspunkte

Wir müssen hier allerdings einschränken: Ein nichttriviales Modul wird nie in Bezug auf seine gesamte Funktionalität offen für Erweiterungen sein. Auch bei einer Spiegelreflexkamera ist es nicht möglich, den Bildsensor auszuwechseln. Stattdessen werden einem Modul definierte Erweiterungspunkte zugeordnet, über die Varianten des Moduls erstellt werden können.

Indirektion

Solche Erweiterungspunkte können Sie in der Regel durch das Hinzufügen einer Indirektion erstellen. Das Modul darf die variantenspezifische Funktionalität nicht direkt aufrufen. Stattdessen muss das Modul eine Stelle konsultieren, die bestimmt, ob die Standardimplementierung oder ein Erweiterungsmodul aufgerufen werden soll.

Funktionalität erkennen

Wie erkennen Sie nun, welche Funktionalität für alle Varianten gleich und welche für die jeweiligen Varianten spezifisch ist? Wo sollen die Erweiterungspunkte hin?

Am einfachsten lässt sich diese Frage beantworten, wenn das Modul nur innerhalb einer Anwendung verwendet oder nur von einem Team entwickelt wird. In diesem Fall können Sie einfach abwarten, bis der Bedarf für eine Erweiterung entsteht. Wenn der Bedarf da ist, sehen Sie bereits, welche Funktionalität allen Verwendungsvarianten gemeinsam ist und in welchen Varianten sie erweitert werden muss. Erst dann müssen Sie das Modul anpassen und es um die benötigten Erweiterungspunkte bereichern.

Diese Vorgehensweise ist natürlich nicht möglich, wenn das ursprüngliche Modul von einem anderen Team entwickelt wird und das Team, welches das Modul erweitern möchte, das ursprüngliche Modul nicht ändern kann, um die benötigten Erweiterungspunkte hinzuzufügen. In diesem Fall ist es notwendig, die benötigten Erweiterungspunkte bereits im Vorfeld einzugrenzen.

Aufwand durch Erweiterungspunkte

Das Hinzufügen der Erweiterungspunkte ist mit Aufwand verbunden, der durch die Wiederverwendung der gemeinsamen Funktionalität wettgemacht werden soll. Wenn die Komponente nicht mehrfach verwendet wird, muss sie auch nicht mehrfach verwendbar sein, und Sie können sich den Aufwand für das Erstellen von Erweiterungspunkten sparen.

Zu viele nicht genutzte Erweiterungspunkte machen Module unnötig komplex, zu wenige machen sie zu unflexibel. Die Bestimmung der notwendigen und sinnvollen Erweiterungspunkte ist deshalb oft nur auf der Grundlage von Erfahrung und Kenntnis des Anwendungskontexts möglich.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.