Wer mit Software-Entwicklung zu tun hat, denkt bei dem Wort „Entwurfsmuster“ fast automatisch an die Gang of Four und die Beschreibung der 23 Entwurfsmuster in ihrem Buch „Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software“. Wer nicht mit Software-Entwicklung zu tun hat: Bei Entwurfsmustern handelt es sich um eine Art Schablone, wie man wiederkehrende Probleme in der Software-Entwicklung lösen kann. Es gibt Tausende von Entwurfsmustern, 1994 haben vier Entwickler, die sogenannte Gang of Four, ein Buch verfasst, welches die in ihren Augen 23 am häufigsten genutzten Entwurfsmustern enthält. Dass es noch mehr gibt als diese 23 Entwurfsmuster zeigt Matthias Geirhos in seinem Buch „Entwurfsmuster – Das umfassende Handbuch“.
Was steht drin?
Das umfassende Handbuch zum Thema Entwurfsmuster beschäftigt sich entgegen des Titels nicht allein mit Entwurfsmustern im herkömmlichen Sinne. Diese nehmen mit über 300 Seiten zwar einen Großteil des Buches ein, sind aber nicht allein für den Inhalt verantwortlich.
Dabei ergänzt der Autor Matthias Geirhos die 23 Entwurfsmuster der Gang of Four zusätzlich noch um das Multiton- und das Interceptor-Muster. Danach geht er auf Architekturmuster ein, die sich aber allein auf verteilte Systeme wie SOA (Service-orientierte Architekturen) beziehen. Strukturelle Architekturmuster wie Pipes und Filter oder Blackboard werden nicht erwähnt.
Der Teil der Datenmuster bezieht sich vor allem auf Datenbanksysteme, obwohl sich die dort erwähnten Verfahren und Probleme in ähnlicher Weise auch auf Multithreading-Systeme anwenden lassen. So kann man auch dort mit optimistischen und pessimistischen Sperren arbeiten und die Probleme von Lost Updates, Dirty Reads, Non-Repeatable Reads, Phantom Reads und natürlich Deadlocks ergeben sich auf ähnliche Weise.
Bei den GUI-Muster werden hauptsächlich Model-View-Controller (MVC), Model-View-Presenter (MVP) und Model-View-ViewModel (MVVM) erklärt, die aber alle sehr ähnlich sind.
Das letzte Teil 8 beschäftigt sich mit Design- und Entwicklungsprinzipien, in denen Geirhos unter anderem auf SOLID, das Agile Manifest und Design Smells und Anti-Pattern eingeht.
Wie liest es sich?
Die Entwurfsmuster sind alle klar strukturiert und in der Regel auch ausführlich gehalten. So folgen auf die Beschreibung in UML und Text die Anwendungsfälle und die Implementierung des Musters in Java – und manchmal C#. Abgeschlossen wird ein Kapitel immer mit weiteren Überlegungen und Alternativen zu den Mustern.
Vor allem die weiteren Überlegungen sind sehr hilfreich, da Geirhos oft sehr ausführlich die Vor- und Nachteile beschreibt, die mit den Mustern in der Praxis auftreten können.
Die Beispiele für die Umsetzung der Entwurfsmuster sind dabei meist der Realität und Projekten entnommen, an die der Autor gearbeitet hat. Es ist aber wahrscheinlich Geschmackssache, ob man beispielsweise das Decorator-Muster mit Kaffee oder Pizza (wie im Buch „Head First Design Patterns“) oder mit einem „realen“ Beispiel mit einem Vertrag, der verschlüsselt wird, erklärt bekommen möchte.
Was mitunter problematisch sein kann, ist, dass der gesamte Beispielcode und auch die Entwurfsmuster in Deutsch erklärt werden. So wird aus der „Chain of Responsibility“ eine „Zuständigkeitskette“ oder aus der „Template Method“ die „Schablonenmethode“. Diese Begrifflichkeiten sind mitunter etwas befremdlich, vor allem, wenn man sich mit anderen Entwicklern unterhält. Hier wäre Englisch als einheitliche Informatik-Sprache besser geeignet, um Missverständnisse zu vermeiden.
Vor allem der deutschsprachige Beispielcode liest sich seltsam:
public BestellContext ( String bestelldaten, Date dateTimeStamp,
boolean isVerschluesselt )
Dieses Schema findet man sicherlich in einigen Projekten, bei den meisten Firmen und auch in den meisten Open-Source-Projekten hat sich Englisch als beschreibende Sprache durchgesetzt, was den Austausch auf internationaler Ebene natürlich erleichtert. Problematisch ist die Verwendung von deutschen Begriffen auch für das Lektorat, denn so wird durch die Korrektur des Buches aus public void kuendigen(...) im Fließtext eine „kündigen“-Methode (S.65).
Ein weitere Eigenart des Autors, an die man sich erst gewöhnen muss, ist, dass in vielen Mustern ein Interface (z.B. „Erzeuger“) eine Basisklasse zurückliefert (hier „Produkt“), die konkrete Klasse „KonkreterErzeuger“ liefert aber plötzlich ein „KonkretesProdukt“. Das heißt, die Signatur der überladenen Methode passt in Interface und Realisierung nicht mehr zusammen. Dies findet man in allen UML-Diagrammen, die im Buch verwendet werden (S.51, S.79 etc.). In dem darauf folgenden Code wird die Methode der Schnittstelle/Basisklasse in der konkreten Klasse glücklicherweise korrekt implementiert – da sonst auch der Quellcode nicht übersetzen würde.
Ganz fehlerfrei ist das Buch leider insgesamt nicht. Manchmal sind es nur kleinere Fehler, sodass ein „I“ im Interface vergessen wird (S.105) oder eine Bildunterschrift nicht passt (S.509). Etwas verwirrender ist, wie oben erwähnt, wenn UML und Code nicht zusammenpassen. Manchmal ist es dabei auch nur, dass die Groß-/Kleinschreibung nicht passt (S.120/122) oder Interfaces nicht korrekt bezeichnet werden (S.337). Man merkt hieran, dass es für die zweite Auflage noch Verbesserungspotential gibt, auch wenn natürlich im Ganzen gesehen die Fehler eher kleinerer Natur sind und auch nicht massiv auf jeder Seite auftauchen.
Ein Fauxpas ist (aus Design-Sicht) aber eigentlich nicht zu entschuldigen. So wird im Teil zu Design-Prinzipien auch das Gesetz von Demeter erwähnt (S.596). Dort wird gesagt, dass ein Objekt M auf die Methoden der Bestandteile von M, der Argumente von Methoden von M, der von M erzeugten Objekte und von globalen Variablen zugreifen darf. Gerade der letzte Punkt ist aber falsch und eine Verstoß gegen das Gesetz. Glücklicherweise wird eine Seite später bei der ausführlichen Erklärung korrekt erklärt, dass man nicht auf globale Objekte zugreifen soll.
Fazit
Trotz der kleineren Fehler, die eben aufgelistet wurden, ist das Entwurfsmuster-Buch von Matthias Geirhos ein sehr gutes und aktualisiertes Nachschlagewerk für verschiedene Entwurfsmuster, wobei der Begriff vom Autor entsprechend weit aufgefasst wird, was aber nicht schlimm ist. Sicherlich sind nicht alle Teile für jeden interessant, da nicht jeder Entwickler mit Service-orientierten Architekturen oder GUI-Entwicklung zu tun hat, aber als Anreiz zur Weiterbildung sind diese Kapitel selbst für solche Personen interessant.
Der Schreibstil des Autors ist dabei auch locker und nicht zu trocken, was manch einen beim Buch der Gang of Four ggf. gestört hat. Und so gibt es am Ende noch ein schönes Zitat, was die Entwicklung von Software-Systemen sehr gut beschreibt (aus dem Abschnitt zum Fassade-Pattern, S.171): „Komplexität ist ein Eichhörnchen. Bis man die Komplexität wahrnimmt, hat es schon viele Haselnüsse versteckt.“
