Eines ist mir heute aufgefallen: es gibt eine Reihe von Büchern, die sich mit den unterschiedlichsten Pattern beschäftigen. Mittlerweile beschäftigt man sich nicht nur mit Architekturpattern sonder eben auch mit Prozessmustern in der Softwareentwicklung oder gerade den Verhaltensmustern von Menschen. Das sind alles interessante und auch wichtige Themen um insbesondere auch als Software Entwickler, Ingenieur oder Architekt die Schemata der sozialen Interaktion zu erkennen.
Doch in den letzten Tagen habe ich festgestellt, dass auch im Umfeld der Implementierung, der einfach Codierung fachlicher Anforderungen, immer wieder neue Pattern erkannt werden können. Sie sind vielleicht nicht immer ganz neu, aber sie stellen eine kreative und effiziente Anwendung bekannter Ideen dar.
Hier zeigt sich meiner Meinung nach, dass das Ausprobieren neuer Konzepte in den dynamischen Programmiersprachen (zum Beispiel Ruby, Python, Clojure) auch einen Paradigmenwechsel zur Folge haben. Diese neuen Paradigmen sind jedoch nicht nur in diesen neuen Umgebungen Teil des Werkzeugkastens der Entwickler. Sie lassen sich genauso gut auch in die etablierten Sprachen übertragen.
Aktuell wird durch den GCC für Apples Objective-C mit den Blocks und der Bibliothek Grand Central Dispatch ein neues Muster auch in die Syntax der Programmiersprache übertragen. Doch mit anonymen inneren Klassen kann ein sehr vergleichbares Konzept auch in Java implementiert werden.
Plötzlich kann auch in einer herkömmlichen Programmierumgebung ein Problem anders betrachtet und eine erstaunlich einfache Lösung präsentiert werden!
Natürlich führt die fehlende syntaktische Unterstützung eines neuen Paradigmas in der Programmiersprache dazu, dass die Prägnanz im Ausdruck reduziert wird. Aber ich glaube nicht, dass der Umfang des notwendigen Programmcodes das eigentliche Problem darstellt. Es ist stattdessen der Mangel an Transparenz, der eine Gefahr für die Wartbarkeit des Softwareprodukts bedeutet. Der Blick auf die für die Lösung des Problems notwendigen vielen Zeilen Code verstellt dann die Sicht auf die Lösungsidee, die dahinter steckt.
Das bedeutet aber nicht, dass wir uns von dem Gedanken verabschieden sollten, in C oder Java neue Konzepte aufzunehmen und in der täglichen Arbeit zu nutzen. Anstatt einfach den Kopf in den Sand zu stecken sollten diese neuen Konzepte so dokumentiert und geschult werden, dass sie auch im Gewimmel des für die Realisierung notwendigen Java-Codes von allen Entwicklern wiedererkannt werden können.
Denke ich zurück an die ersten Pattern, die ich kennengelernt habe und die ich und meine Kollegen dann auch wiederholt eingesetzt haben, fällt mir sofort Singleton, Factory und natürlich auch Visitor ein. Sie waren großartig, sind aber zum Teil auch schon in die Jahre gekommen. Singleton wird nun eigentlich schon in vielen Fällen als Anti-Pattern gesehen. Alle diese Pattern sollten daher eigentlich einmal wieder neu betrachtet und bewertet werden. Dazu sollte man die vielen neuen Konzepte, also etwa Closure oder Block und das Template mit einer beispielhaften Implementierung aufnehmen. Es ist dringend Zeit, denn Singleton ist als einziges Pattern sicherlich nicht ausreichend.
Wer also mag sich wieder auf die Ursprünge der Pattern-Forschung besinnen und präsentiert uns nun neue Versionen grundlegender Implementierungsmuster?