Die ganze Welt nichts als Entwurfsmuster

Als Gamma et al. 1994 "Design Patterns" veröffentlichten, wurde nicht nur mir endlich klar, was objektorientierte Programmierung bedeuten kann. Vorher verstanden eigentlich nur die Wenigen, die das Glück hatten, mit Smalltalk programmieren zu dürfen, wie man ein Programm aus Objekten aufbaut. Gewiß, da war noch C++. Aber mal ehrlich, die am meisten genutzte Eigenschaft von C++ ist die Rückwärtskompatibilität zu C. Klassen werden meist nur zur groben Modularisierung gebraucht.

Jetzt nach 12 Jahren Java denken die meisten Softwarearchitekten nur noch in Mustern. Das ist an sich eine gute Sache. So wie der Unterschied zwischen einem Amateurschachspieler und einem Profi ist, daß der erste 64 Felder und (bis zu) 32 Figuren sieht und der letztere Positionen (Muster), so sieht der Programmieranfänger Klassen und der Erfahrene die Muster im Zusammenspiel der Klassen.

Leider gibt es aber auch Nebenwirkungen. Gamma erzählte einmal im Anschluß an einen Vortrag, daß er ein Erlebnis gehabt hätte, daß ihn daran zweifeln ließ, ob er mit seinem Buch Gutes geleistet hätte. Jemand hätte ihn um Rat gefragt. Die meisten der Muster hätte er in seinem Design schon untergebracht, aber für eines hätte er noch keine Verwendung gefunden.

In letzter Zeit hatte ich mit mehreren Systemen zu tun, bei denen die meisten Klassen schon in den Namen auf die verwendeten Patterns hinwiesen. So weit, so gut. Leider fehlten aber weitestgehend Klassennamen, die darauf hätten schließen können, wozu das System eigentlich gedacht war. Die einzige Ausnahme war die Datenzugriffsschicht, deren Klassen aber nur Datenbehälter waren ohne jede Funktion.

Hier läuft etwas grundsätzlich schief. Entwurfsmuster sind großartig, um Probleme zu lösen. Sie sind aber kein Selbstzweck. Ein Softwarearchitekt macht keinen besseren Job dadurch, daß er in seiner Architektur beweist, wieviele Entwurfsmuster er kennt.

Ein Problem mit derartigen Architekturen ist es, daß es sehr schwer ist, eine neue Anforderung unterzubringen. Die Anforderung wird wohl eher lauten, bei Kunden eine Überprüfung auf die Anwendbarkeit eines neuen Rabatts zu ermöglichen, als noch einen Listener um eine Factory zu ergänzen. Basiert die Architektur auf der Begriffswelt des Kunden, ist es sehr einfach die neue Anforderung zuzuordnen. Basiert die Architektur aber auf rein technischen Begriffen, geht dieser Zusammenhang verloren.

Die weitaus bessere Methode, zu einer guten Architektur zu kommen, ist es, mit der Fachlichkeit anzufangen und die fachlichen Anforderungen so zu implementieren, daß sie durch Modultests (JUnit o.ä) gesichert ist. Die technischen Anforderungen und Anbindungen können dann im zweiten Schritt dazuentworfen werden.

Natürlich leisten hierbei Entwurfsmuster gute Dienste. Aber die Anwendung eines Musters muß aus der fachlichen Anforderung resultieren.

Wie kommt es nun zu dieser Fehlentwicklung? Ich sehe hier mehrere Gründe:

• Manchmal liegt es sicher an einem problematischen Rollenverständnis des Architekten. Dieser meint sich von dem "gemeinen" Programmierer dadurch abheben zu müssen, daß er die Abstraktion soweit treibt, bis keiner mehr folgen kann.
• Häufiger liegt es jedoch daran, daß die fachlichen Anforderungen noch nicht hinreichend klar sind, wenn schon eine Architektur geliefert werden soll.
• In manchen Organisationen wird bewußt getrennt zwischen fachlichen und technischen Experten. Dies kann nicht gut gehen. Wenn der Architekt keinen Umgang mehr mit dem Kunden hat, so wird er nie dessen Sprache lernen. Die so entstehenden Anwendungen werden nicht mehr die gewünschte Fachlichkeit wiederspiegeln sondern sich in technischer Beliebigkeit auflösen.