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.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s