Schlichtes Design

Der traditionelle Ansatz

Bei traditionellen Vorgehensweisen wird häufig ein großer Aufwand in das Software-Design gesteckt, lange bevor die erste Zeile Code geschrieben wurde. Das ist insofern verständlich, als dies unter anderem damit begründet wird, daß man auf diese Weise sicherstellen möchte, daß das System optimal designed ist. Dieses Design auf Vorrat wird im englischen Upfront Design genannt.

In der Praxis ergeben sich dabei jedoch Probleme. Eines der Probleme ist, daß sich während der Implementierung neue Einsichten ergeben, die häufig eine Designänderung erfordern. Dann wird de facto die Arbeit, die vorher geleistet wurde, weggeworfen. Schließlich wird ja das ursprüngliche Design an dieser Stelle nicht benötigt.

Die Ursachen für solche Änderungen sind vielfältig:

• Das ursprüngliche Design führt zu Performanceproblemen.
• Das ursprüngliche Design ist zu komplex.
• Das ursprüngliche Design ist nicht flexibel genug, z.B. um eine bestimmte Schnittstelle zu unterstützen.
• Es gibt eine neue Anforderung des Kunden, die in das System integriert werden muß.
• Das ursprüngliche Design verbraucht zu viele Resourcen, z.B. Speicherplatz, Datenbankverbindungen, Plattenplatz.

Mit anderen Worten: obwohl traditionelle Vorgehensweise häufig davon ausgehen, das sich die ursprünglichen Anforderungen nicht ändern, so ergeben sich bei der Implementierung in der Praxis eben doch Änderungen, die dann berücksichtigt werden müssen.

Der XP Ansatz

Die Problematik nachträglicher Änderungen verschwinden bei der Verwendung von XP nicht. Im Gegenteil geht XP davon aus, daß solche Änderungen der Normalfall sind. In Verbindung mit dem Grundsatz immer den geringstmöglichen Aufwand zu betreiben erstellen XP Programmierer immer nur das minimal mögliche Design. Über die Zeit wird das Design weiterentwickelt, so daß mit der Zeit genau das Design entsteht, daß für das System ausreichend ist. Der XP Programmierer spricht dann auch von schlichtem Design. Die Erfahrung zeigt, daß man in der Regel damit auch das optimale Design hat.

Wie entsteht nun dieses schlichte Design? Ein Beispiel aus der Praxis soll dies deutlich machen.

Für ein Web Portal wird als erstes die Startseite erstellt. Getestet wird mit dem Microsoft Internet Explorer. Die Seite ist fertig erstellt. Sie wird repräsentiert durch eine Klasse "index" (Hinweis: Die Basisklasse stammt aus dem .NET Framework):

switch( Request.Browser.Browser ) {
case "Netscape":
// ... Anpassungen für Netscape
break;

case "Opera":
// ... Anpassungen für Opera
break;

}

void index::Page_Init() {

browserFilter.FixupPage();

}

Auch damit sind wir noch fertig. Bis jetzt haben wir nur den Code für die Brower-spezifischen Anpassungen in die jeweilige Filterklasse ausgelagert. Den 'switch' sind wir noch nicht losgeworden.

Eine neue Basisklasse

Für diesen Zweck, und weil wir die einer Klassenbibliothek entnommene Klasse nicht modifizieren können (wollen), führen wir eine neue gemeinsame Basisklasse ein:

In dieser Klasse bauen wir jetzt den 'switch' in den Konstruktor ein. Dadurch entfällt diese Stück Code bei allen abgeleiteten Klassen. Weiterhin führen wir ein Attribut ein als Verweis auf den verwendeten Browser. Als Ergebnis ergibt sich dann folgendes Bild:

Das ganze läuft nun so ab: Wenn eine Instanz von 'index' oder 'links' erzeugt wird, so wird auch der Konstruktor der Basisklasse 'webBrowser' ausgeführt. In diesem wird geprüft, welcher Browser verwendet wird, und es wird eine dazu passende Instanz von 'DefaultFilter', 'NetscapeFilter' oder 'OperaFilter' erzeugt. Wenn nun die Seite initialisiert wird, wird von der Seite die Methode BrowserFilter.FixupPage() polymorph aufgerufen, mit dem Resultat, daß die genau richtige Anpassung vorgenommen wird.

Entwurfsmuster "Strategy"

'BrowserFilter', die abgeleiteten Klassen sowie die Methode 'FixupPage()' stellen eine Anwendung des Entwurfsmusters "Strategy" dar. Dies ist damit auch ein Beispiel dafür, daß Entwurfsmuster auch ihren Platz im Rahmen von XP haben.

Weitere Informationen zu Entwurfsmuster (Design Patterns) findet sich in der einschlägigen Literatur (siehe Bücher). Das "Strategy"-Entwurfsmuster wird in GOF detailliert beschrieben.

Vorteile

Der erste Vorteil, der ins Auge fällt, ist, daß die wesentlichen Konzepte sauber getrennt sind. Weiterhin gibt es kein Stück Code, das doppelt existiert. Und schließlich ist deutlich zu erkennen, daß problemlos weitere Seiten oder weitere BrowserFilter hinzugefügt werden können, ohne daß existierender Code geändert werden müßte (mit Ausnahme des 'switch' im Konstruktor der Klasses 'webPage').

Tipps

• Immer nur einen Schritt auf einmal machen (Piecemeal Growth).
• Immer nur soviel Design wie unvermeidlich.
• Designänderungen gibt es sowieso, also den Prozess gleich danach ausrichten.