Gibt es in der objektorientierten Softwareentwicklung eine Pattern Language?

Nach meinem letzten Blogpost zur Relevanz von Design Patterns in der objektorientierten Softwareentwicklung stellt sich für mich die Frage nach den Beziehungen dieser Entwurfsmuster untereinander. Konkret geht es mir darum, wie die Entwurfsmuster in ihrer Anwendung kombiniert werden und ob man auch in der objektorientierten Softwareentwicklung von einer Pattern Language sprechen kann, wie sie Christopher Alexander für die Architektur entwickelt hat.

Alexander weist in A Pattern Language deutlich darauf hin, dass ein einfaches lineares Aneinanderreihen von Mustern nicht zur Entstehung von „profunden“ Gebäuden führt.

„It is possible to make buildings by stringing together patterns, in a rather loose way. A building made like this, is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together in such a way that many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound.“

Bereits hier zeigt sich die Komplexität der Pattern-Theorie: Einerseits gibt Alexander step-by-step-Anleitungen, wie Patterns eines nach dem anderen verwendet werden, um ein Gebäude zu schaffen. Andererseits jedoch betont er die Notwendigkeit, Raum für Kreativität zu lassen sowie die unabdingbare Fähigkeit des Architekten, die Bedürfnisse und Gewohnheiten der Menschen zu kennen und zu verstehen, um ein „sinnvolles“ Gebäude überhaupt schaffen zu können. Insgesamt geht es also immer darum, die Muster richtig, kreativ und sinnstiftend zu kombinieren, um ein Ergebnis zu erhalten, das den äußeren Gegebenheiten sowie den Wünschen der Menschen entspricht (welche ihnen nebenbei bemerkt gar nicht unbedingt bewusst sein müssen).

Gemeinsamkeiten und Unterschiede zweier Pattern-Ansätze
Die Entwurfsmuster von Alexander und die Design Patterns im Katalog der „Gang of Four“ haben Gemeinsamkeiten und unterscheiden sich gleichzeitig in bestimmten Aspekten.

Gemeinsam ist den Entwurfsmustern in der Architektur und jenen in der objektorientierten Softwareentwicklung, dass es stets um die Beschreibung bestehender Systeme geht und darum, dort nach Patterns zu suchen. In beiden Bereichen werden praktische Beispiele möglichst detailliert beschrieben. Diese bilden die Grundlage für die Entwicklung der Muster, welche so jeweils nicht nur theoretisch, sondern auch praktisch rational begründet werden können. Weiters liegt den Alexander’schen wie auch den Design Patterns eine klar definierte Struktur zugrunde.

Alexander vs. GoF
Allerdings gibt es auch in entscheidenden Punkten Unterschiede. Diese ergeben sich zunächst allein aufgrund des jeweiligen Fachbereichs: Menschen bauen seit Jahrtausenden Gebäude und es gibt eine Vielzahl an architektonischen Strömungen, Beispielen und Erfahrungen. Die Objekte, auf welche sich die Patterns in der Architektur beziehen, sind also nicht erst kürzlich entstanden, sondern haben sich im Lauf der Menschheitsgeschichte entwickelt. Die objektorientierte Softwareentwicklung hingegen ist kein derart über die Zeit gewachsener Fachbereich. Objekte, die als „Klassiker“ wie in der Architektur gelten, gibt es bisher nicht. Aufgrund der schnellen technologischen Weiterentwicklung scheint es auch fraglich, ob es solche überhaupt in unveränderbarer Form geben wird.

Die Alexander’schen Entwurfsmuster konzentrieren sich auf die architektonischen Probleme, die gelöst werden sollen. Diese werden im Detail beschrieben, woraus sich des Weiteren auch im eigentlichen Sinne erst der Kontext ergibt, in welchem das jeweilige Pattern anzuwenden ist, sowie die Lösung.
Bei den Design Patterns in der objektorientierten Software liegt der Fokus hingegen auf der Lösung des Problems, das man als Ziel vor Augen hat. Dennoch ist bei der Beschreibung der Muster nicht so sehr entscheidend, was getan wird, sondern warum es getan wird. Erst dann können Menschen, welche bisher keine Erfahrung mit den Patterns haben, sie verstehen und begreifen, warum sie wichtig sind.

Alexander gibt eine Reihenfolge vor, in welcher seine Patterns benutzt werden sollen, um so ganze Gebäude errichten zu können (natürlich darf auch hier wieder nicht auf Kreativität und Wünsche der Menschen vergessen werden). In der objektorientierten Softwareentwicklung gibt es das nicht und es wird auch nicht behauptet, mit den Entwurfmustern ganze Systeme generieren zu können. Eine Schritt-für-Schritt-Anleitung bei der Anwendung von Design Patterns sieht die GoF in der objektorientierten Softwareentwicklung als mehr oder weniger unmöglich an:

„Given the variety of software systems that people build, it’s hard to see how we could provide a ‚complete‘ set of patterns, one that offers step-by-step instructions for designing an application.“

Gibt es in der objektorientierten Softwareentwicklung eine Pattern Language?
Die Beantwortung dieser Frage wird für mich aus den oben zusammengefassten Unterschieden zwischen Entwurfsmustern in der Architektur, die eine Pattern Language bilden, und den Design Patterns in der objektorientierten Softwareentwicklung klar: Nein, in der objektorientierten Softwareentwicklung gibt es (bisher) keine Pattern Language! Weil: Die objektorientierte Softwareentwicklung sich sehr sehr rasch verändert und es damit schwierig wird, übergeordnete Muster zu entwickeln und festzuhalten, die so flexibel sind, dass sie jegliche technologischen Veränderungen „mittragen“ können. Weil: Es in der objektorientierten Softwareentwicklung ganz dezidiert um die Lösung von Problemen geht – ein schneller, einfacher und leicht verständlicher Weg wird eingeschlagen, um an das Ziel zu gelangen. Nicht immer besteht der Anspruch bei der Entwicklung der Entwurfsmuster, Allgemeingültigkeit zu erreichen – sie müssen einfach nur funktionieren! Weil: Es zwar in der Architektur möglich ist, eine Gebäude mittels der Pattern Language zu errichten. (Das funktioniert gleich, wie in der Sprache aus einzelnen Wörtern, ihren Beziehungen zueinander und der Grammatik richtige und sinnvolle Sätze gebildet werden.) In der objektorientierten Softwareentwicklung ist es aber nicht möglich, sich bei der Muster-Anwendung an bestimmte Regeln zu halten und damit ein ganzes System zu generieren.

Christopher Alexander hat festgestellt, dass die Entwurfsmuster der GoF zwar in Beziehung zueinander stehen. Er betonte jedoch, dass sie seiner Meinung nach „an assembly of patterns“ blieben. Und die GoF selbst schließen die Möglichkeit aus, dass es in der Softwareentwicklung insgesamt jemals eine Pattern Language geben kann: „Design patterns are just a part of a larger pattern language for software.“ Die Entwicklung einer solchen für eine bestimmte und fest definierte Klasse an Applikationen, wie z.B. Report-writing oder Form-entry systems, halten sie jedoch für machbar.

Beziehungskiste
Dennoch soll nun nicht der Eindruck erweckt werden, dass es sich in der objektorientierten Softwareentwicklung um eine lose, unzusammenhängende und willkürlich gebildete Sammlung an Mustern handelt. Die besten Designs enthalten viele Design Patterns, die ineinandergreifen und verzahnt sind, um ein größeres Ganzes zu generieren. Auch wenn die objektorientierte Softwareentwicklung bisher noch keine Pattern Language aufweisen kann, gibt es doch interessante Vorschläge zur Kategorisierung und Hierarchisierung der Entwurfsmuster sowie deren Beziehungen untereinander, um sie leichter, schneller und verständlich anwendbar zu machen (dazu beim nächsten Mal mehr).

Für mich ist entscheidend herauszufinden, wie die Pattern-Konzepte in den einzelnen Fachbereichen konzipiert sind, wozu sie konkret dienen und wie mit der Anwendung der Entwurfsmuster in der Praxis Probleme gelöst werden. Ich hoffe, dadurch das „Wesen“ von Patterns insgesamt begreifen zu können, und durch das Verständnis, warum und wie sie angewendet werden, so weit zu gelangen, selbst Entwurfsmuster für die Webkommunikation bzw. für Social Content entwickeln zu können.

Literaturhinweis:
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley 1995. ISBN 0-201-63361-2.
Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press. New York 1977. ISBN 0195019199.

Warum Design Patterns für die Softwareentwicklung wichtig sind

Schon im Rahmen meiner Diplomarbeit habe ich mich mit der Pattern-Theorie von Christopher Alexander beschäftigt und diese auf die Web-Kommunikation von Unternehmen angewandt. Es hätte den Umfang der Arbeit gesprengt, detailliert auf andere als den originären Pattern-Anwendungsbereich der Architektur einzugehen – dies möchte ich nun nachholen.

Bei einer Recherche über die Pattern-Theorie und deren Anwendungsgebiete kommt man an der Softwareentwicklung nicht vorbei. Dort erfüllen Design Patterns mehrere wichtige Funktionen und dienen dazu, die Arbeit von Entwicklern zu erleichtern. Als „novice“ auf diesem Gebiet habe ich mir das Buch „Design Patterns“ der „Gang of Four“ (GoF) vorgenommen und begonnen, mich einzulesen (übrigens auch für Leute, die sich nicht mit Softwareentwicklung beschäftigen, empfehlenswert und verständlich – zumindest abschnittsweise!).

Das Buch beschäftigt sich mit „design patterns that describe simple and elegant solutions to specific problems in object-oriented software design“. Sinn und Zweck ist es, die Rolle von Design Patterns bei der Generierung und Gestaltung komplexer Systeme zu erklären. Weiters stellt die GoF auch einen Katalog von 23 Patterns zur Verfügung, welche direkt von Entwicklern einsetzbar sind. Dabei legen sie auf die Feststellung Wert, dass es sich dabei nicht um eine taxative Aufzählung handelt, sondern um eine sich ständig verändernde und weiterentwickelnde Sammlung.
Die für mich interessantesten Erkenntnisse sind folgende:

Reusability and Flexibility
Designs in der Softwareentwicklung müssen auf spezifische und aktuelle Probleme eingehen, aber auch auf zukünftige Probleme und Notwendigkeiten muss geachtet werden. Denn eine wichtige Voraussetzung für erfolgreiches Design ist, dass es „reusable and flexible“ ist.
Design Patterns benennen, erklären und bewerten wichtige und wiederkehrende Designs in der Softwareentwicklung. Es geht darum, bereits gemachte Erfahrungen in einer abstrahierten Form zur Verfügung zu stellen, die für die Menschen hilfreich und nutzenstiftend ist.

Die GoF beschreiben Design Patterns als „descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context“.

Konserviertes Wissen
Design Patterns enthalten Lösungen für bereits früher aufgetauchte Probleme, die im Laufe der Zeit entwickelt wurden und auf die im betreffenden Kontext immer wieder zurückgegriffen werden kann. In den Entwurfsmustern ist schnell abrufbares Wissen konserviert; es ist nicht nötig, den Problemlösungsprozess wieder bei Null zu starten. Dabei handelt es sich häufig um implizites Wissen, welches erfahrene Softwareentwickler unbewusst bei ihrer täglichen Arbeit einsetzen. Experten sind deshalb Experten, weil sie immer wieder bereits bekannte Lösungen anwenden. Die Entwurfsmuster machen dieses Know-how explizit und beschreiben es im Detail. So sind Design Patterns vor allem für „Neulinge“ hilfreich.

Praxisbezug und Abstraktion
Prozesse der praktischen Tätigkeit der Softwareentwicklung werden durch und in Patterns abstrahiert und damit im jeweiligen Kontext allgemeingültig gemacht. Hier zeigt sich der enge Praxisbezug, welcher von großer Bedeutung in allen Anwendungsgebieten des Pattern-Konzepts ist. Meist werden aus praktischen Beispielen Gesetzmäßigkeiten oder „Regeln“ abgeleitet, detailliert beschrieben und „in die Pattern-Form gegossen“.
Viele Softwareentwickler kennen eine große Zahl an Design Patterns, allerdings nur in Form von existierenden Systemen – hier sind wir wieder beim Punkt des impliziten Wissens. Durch die Abstraktion dieses Wissens entstehen Design Patterns, die auch von Entwicklern anwendbar sind, die bisher noch keine praktischen Erfahrungen im jeweiligen Bereich gemacht haben.

Veränderung des Vokabulars
Weiters vereinfachen Design Patterns in der Softwareentwicklung die Kommunikation über fachliche Inhalte. Statt ein Problem, einen Prozess oder einen Zustand erklären zu müssen, wird einfach der Name eines spezifischen Patterns herangezogen. Teilen die Beteiligten den Sinn und die Bedeutung dieses Begriffs, teilen sie auch das Wissen darüber, was damit gemeint ist. Es ist also nicht mehr nötig, lange inhaltliche Erklärungen zu liefern – die Kommunikation wird durch die Entwurfsmuster und die ihnen immanenten Bedeutungen schneller, einfacher und weniger störungsanfällig.

„Design patterns provide a common vocabulary for designers to use to communicate, document, and explore design alternatives. Design patterns make a system seem less complex by letting you talk about it at a higher level of abstraction than that of a design notation or programming language. Design patterns raise the level at which you design and discuss design with your colleagues.“

(Hier sehe ich nebenbei bemerkt eine bedeutende Schnittstelle zur Ethnomethodologie, welche im Zusammenhang mit dem Projekt WLL für mich interessant ist.)

Patterns als Lernhilfe in der Softwareentwicklung
Wie gesagt sind Design Patterns besonders für solche Entwickler hilfreich, die noch keinen großen Erfahrungsschatz haben, da sie für häufig auftretende Designprobleme in spezifischen Kontexten konkrete Lösungen bieten. Durch die Kenntnis von Design Patterns ist es einerseits leichter, bestehende Systeme zu verstehen. Andererseits helfen die Entwurfsmuster natürlich auch bei der Entwicklung eigener Systeme. Die Reduktion von Komplexität steht hier im Vordergrund.

Erstes Fazit
Insgesamt ist dies nun mein erstes persönliches Fazit über die Funktionen von Design Patterns in der Softwareentwicklung: Wie bereits im Rahmen meiner Diplomarbeit stelle ich fest, dass Patterns eine gute Möglichkeit sind, flexible und dennoch allgemeingültige „Regeln“ zu erstellen. Durch die Abstrahierung von praktischen Gegebenheiten und Beispielen werden Patterns entwickelt, die wiederum durch ihre Anwendung Komplexität reduzieren. So können auch Anfänger auf die Erfahrungen von Profis zurückgreifen. Dies wird dadurch noch unterstützt, dass in der Softwareentwicklung keine außerordentlichen Programmierkompetenzen zur Implementierung von Patterns nötig sind. Und gegenüber Ad-hoc-Lösungen muss natürlich in der Softwareentwicklung der Vorteil der Flexibilität und Wiederverwendbarkeit von Systemen hervorgehoben werden: Durch Design Patterns werden Designs flexibler, modular (baukastenartig), wiederverwendbar und verstehbar – was auch Sinn und Zweck objektorientierter Software ist.

Literaturhinweis:
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley 1995. ISBN 0-201-63361-2.