Netzgeflüster: Design Pattern lernen (+Buch-Besprechungen ‚Gang of Four‘)

Heute wagen wir uns mal wieder in das Gebiet der Programmierung vor. Der Artikel handelt von Entwurfsmustern („Design Pattern“) der Programmierung und Softwareentwicklung und deren Sinn oder Unsinn, die quasi Standards der sogenannten Gang of Four und ich stelle zwei Bücher vor mit deren Hilfe ich mich an das Thema gewagt habe und erkläre wie hilfreich die waren. Meine weapon of choice was Programmiersprachen betrifft ist dabei Java.

Warum Design Pattern? Und warum ‚Gang of Four‘? Macht mein Leben auch ohne Design Pattern Sinn?

Unter Design Pattern bzw. Entwurfsmustern versteht man Programmierweisen und Konstrukte deren Benutzung für bestimmte Fälle von großem Vorteil sind. Als Design Pattern kann man Programmierweisen dann bezeichnen, wenn sie für einen speziellen, wiederkehrenden Fall der best approach sind, d.h. die beste Herangehensweise. Ein solches Design Pattern ist im Bereich der objekt-orientierten Programmiersprachen beispielsweise Singleton. Möchte ich eine Klasse genau ein einziges Mal instanziieren und nur dieses eine Objekt wiederverwenden, aber niemals ein zweites, dann kann ich Singleton anwenden. Ein solcher use case könnte eine Properties-Datei sein, die nicht öfter als ein Mal eingelesen werden darf. Beispielsweise um sicherzustellen, dass sich die Einstellungen aus der Properties-Datei nicht zur Laufzeit ändern und man immer auf dem spezifischen Stand eines bestimmten Zeitpunktes arbeitet. Singleton kann so realisiert werden, dass man eine nach außen sichtbare (public) Klasse hat, aber einen private Konstruktor. Somit kann das Objekt nicht (von außen) instanziiert werden. Eine statische Funktion public static getInstance() kann aber von außen aufgerufen werden und gibt das als private static final Klassenvariable deklarierte Objekt zurück. Dieses wird nur einmal als Klassenvariable instanziiert bei der ersten Nutzung der Klasse und eine Instanziierung ‚mit Gewalt‘ ist nicht möglich, da es keinen public Konstruktor gibt. Singleton ist ein Design Pattern, das von der sogenannten Gang of Four (GoF) definiert wurde.

Die Gang of Four sind Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides, deren Buch Design Patterns: Elements of Reusable Object-Oriented Software ein quasi-Standard geworden ist und Entwurfsmuster in das Bewusstsein der Programmierer gerückt hat oder viel mehr als Begriff in Stein gemeißelt hat. Dass bestimmte Techniken und Vorgehensweisen in manchen Fällen lohnenswert und unumgehbar sind, wird jedem Entwickler früher oder später in einem größeren oder kleineren Heureka-Moment aufgefallen sein. Und auch wenn die Design Pattern der Gang of Four (ca. 24 an der Zahl) sehr bekannt sind, so sind sie nicht der einzige Ansatz. Der Bekanntheitsgrad rührt v.A. daher, dass man die Design Pattern der GoF flächendeckend auf die meisten objekt-orientierten Programmiersprachen anwenden kann. Wie die Umsetzung im Detail aussieht variiert dabei natürlich syntaktisch. Im Buch der GoF waren die Beispiele in C++ und Smalltalk, wobei ich die Design Pattern speziell aus Java-Sicht gelernt habe. Was man also als Design Pattern erachtet ist nicht etwa vorgeschrieben. Prinzipiell ist es denkbar und auch wünschenswert, dass man sich über solche populären Muster hinaus Arbeitsweisen entwickelt, die für eine bestimmte Architektur der best approach sind. Auch wenn darüber noch kein Buch geschrieben wurde. Dann erst recht. Ein Leben ohne GoF ist möglich, arbeiten ganz ohne Entwurfsmuster und best approaches wäre aber mühselig und ineffektiv.

Review: ‚Java Design Pattern Essentials – Second Edition‘ von Tony Bevis

Tony Bevis Buch ist ziemlich auf den Punkt. Es werden alle Design Pattern der GoF vorgestellt und das ziemlich nach „Lehrbuch“, d.h. die Design Pattern werden nach Creational, Structural und Behavioral Pattern gegliedert und erklärt so wie es die GoF definiert haben. Dabei ist das Buch sehr schlicht gehalten und ohne viel Vorrede kann man sagen. Ein Text beschreibt für welche Szenarien man das Pattern braucht, es gibt ggf. ein Klassendiagramm und eine Beschreibung wie man das Pattern programmiert und anschließend ein Java-Code-Beispiel. Der Code wird dabei mit jedem Kapitel erweitert. Es ist also quasi dasselbe Code-Beispiel, nur dass es in jedem Kapitel wegen des Patterns variiert. Auto-Fans werden sich freuen, denn die Codeschnipsel und Klassen haben alle mit Autos, Motoren, etc zutun.

Das Buch ist also offensichtlich ziemlich straight forward, ohne viel Zusatz-Mist mit Sahnehäubchen. Allerdings wirkt es auch leider schlecht lektoriert. Es gibt einige Tippfehler, auch ein paar kleinere Fehler in den Klassendiagrammen oder hier und da wurde die falsche Klasse erwähnt. Außerdem scheinen manche Beschreibungen wofür man das Pattern braucht und wie man es implementiert nicht schlüssig, schwer nachvollziehbar oder beliebig. Wenn das Auto-Beispiel nicht viel hergibt, hätte man ruhig mal ein anderes wählen können, um den Sachverhalt deutlicher zu machen. Bei den wirklich großen und oft eingesetzten Pattern wie Factory, Singleton, Observer kann das Buch richtig was. Bei anderen Pattern scheitert es daran den Zweck zu erläutern und verständlich zu machen, warum dieses Pattern die Lösung aller unserer Probleme ist oder was daran smart ist. Dadurch, dass die Beschreibungen knapp und nicht immer auf den Punkt sind, würde ich das Buch eher zu Rate ziehen, wenn man ein Nachschlagewerk für die Pattern braucht und man ohne viel Bullshit das wichtigste nachschlagen will. Dafür kann man aber auch das große, weise WWW zu Rate ziehen, wenn wir ehrlich sein wollen. Das heißt aber auch nicht, dass es ein schlechtes Buch ist. Nur ist es eins, dass ich eher Programmierern mit einer schnellen Auffassungsgabe und viel Programmiererfahrung empfehlen würde.

Review ‚Head First Design Patterns‘ von Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Robson

Wenn man Design Pattern wirklich richtig gründlich verstehen, lernen und beherrschen will, dann ist Head First Design Patterns eine gute Wahl, erfordert aber auch, dass man einiges mehr an Zeit investiert. Das über 500 Seiten starke Buch widmet sich in Kapiteln die durchaus mal 30 Seiten oder mehr fassen einem Pattern. Dabei geht das Buch sehr gründlich vor. Es werden Probleme geschildert bei denen man das Pattern braucht, man tastet sich schrittweise an die letztendliche Lösung heran wie das Pattern umzusetzen ist, es gibt viele abstrakte Beispiele, die dann meistens zu Code-Beispielen führen und es wird abgegrenzt worin der Vorteil und Mehrwert des Patterns liegt im Gegensatz zu ähnlichen Vorgehensweisen oder anderen Pattern. Dabei ist das Buch spielerisch und witzig gehalten. Es gibt beispielsweise sehr viele Abbildungen und Gags (über die wahrscheinlich nur Informatiker lachen können 😉 ) und Übungen, die mal ganz anders sind als das was man üblicherweise in Coding-Lehrbüchern sieht, bspw. Kreuzworträtsel. Manche der Gags wirken ziemlich kindisch wie beispielsweise die „Interviews mit dem Design Pattern“, sind aber durchaus mal ganz lehrreich.

Alles in allem bietet das Buch eine Plattform um sich wirklich tiefergehend mit den Pattern zu beschäftigen. Ich bin der Überzeugung, dass nur etwas hängen bleibt, wenn sich dem Leser erschließt wofür genau das Pattern gut ist und warum das Pattern besser funktioniert als andere Ansätze. Das zu vermitteln gelingt dem Buch wirklich gut. Außerdem weist das Buch nicht nur schnöde auf die GoF hin, sondern stellt auch noch Verbesserungen der Ansätze vor. Allerdings sind die langen Kapitel manchmal auch ein Overkill und es fiel mir mitunter schwer ein Kapitel an einem Tag abzuschließen (gemessen daran, dass ich das manchmal nach einem langen Arbeitstag probiert habe). Was dieses Buch (bzw. die Buch-Reihe, denn es gibt noch mehr Head-First-Bücher) von anderen deutlich abhebt, ist dass es lebendig ist und viele Beispiele bietet. Es ist spielerisch und nicht so knochen-trocken wie viele andere Bücher über Coding. Was sehr schade ist: es wird nur ein Teil der Pattern so ausführlich besprochen. Eine ganze Latte von Pattern wird nur in Kurzform am Ende des Buches erklärt, wo es nochmal ein Nachschlagewerk mit den wichtigsten Eckdaten der Pattern gibt.

Beide Bücher im Vergleich

Die Bücher sind quasi wie Feuer und Wasser oder Tag und Nacht. Tony Bevis Buch ist ein klassisches, trockenes Coding-Buch, dass auf zuviel Bullshit und Herumgerede verzichtet. Head First Design Patterns ist ein spielerisches Buch mit lockerer Art, dass sich viel viel Zeit nimmt einem die Pattern von Grund auf zu erklären und für diesen Ansatz braucht man auch als Leser ordentlich viel Zeit. Das bessere Ergebnis bekommt man meines Erachtens also, wenn man sich mit Head First Design Patterns auseinandersetzt, was wiederum leider nicht alle Pattern so ausführlich behandelt. Für Einsteiger, die noch nicht Java-Profis sind, ist Head First Design Patterns trotzdem die bessere Wahl, da es die Java-Konzepte mit erklärt. Tony Bevis Buch richtet sich durch seine knappen Erklärungen eher an Programmierer, die erstens schon sehr solide Java-Kenntnisse haben und zweitens vielleicht sogar schon ein Verständnis dafür entwickelt haben wie man strukturell und architektonisch sinnvoll und clean arbeitet.

Und was kommt danach?

Hier die schlechte Nachricht: wenn man Design Pattern nicht anwendet, hat man wahrscheinlich direkt vergessen, was man lernt. Oder man hat sie nicht kapiert bzw. die Lernhilfen scheitern daran zu erklären wann und wie man sie anwendet. Das ist die andere Möglichkeit. Selbst wenn das passieren sollte, hat man zumindest einen großen Mehrwert: man hat sich mit dem effektiven Lösen von programmiertechnischen Problemen auseinandergesetzt und entwickelt ein Bewusstsein dafür wie man seine tools richtig einsetzt. Es ist also lohnenswert, selbst wenn man vergessen hat wie das Bridge oder Mediator Pattern funktioniert. Generell würde ich aber trotzdem empfehlen die Pattern für eine Programmiersprache zu lernen, die man gerade ständig im Einsatz hat um wirklich das Bewusstsein zu schärfen und die Pattern idealerweise direkt anzuwenden. Gang of Four ist auch nicht das Maß aller Dinge. Es kann sein, man bewegt sich in einem Kontext, in dem andere Verhaltensweisen wichtiger werden. So ähnlich ist es auch in meinem Fall und die GoF-Design-Pattern haben mein Leben nicht verändert um ehrlich zu sein, aber durchaus mein Bewusstsein geschärft. In naher Zukunft werde ich mich wahrscheinlich eher mit Martin Fowlers Patterns of Enterprise Application Architecture auseinandersetzen oder einem anderen Buch, das sich mehr mit JavaEE auseinandersetzt.

Was habt ihr für Empfehlungen was Design Pattern Lehrwerke betrifft? Gibt es gute Online-Schulungen, die ihr empfehlen könnt? Oder sagte euch das Thema bisher noch gar nichts? Haltet ihr Design Pattern für gewinnbringend? Oder die GoF-Pattern sogar für überholt?

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen rund um IT, Forschung, Netzwelt, Internet und eben auch Gerüchten widme. 🙂

9 Antworten

  1. „Macht mein Leben auch ohne Design Pattern Sinn?“ 😀 Haha, geniale Überschrift. Danke fürs Feierabend-Versüßen – und Einblicke in ein Themenfeld, von dem ich absolut null Ahnung habe. 🙂

    1. Avatar von Miss Booleana
      Miss Booleana

      Haha, danke – freut mich, dass die gut ankommt und der Artikel trotzdem lesbar ist, auch wenn es nicht dein Thema ist 😀 Das finde ich übrigens klasse, dass du trotzdem draufschaust. Wenn ich eins gelernt habe (durch den Multi-Themen-Blog), dann dass die Leserschaft normalerweise sehr selektiert und manche Themen keines Blickes würdigt XD

  2. Ich hatte mich für das Original der GoF entschieden und halte es für ein sehr gutes Buch was mir auch zum Nachschlagen gut geeignet erscheint. Wenn ich neue Komponenten entwerfe, dann tue ich das ab und zu auch.

    Als Softwareentwickler sollte man den Schritt schaffen von einer auf Funktionen beschränkten Programmierweise (bei der man üblicherweise auch in einer objektorientierten Sprache beginnt) hin zu einer Struktur und Kapselung orientierten, wart- und erweiterbaren Programmierweise. Im Grunde ist denke ich „Separation of concerns“ das, was gut struktierten Code auszeichnet. Die Objektorientierung bietet komfortable Mechanismen dafür an und der größte Mehrwert des Studiums von Design Patterns liegt meiner Meinung nach im Training wie man Concerns an Objektgrenzen sinnvoll trennen kann. Außerdem liefert es mächtigere und einheitliche Vokabeln für die Beschreibung von Design und Architektur.

    Oft bieten bereits Libraries und Frameworks bereits Funktionen die das Implementieren einiger klassischer Patterns überflüssig machen, wobei die Kenntnis der Pattern einen auch beim Verwenden der Funktionalität oft noch nützlich ist. Und besonders die komplizierteren Patterns wie z.B. Visitor sind schon allein ihrer selbst willen sehr wertvoll – zumindest mir würde das wohl nicht ohne weiteres in den Sinn gekommen.

    1. Avatar von Miss Booleana
      Miss Booleana

      Ja, da hast du recht – wenn man von den prozeduralen zu den objektorientierten Sprachen wechselt, werden Pattern plötzlich enorm wichtig durch die Modularität. Allerdings habe ich auch den Eindruck, dass mit diesen Sprachen plötzlich die Menge an Tools und Techniken explodiert und man eine Weile braucht bis man Kapselung, Sichtbarkeiten, Polymorphismus etc verinnerlicht hat. Und bevor einem das nicht etwas ins Blut übergeht, kann man wahrscheinlich Design Pattern schwer nachvollziehen. Zumindest erging es mir so als ich schon Mal vor vielen Jahren Pattern lernen wollte. Ich denke, wenn man das dann aber richtig beherrscht, dann kommt es gar nicht so sehr darauf an, ob man die GoF-Pattern beherrscht, sondern kann sich eigene Gedanken machen, was für einen selber sinnvoll. Aber ich muss dir auch dahingehend recht geben, dass mir solche komplexen Pattern die Visitor und viele andere unter Garantie nicht selber eingefallen wären.

      Und ja die in APIs aus Pattern implementierten Interfaces sind mir auch schon begegnet, bspw. Observer und Iterator in Java. Das war ein schöner Aha-Effekt, da ich die Interfaces kannte bevor ich über Design Pattern gelesen habe.

      1. Ich teile die Einschätzung, dass ein Verständnis von Modularität und die Fähigkeit Abläufe im Allgemeinen (und im Speziellen in seinem Tätigkeitsfeld) objektorientiert zu modellieren wichtiger sind als die Pattern, die entstehen dann oft schon von alleine wo sie sinnvoll sind.

  3. Und ich war bis gerade der Überzeugung, dass Gang of Four eine Band ist. *lach*

    1. Avatar von Miss Booleana
      Miss Booleana

      Ha XD Offensichtlich ist es auch eine Band 😉 danke fürs teilen. Wenn ich jemandem zutraue zu jedem Thema eine Band mit demselben Namen zu kennen, dann dir 😀

      1. Ahaha, meine Superpower.

      2. Die Herausforderung würde ich sofort annehmen. *lach*

Schreibe einen Kommentar zu Kathrin Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert