Design Patterns (dt. Entwurfsmuster)

Design Patterns (dt. Entwurfsmuster) Michael Svoboda 25. Mai 2007 Ein fortgeschrittener bzw. erfahrener Softwareentwickler hat oftmals während der Analyse eines Problems bei der Erstellung eines Entwurfs eine Art Déjà-vu-Erlebnis [4]. Er weiß oder hat zumindest das Gefühl, dass er schon einmal genau so ein oder ein ähnliches Problem hatte, welches er auch bereits einmal gelöst hat, kann sich aber beim besten Willen nicht mehr an diese Lösung oder die Stelle an der er das Problem damals gelöst hatte erinnern und verliert unnötig viel Zeit beim Entwurf, weil er die Lösung des Entwurfsproblems von Grund auf neu angehen muss, also sozusagen das Rad neu erfinden muss. Aber genau dieses Wissen bzw. diese Erfahrung machen einen Entwickler erst zu einem guten und erfahrenen Softwareentwickler. Niemand kann von einem Menschen erwarten, dass er sich an alles was er je gemacht oder gedacht hat erinnert, weshalb auch von einem Softwareentwickler nicht erwarten kann, dass er sich an alle Konzepte oder gar jede Zeile Code die er sich je überlegt hat gut genug erinnert, um sie ohne weiteres wieder zu verwenden, zumindest bei größeren und komplizierteren Problemen bzw. Lösungen ist dies offensichtlich unmöglich. Genau hier können Design Patterns helfen, denn sie beschreiben solche immer wiederkehrende Entwurfsprobleme und erfahrungsgemäß erfolgreiche Lösungen dazu, wodurch der Entwickler schnell und effizient auf dieses sonst möglicherweise verloren gegangene Wissen zurückgreifen kann. Schlagworte: Design Patterns, Entwurfsmuster, Patterns, Muster, objektorientierte Softwareentwicklung MatrNr.: 0627576 1

1 Einleitung Viele Personen kennen es, wenn sie beim Ansehen vieler Hollywood-Filme oft das Gefühl bekommen, genau diesen oder einen ähnlichen Film bereits einmal gesehen zu haben und ziemlich schnell erahnen, wie der restliche Teil der Geschichte ungefähr aussehen wird, da sie bereits ein bekanntes Muster im Aufbau des Films erkennen und auf Erfahrungen mit solcherlei Filmen zurückgreifen konnten. Tatsächlich ist ja bekannt, dass sich Hollywood- Filmproduzenten und Drehbuchautoren beim Schreiben eines Drehbuchs gerne auf gute und erfolgreiche Grundkonzepte, die sich bereits einige male in der Vergangenheit bewährt haben, wie etwa die Geschichte vom Tellerwäscher der zum Helden wird (z.b. Spiderman), verlassen und diese in einer vielleicht doch von anderen Drehbüchern, die das selbe Rezept nutzen, in nur leicht abgeänderten Form umsetzen. Genau solche Grundkonzepte bezeichnet man auch als Entwurfsmuster (Design Patterns), die es auch in anderen Bereichen wie eben der objektorientierten Softwareentwicklung gibt und auch genutzt werden, um immer wieder auftretende Probleme durch bereits bekannte, einfache und gute (also elegante ) Lösungen zu beheben. Bei der Entwicklung von Softwaresystemen wird von vielen unerfahrenen Entwicklern scheinbar meistens davon ausgegangen, dass es bisher noch kein dazu vergleichbares Softwaresystem oder vergleichbare Probleme beim Erstellen eines Entwurfs solcher Systeme gegeben haben könnte. Sie fangen daher beim Entwurf der Software bei Null an und müssen sich mühsam für jeden Teil des Entwurfs neu überlegen wie sie gewisse Probleme lösen und müssen es dann auch schaffen diese Lösungen zu implementieren. Es stellt sich dann oft später bei der Implementierung bzw. beim Testen heraus, dass Fehler beim Entwurf gemacht wurden, da zum Beispiel ein Ausnahmefall auftritt der nicht erwartet wurde und daher im Entwurf fehlt, weshalb der Entwurf immer wieder geändert werden muss, bis ein vollkommen korrekter bzw. funktionierender Entwurf vorliegt. Wie bereits auf der vorangegangenen Seite beschrieben, geht es bei Entwurfsmustern unter anderem darum, dem Wissens- bzw. Erfahrungsverlust bei der Lösung von bereits bekannten und wiederkehrenden Entwurfsproblemen entgegenzuwirken, denn der Mensch hat nun mal die Angewohnheit Dinge nach einiger Zeit zu vergessen und Softwareentwickler bilden hier nun mal keine Ausnahme. Selbst wenn der Softwareentwickler weiß wo er ein ähnliches Problem schon einmal gelöst hat muss er trotzdem jedes mal die alten Entwürfe nach dem Teil durchstöbern, der die damalige Lösung des Problems enthält, wobei auch einiges an Zeit verloren geht. Doch auch das Analysieren und Herauslesen des grundlegenden Konzepts (Musters) das zur Lösung angewandt wurde um es dann beim aktuellen Problem nur noch in den richtigen Kontext, das heißt in eine an das aktuelle Problem angepasste Version der Lösung, bringen zu müssen beansprucht einen großen (zeitlichen) Aufwand der in Summe dann vielleicht sogar größer wäre als der, das Problem auf die normale Art, also von Grund auf neu, zu lösen. Bei Entwurfsmustern geht es darum diesen Prozess des Reviews (des Nochmal- Ansehen und Analysierens ) zu erleichtern bzw. zu verkürzen indem immer wieder auftretende, erfahrungsgemäß funktionierende Konzepte bzw. Lösungen niedergeschrieben werden [4]. In anderen Worten versuchen Entwurfsmuster Erfahrungen in abstrakter Form (Konzepten) auf schriftliche Art und Weise festzuhalten. 2

2 Was sind Design Patterns? 2.1 Geschichtliches Das Grundprinzip und die Idee von Design Patterns gibt es schon sehr lange, denn seitdem wir Menschen angefangen haben Dinge zu bauen bzw. zu entwerfen (z.b. Werkzeuge, Gebäude, etc.) und diese dann auch in verschiedensten Variationen zu reproduzieren nutzen wir schon gewisse Design Patterns ( Entwurfsmuster ). Auch die Architekten der großen Pyramiden bedienten sich offensichtlich bestimmter Entwurfsmuster beim Entwerfen dieser riesigen Bauwerke, sonst wäre es wohl ein ziemlich großer Zufall, dass alle dieselbe Grundform (die Pyramide) besitzen. [5] Der Begriff Design Pattern der genau diese Idee beschreibt, wurde aber erst 1977 durch den Architekten Christopher Alexander genannt, der diesen Begriff in einer seiner vielen schriftlichen Arbeiten zu Mustern (Patterns) in der Architektur das erste Mal verwendete. Im Jahr 1987 erkannten Kent Beck und Ward Cunningham das Potential dieser Idee und legten diese auf die Softwareentwicklung um und entwickelten die ersten Software Design Patterns zur Entwicklung von graphischen Oberflächen in Programmiersprache SmallTalk. Mit diesem Schritt machten sie einige Softwarespeziallisten auf dieses Thema aufmerksam, aber zum wirklichen Durchbruch verhalf den Design Patterns jedoch erst 1995 die Gang of Four, welch aus den Autoren Erich Gemma, Richard Helm, Ralph Johnson und John Vlissides besteht, mit ihrem heute berühmten Buch Design Patterns - Elements of Reusable Object-Oriented Software (siehe [4]). [6] [5] 2.2 Eigenschaften von Design Patterns Ein gut geschriebener Design Pattern sollte laut Doug Leas Arbeit Christopher Alexander: An Introduction for Object-Oriented Designers [2] folgende Eigenschaften besitzen: Zusammenfassung von Problem und Lösung ( Encapsulation ) Ein Entwurfsmuster fasst ein gut definiertes Problem und eine dazu passende funktionierende Lösung klar und genau zusammen. Zusätzlich werden auch die Vorraussetzungen die ein Problem und die Entwicklungsumgebung erfüllen muss damit das Muster auch wirklich als funktionierende Lösung verwendet werden kann. Abstraktion ( Abstraction ) Ein Design Pattern abstrahiert Wissen und Erfahrungen aus einem gewissen (Problem-) Bereich um es wenn möglich in einer Vielzahl von anderen Bereichen ebenfalls anwenden zu können. Durch die Abstraktion kann dieses Wissen auch besser an Andere weitergegeben werden und durch Benennung dieses Design Patterns kann dieses auch in das eigene Vokabular aufgenommen werden, um Diskussionen bei Entwurfsproblemen und deren Lösung zu erleichtern. 3

Offenheit für Änderungen bzw. Erweiterbarkeit ( Openness ) Jedes Entwurfsmuster sollte offen für Änderungen und Erweiterung durch andere Muster sein damit auch größere und kompliziertere Probleme dadurch gelöst werden können. Anwendbarkeit und Kombinierbarkeit ( Generativity and Composability ) Design Patterns sollen bei möglichst vielen Entwurfsproblemen in möglichst vielen Bereichen anwendbar (und auch funktionstüchtig) sein. Aber dadurch das Design Patterns meist relativ allgemein beschrieben sind um dies zu ermöglichen kann ein allgemeineres Muster ein oder mehrere nicht so allgemeine Muster überlappen bzw. aus solchen zusammengesetzt sein. Ausgeglichenheit ( Equilibrium ) Bei jedem Design Pattern sollen nicht nur die Möglichkeiten und Vorteile sondern auch die Einschränkungen bzw. die Nachteile bekannt sein. Es soll sozusagen eine Balance zwischen der Aufzählung der Vorteile und der Nachteile geben. 2.3 Beschreibung eines Design Patterns Um all diese Eigenschaften eines Entwurfsmusters in der objektorientierten Softwareentwicklung zu beschreiben ist eine gute und detaillierte Form der Beschreibung notwendig. In dem Buch Entwurfsmuster von (u.a.) Erich Gamma [4, Seiten 8-10] sieht diese wie folgt aus: Mustername und Klassifizierung: Ein Mustername erklärt schnell und möglichst genau was es beinhaltet bzw. kann. Zweck: Welchen Zweck hat das Muster und welche Probleme es behandelt. Auch bekannt als: Synonyme für das Muster falls es sie gibt. Motivation: Beschreibt ein Szenario eines Entwurfsproblems ziemlich genau und eher aus praktischer Sicht und erklärt wie das Entwurfsmuster dieses Problem mittels ihrer speziellen Klassen- und Objektstrukturen löst. Dieser Teil soll es erleichtern die abstrakteren Beschreibungen des Patterns zu verstehen. Anwendbarkeit: In welchen Problemsituationen kann man das Muster anwenden und woran diese Situationen erkannt werden können. Struktur: Eine graphische Darstellung der Klassen und deren Verbindungen untereinander im Muster etwa mittels UML-Diagrammen (z.b. Klassendiagramm, Interaktionsdiagramme, etc.) Teilnehmer: Beschreibt die im Entwurfsmuster enthaltenen Klassen bzw. Objekte und deren Aufgaben. Interaktionen: Beschreibt wie die Klassen miteinander zusammenarbeiten. 4

Konsequenzen: Erklärt was vom Entwurfsmuster zu erwarten ist, welche Einschränkungen, Vor- und Nachteile es mit sich bringt. Implementierung: Beschreibt worauf man bei der Anwendung des Musters besonders acht geben muss und gibt Tipps die einem bei der Umsetzung helfen könnten. Beispielcode: Enthält Beispiele wie Teile des Codes in einer bestimmten Programmiersprache aussehen könnten. Bekannte Verwendungen: Zählt Beispiele für bereits erfolgreiche Verwendungen des Musters in gewissen Systemen auf. Verwandte Muster: Falls ähnliche Muster oder Verbindungen zu anderen Mustern bekannt sind werden die wichtigsten Unterschiede oder mögliche Kombinationsmöglichkeiten mit diesen Design Patterns genannt bzw. beschrieben. 2.4 Arten von Design Patterns 2.4.1 Erzeugungsmuster ( Creational Patterns ) Dabei handelt es sich um Design Patterns die sich vor allem mit der Erzeugung von Objekten befassen. Es beschreibt den Prozess der Objekterzeugung mithilfe von gewissen Erzeugungsstrukturen, die einem bei bekannten Erzeugungsproblemen helfen sollen. 2.4.2 Strukturmuster ( Structural Patterns ) Beschreiben wie Klassen bzw. Objekte zu größeren und komplexeren Strukturen zusammengefasst werden können, wobei sich aber die meisten Strukturmuster mit Objektstrukturen befassen. 2.4.3 Verhaltensmuster ( Behavioral Patterns ) Beschreiben die Art und Wiese wie Objekte bzw. Klassen miteinander kommunizieren, zusammenarbeiten und Zuständigkeiten (bzw. Aufgaben) untereinander delegiert (zugeteilt bzw. aufgeteilt) werden. 3 Was Design Patterns nicht sind Trotz der Bemühungen vieler Experten auf diesem Gebiet, genau zu erklären was Design Patterns sind und auch versuchen dies durch das einbringen von Beispielen bringen zu bestärken, kommt es immer wieder zu Missverständnissen bzw. Fehlinterpretationen wenn es darum geht was nun die tatsächlichen Aufgaben bzw. Nutzen von Design Patterns sind. John Vlissides, ein Mitglied der Gang of Four beschäftigt sich in seinem Buch Entwurfsmuster anwenden [3] unter anderem mit solchen Missverständnissen bezüglich der Frage was Design Patterns sind bzw. was sie nicht sind: 5

Muster sind nichts weiter als Fachsprache, Regeln, Programmiertricks, Datenstrukturen, Algorithmen, Code,... [3, Seite 4] Diese Aussage trifft zwar in gewisser Weise zu, könnte aber zugleich fast als Beleidigung von Design Patterns gesehen werden, weil es die Fähigkeiten und Möglichkeiten von Entwurfsmustern als sehr eingeschränkt darstellt, obwohl Design Patterns mehr Ideen darstellen als fixe Entwurfsstrukturen vorgeben. Die Eigenschaften der Erweiterbarkeit, Kombinierbarkeit und einige andere Eigenschaften gehen durch diese verallgemeinernde Aussage verloren und ist daher nicht wirklich eine zutreffende Beschreibung von Design Patterns. Muster garantieren wieder verwendbare Software, höhere Produktivität, den Weltfrieden etc. [3, Seite 7] Muster, erzeugen vollständige Architekturen. [3, Seite 9] Dieses Missverständnis gibt Grund zur Vermutung, dass Entwurfsmuster den Entwicklern (den Anwendern) die Arbeit abnehmen ein System wirklich selbst zu entwickeln und sozusagen nur einen Baukasten Entwurfsmuster verwenden um das System zusammenzubauen. Wie bereits in den vorangegangenen Kapitel erklärt wurde, handelt es sich bei Design Patterns lediglich um Beschreibungen von bekannten und erfahrungsmäß funktionierenden Ideen bzw. Konzepten zur Lösung von wiederkehrenden Entwurfsproblemen und nicht um ein Rezept oder Code, dass vom Anwender einfach abgetippt werden muss, weshalb er bei der Umsetzung eines Design Patterns immer noch sehr viel selbst zu überlegen und zu tun hat. Dabei und auch schon bei der Wahl des Entwurfsmusters zur Lösung seines Entwurfsproblems kann er immer noch leicht Fehler machen, denn Muster selbst garantieren nichts, da der größte Teil der Umsetzung immer noch am Entwickler (dem Faktor Mensch) hängt. 4 Anti-Patterns 4.1 Was sind Anti-Patterns? Anti-Patterns beschreiben im Gegensatz zu Design Patterns immer wieder auftretende falsche Lösungen, die Entwicklern zeigen soll wie man ein bestimmtes Problem nicht lösen sollte bzw. welche negativen Konsequenzen diese Lösung mit sich bringen würde. Ein Anti-Pattern zeigt aber nicht nur wie man es nicht machen soll, sondern erklärt auch warum eine bestimmte Lösung nicht funktioniert und beschreibt wie man es besser bzw. richtig machen kann. [6] Ein vollständig dokumentierter Anti-Pattern beschreibt eine fehlerhafte Lösung eines Problems indem er das allgemeine Problem, die Problemauslöser, die Symptome an denen man das allgemeine Problem erkennen kann und die Konsequenzen bzw. Fehler die durch diese Probleme entstehen erklärt und liefert eine funktionierende korrekte Lösung das so genannte Refactoring der Lösung. [1] 6

4.2 Wie kommt es zu einem Anti-Pattern? Ein Anti-Pattern kann in der Software-Entwicklung durch fehlende Erfahrungen und fehlenden Kenntnissen der Entwickler oder deren Vorgesetzten bei der Lösung von bestimmten Arten von Problemen entstehen. Sie machen also so genannte klassische Fehler die schon viele andere vor ihnen gemacht haben. Genau solche klassischen Fehler werden Anti-Patterns genannt. Wie der Name Anti-Patterns schon vermuten lässt existiert ein gewisser Zusammenhang zwischen Anti-Patterns und Design Patterns. Dieser besteht darin, dass es bei der Verwendung von Entwurfsmustern in der Praxis oft das Problem gibt, dass ein eigentlich perfekt funktionierendes Muster oft falsch bzw. im falschen Kontext angewandt wird, wodurch sich aus einem Design Pattern auch ein Anti-Patterns entwickeln kann. Einige Hauptursachen für Fehler in der Software-Entwicklung und Beispiele dafür sind [1]: Unangebrachte Hast: Durch Zeitdruck bei der Entwicklung einer Software müssen oft Kompromisse im Bezug auf die Qualität gemacht werden, indem auf ausführliche Tests verzichtet wird. Desinteresse: Desinteresse an einem Software-Projekt kann zu mangelnder Qualität führen, da kein Interesse besteht, die beste Lösung sondern nur irgendeine Lösung zu finden. Engstirnigkeit: Die Weigerung eine andere vielleicht praktischere Lösung überhaupt in betracht zu ziehen oder gar zu verwenden. Andere Hauptursachen sind auch: Faulheit, Geiz, Ignoranz, Stolz, usw. 5 Zusammenfassung 5.1 Vorteile von Design Patterns Entwurfsmuster bieten dem Nutzer einiges an Vorteilen und zwar nicht nur bei der Entwurfsentwicklung. So helfen Design Patterns Erfahrungen in der Entwicklung (Expertenwissen) in schriftlicher Form zu sammeln und zu beschreiben, wodurch sich zusätzlich der Vorteil ergibt, dass diese Erfahrungen der breiten Masse zur Verfügung gestellt und nutzbar gemacht werden können. Durch die Verbreitung dieser durch Entwurfsmuster beschriebener Erfahrungen und der Eigenschaft von Entwurfsmustern, einen sprechenden und zusammenfassenden Namen zu besitzen, können und werden diese Namen in die Fachsprache der Softwareentwicklung aufgenommen, wodurch diese Diskussionen und das Erklären eines Entwurfs um einiges vereinfacht werden können. Beschreibungen von Entwurfsmustern enthalten nicht nur die Lösung eines Entwurfsproblems, sondern auch andere Informationen wie etwa die Vor- und Nachteile dieser Lösung, wodurch es auch weniger erfahrenen Entwicklern erleichtert wird diese zu verwenden. Durch eine Vielzahl von Eigenschaften der Design Patterns erspart sich der Entwickler im Normalfall einiges an Zeit und Geld und auch die Wartungsfähigkeit und Erweiterbarkeit wird erhöht. 7

5.2 Nachteile von Design Patterns Bei der Nutzung von Design Patterns kann es passieren, dass der Entwickler sich zu sehr auf Patterns verlässt und nicht darüber nachdenkt bzw. nachliest welche Einschränkungen und Nachteile diese Muster mit sich bringen. Denn durch unbedachten Einsatz von Entwurfsmustern können beispielsweise eigentlich einfache Entwürfe unnötig vergrößert und verkompliziert werden, wo es doch eine vielleicht zwar speziellere, aber einfachere Lösung gibt, denn Entwurfsmuster erhöhen oftmals (unnötigerweise) die Anzahl von Klassen. Ein guter Einsatz von Design Patterns zeichnet sich nämlich dadurch aus, dass sie einen Entwurf verbessern, sei dies jetzt im Bezug auf Übersichtlichkeit, Erweiterbarkeit oder sonstigen Verbesserungsmöglichkeiten. Wenn ein Entwurfsmuster, welches viel Flexibilität oder Erweiterbarkeit bietet, bei einem Entwurf eingesetzt wird, bei dem diese Eigenschaften nicht benötigt werden, dann entsteht daraus nur ein unnötiger Mehraufwand und das entworfene System verliert möglicherweise zusätzlich noch einiges an Effizienz (Geschwindigkeit). Auch durch die ständig steigende Anzahl an Entwurfsmustern wird die Suche nach dem richtigen Muster, wenn man bisher erst mit wenigen zu tun hatte, immer zeitaufwändiger und auch das Einlesen in ein Entwurfsmuster kann möglicherweise (bei schlechter Beschreibung oder komplexeren Mustern) einiges an Zeit und Aufwand kosten. 5.3 Abschluss und Ausblicke Die Idee von Entwurfsmustern gibt es schon seitdem Menschen denken können und wurde seither bewusst oder unbewusst immer wieder genutzt. Erst Christopher Alexander in der Architektur und später die Gang of Four bestehend aus Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides in der Softwareentwicklung entwickelten den Begriff Design Pattern bzw. Entwurfsmuster und eine Formalisierung (Arten der Beschreibungen) dieser Grundidee. In der Architektur konnte sich diese Erfindung jedoch nicht durchsetzten, in der Softwareentwicklung hingegen schon. Durch das Erstellen eines Kataloges bestehend aus bekannten und vor allem detailliert beschriebenen Entwurfsmustern schaffte die Gang of Four es den Bereich der Softwareentwicklung zu begeistern und lösten dort dadurch einen Hype aus der noch immer andauert. Erfahrungen von Experten konnten nun endlich auf gute Art und Weise an Anfänger weitergegeben werden und diese schneller zu Experten heranwachsen, wodurch Design Patterns die Qualität in der Softwareentwicklung erhöht werden konnte. Mit diesem Hype treten aber auch immer mehr Missverständnisse auf und auch der Katalog an Design Patterns wird immer größer und dadurch leider auch unübersichtlicher. Erfahrungen mit Design Patterns werden deshalb für das Zurechtfinden in solchen Katalogen eine immer größere Notwendigkeit, wodurch sich vielleicht viele potentielle Nutzer von Entwurfsmustern möglicherweise abschrecken lassen könnten, weil ihnen einfach der Einarbeitunsaufwand zu groß erscheint. Doch Leute wie jene der Gang of Four und auch Universitäten versuchen Softwareentwicklern so einfach wie möglich und Schritt für Schritt an Design Pattern näher zu bringen und damit Design Patterns mehr und mehr zu Basiskenntnissen der Softwareentwicklung zu machen. 8

Literatur [1] BROWN, W.J.; MALVEAU, R.C.; McCORMICK III, H.W.; MOWBRAY, T.J.: Anti-Patterns - Entwurfsfehler erkennen und vermeiden, 1. Auflage mitp-verlag/bonn, 2004 [2] LEA, Doug: Christopher Alexander: An Introduction for Object-Oriented Designers http://gee.cs.oswego.edu/dl/ca/ca/ca.html [3] VLISSIDES, John: Entwurfsmuster anwenden - Die Fortsetzung des Klassikers der Gang of Four, Addison Wesley Verlag in Pearson Education Deutschland/München, 1999 [4] GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John: Entwurfsmuster - Elemente wiederverwendbarer objektorient. Software, Addison Wesley Verlag in Pearson Education Deutschland/München, 2004 [5] http://www.designpatternsfor.net/default.aspx?pid=1 [6] http://de.wikipedia.org/wiki/entwurfsmuster 9