Java für Fortgeschrittene Proseminar im Sommersemester 2009 Design Patterns: Schöner Programmieren mit Design Tips

Transkript

1 Java für Fortgeschrittene Proseminar im Sommersemester 2009 Design Patterns: Schöner Programmieren mit Design Tips Richard Kaufhold Technische Universität München Zusammenfassung Diese Ausarbeitung vermittelt einige grundlegende Entwurfsmuster, die sich in der objektorientierten Programmierung bewährt haben. Es werden Basiskonzepte der Design Patterns an anschaulichen Beispielen erklärt. 1

2 Inhaltsverzeichnis 1 Einleitung 3 2 Design Patterns Creational Patterns Abstract Factory Singleton Structural Patterns Decorator Facade Behavioral Patterns Observer Demoprojekt 15 4 Schluss 16 2

3 1 Einleitung In unserer globalisierten Welt, in der sich Softwareentwickler behaupten müssen, ist der Leistungsdruck immer mehr angestiegen. Die time to market für die Softwareanwendungen ist in den vergangenen Jahren immer geringer geworden. Außerdem erwarten die Kunden von den Anwendungen, die sie einsetzen, immer mehr und eine immer ausgeklügeltere Funktionalität. Deshalb können es sich Anwendungsentwickler heute nicht mehr leisten das Rad bei jeder Anwendung neu zu entwickeln. Aus diesen Gründen haben sich Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides vor mehr als 14 Jahren zusammengetan, um wiederkehrende Muster in der objektorientierten Softwareentwicklung zu sammeln und ihnen einen Namen zu geben. Das aus dieser Sammlung entstandene Werk, das oft auch als das Buch der GoF (Gang of Four) bezeichnet wird, ist zu dem Standardwerk der Design Patterns geworden. Heutzutage sind Design Patterns aus der Softwareentwicklung nicht mehr wegzudenken. Sie stellen einen einheitlichen Wortschatz bereit, den jeder Entwickler für objektorientierte Software beherrschen sollte. In der Entwicklung neuer Software sollten sich Softwarearchitekten schon frühzeitig über eine klare Struktur des zu entwerfenden Programms im klaren sein. Vorteilhaft ist es dabei, wenn sie erkannte Muster in einer sehr frühen Projektphase beim Namen nennen. Es erleichtert anderen Programmierern, die in späteren Projektphasen dazu kommen, die Software zu verstehen. Java erfüllt durch seine strikte objektorientierte Architektur die besten Voraussetzungen Design Patterns gewinnbringend einzusetzten. Deshalb werde ich in meiner Ausarbeitung einige dieser Konzepte, anhand von Java Beispielen, vorstellen. 2 Design Patterns Im Folgenden werde ich einen Katalog von verschiedenen Design Patterns und deren Verwendung vorstellen. Diese Sammlung ist bei weitem nicht vollständig, da es den Rahmen dieser Ausarbeitung sprengen würde. Deshalb möchte ich das Buch Design Patterns Elements of Reusable Object-Oriented Software ([1]) für ein tiefergehendes Studium des Themas empfehlen. In diesem Buch werden die in Abbildung 1 dargestellten Patterns vorgestellt. Diese 23 Patterns bilden eine solide Grundlage, wenn man als Software Architekt Design Patterns sinnvoll einsetzten will. Wie der Abbildung zu entnehmen ist, lassen sich die Design Patterns in drei Kategorien unterteilen: Creational Patterns, Structural Patterns und Behavioral Patterns, die alle einem bestimmten Bereich des Objekt Lebenszykluses gewidmet sind. Zum Beginn jedes Kapitels werde ich genauer erklären, was es mit dem jeweiligen Bereich auf sich hat. 3

4 Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Abstract Factory Builder Prototype Singleton Adapter(object) Bridge Composite Decorator Facade Flyweight Proxy Abbildung 1: Design Pattern Übersicht Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 2.1 Creational Patterns Am Anfang des Objekt Lebenszyklus benötigt ein Objek Platz im Hauptspeicher und seine interne Datenstruktur muss initialisiert werden. Mit diesem Schritt befassen sich die Creational Patterns. Sie spezifizieren wie der Erstellungsprozess neuer Objekte gestaltet werden kann. Das bedeutet sie machen die resultierende Software unabhängig von der Art wie die einzelnen Instanzen erzeugt, zusammengesetzt und repräsentiert werden. Durch diese Abstraktion erzeugt man ein größeres Maß an Unabhängigkeit zwischen den Objekten, aus denen eine Anwendung zusammengesetzt ist. So müssen, beim Austausch einer einzelnen Klasse, nicht mehr alle mit ihr in Verbindung stehenden Klassen geändert werden, sondern nur noch die zentrale, erzeugende Instanz Abstract Factory Das wohl am häufigsten dafür verwendete Pattern ist die Abstract Factory. Sie erzeugt eine Gruppe zusammengehöriger Objekte ohne ihre konkrete Implementierung festzulegen. In Abbildung 2 ist die Struktur eines Factory Patterns dargestellt. Der Client hat hierbei nur Zugriff auf die Abstract Factory und die abstrakten Produkte. Er kommuniziert ausschließlich über die Interfaces dieser Klassen. Die Klasse Abstract Factory legt für jedes abstrakte Produkt die Signatur der Methode zum Erzeugen einer neuen Instanz fest. Es liegt nun bei der konkreten Factory, ein passendes Objekt der mit ihr verbundenen Produktlinie zu erzeugen. Auf diese Weise ist es zum Beispiel möglich Software an verschiedene Basissysteme anzupassen. Um die Arbeitsweise des Factory Patterns besser zu verstehen, möchte ich das folgende Beispiel betrachten. Es handelt sich um ein einfaches Konsolenspiel, bei dem es das Ziel ist das Ende eines Labyrinths zu erreichen. Die Objekte, mit denen wir es dabei zu tun haben, sind Game, Maze, Room, Wall, Door und 4

5 Abbildung 2: Factory Pattern 5

6 Abbildung 3: Maze Game Player. Diagramm 3 stellt die Zusammenhänge der Komponenten da. Das Spiel ist dafür verantwortlich am Spiel teilnehmende Benutzer anzulegen und sie in den Räumen des Labyrinths zu verteilen. Die Klasse Maze erzeugt ein Labyrinth und legt den Zielraum fest. Sobald ein Nutzer den Zielraum erreicht hat, wird er als Sieger aus dem Spiel entfernt und die anderen Spielteilnehmer können noch weiter versuchen das Ziel zu erreichen. Um den Schwierigkeitsgrad etwas zu erhöhen, bekommt der Spieler jedes Mal, wenn er gegen eine Wand oder eine geschlossene Türe läuft, einen Schlag. Wurde er zu oft getroffen, ist das Spiel für ihn zu Ende und er hat verloren. Die Spieler kommen immer der Reihe nach dran und können maximal eine Aktion ausführen, wie zum Beispiel das Öffnen oder Schließen einer Tür oder das Hindurchgehen. In einer einfachen Implementierung wird die Maze Klasse des Labyrinths mit dem new Operator anlegt. 1 r1=new Room( ) ; 2 r2=new Room( ) ; d1=new Door ( ) ; 5 d2=new Door ( ) ; Auf diese Art erhalten wir ein einfaches Labyrinth. Das Problem dabei ist aber, 6

7 Abbildung 4: Abstract Game Factory dass das Labyrinth nur durch das neu compilieren des Source Codes geändert werden kann. Wir können so zum Beispiel nachträglich keine anderen Türen einbauen, die unterschiedliche Aktionen unterstützen. Besser wäre es doch dieses Anlegen der Objekte aus dem Source Code der Maze Class auszulagern, so dass wir die Möglichkeit erhalten die erstellten Komponenten später zu tauschen. Dazu definieren wir uns eine abstrakte Klasse. Diese spezifiziert die Methoden, die nötig sind, um alle Game Componenten zu erstellen. Abbildung 4 stellt diese abstrakte Klasse dar. Die Default Game Factory erzeugt die Basis Konfiguration mit den Standardklassen. Die Action Mod Factory tauscht die Game und die Door Komponente aus. Dabei wird die Game Klasse um einen Befehl zum Schlagen anderer Spieler erweitert und die Türen werden in einer zufälligen Position, d.h. geöffnet bzw. geschlossen, initialisiert. Um den Übergang zum Factory Pattern abzuschließen, müssen wir jetzt alle new Befehle durch Aufrufe der passenden Factory Methode ersetzten. 1 AbstractFactory f a c t o r y ; 2 r1=f a c t o r y. createroom ( ) ; 3 r2=f a c t o r y. createroom ( ) ; d1=f a c t o r y. createdoor ( ) ; 6 d2=f a c t o r y. createdoor ( ) ; Damit ein Game Objekt erstellt werden kann, muss die verwendete Factory 7

8 festgelegt werden. Wie das genau umgesetzt wird, werde ich im nächsten Kapitel zeigen Singleton Bei der Erklärung des Factory Patterns bin ich nicht darauf eingegangen, wie es den einzelnen Spielkomponenten ermöglicht wird, auf die Factory zuzugreifen. Dafür gibt es verschiedene Ansatzweisen. Eine davon ist es, sie den Komponenten als Parameter zu ihrem Konstruktor zu übergeben. Diese Vorgehensweise hat aber mehrere Schwächen. Wenn wir die Klassen auf diese Art aufbauen, müssen wir in jeder Komponente die Factory speichern obwohl wir sie im Normalfall nach der Initialisierung nicht mehr benötigen. Wir könnten die Factory auch als Attribut der Initialisierungsmethode übergeben. Dadurch verlieren wir aber wieder Dynamik, da dann die Maze nach Abschluss der Initialisierung keine weiteren Komponenten mehr erzeugen kann. Sie ist also nicht im Stande sich dynamisch zu vergrößern. Ich möchte nun das passende Design Pattern vorstellen, das die vollständige Dynamik des Systems bewahrt und es gleichzeitig davon befreit in allen Klassen die Factory zu speichern. Das Singleton Pattern erfüllt genau diese benötigten Anforderungen. Die allgemeine Struktur des Singleton Patterns ist in Abbildung 5 dargestellt. Wenn wir dieses Pattern nun auf unsere Factory anwenden, müssen wir die Abstract Factory um ein statisches Attribut vom Typ AbstractGameFactory erweitern. Außerdem brauchen wir noch eine ebenfalls statische Zugriffsmethode die sicherstellt, dass das Singleton, wenn nötig, erstellt wird. Außerdem wollen wir uns es freistellen eine beliebige, von AbstractGameFactory abgeleitete Klasse als Singelton einzusetzen. Dafür definieren wir uns noch eine statische Methode loadfactory(string name):boolean, welche die Klasse mit dem full qualified Name als Singleton Instanz lädt. Diese Methode muss in jedem Fall ausgeführt werden. Nach dem Ladevorgang ist das Singleton gesperrt, damit es zu keinen Inkonsistenzen durch ein späteres Auswechseln des Singletons kommen kann. Dazu muss noch gesagt werden, dass ein Singleton immer nur in Verbindung mit dem verwendeten Classloader einzigartig ist. Verschiedene Classloader würden mit der von mir vorgeschlagenen Version unterschiedliche Instanzen des Singletons erzeugen. Abbildung zeigt die Implementierung des Singletons. 1 / /.. 2 p u b l i c a b s t r a c t c l a s s AbstractGameFactory { 3 s t a t i c AbstractGameFactory i n s t a n c e=n u l l ; 4 5 p u b l i c s t a t i c f i n a l S t r i n g d e f a u l t F a c t o r y=defaultgamefactory. c l a s s. getcanonicalname ( ) ; 6 7 p u b l i c s t a t i c AbstractGameFactory i n s t a n c e ( ) { 8 r eturn i n s t a n c e ; 9 } 10 8

9 Abbildung 5: Singleton Pattern 11 p u b l i c s t a t i c boolean loadfactory ( S t r i n g classname ) { 12 i f ( i n s t a n c e==n u l l ) { 13 try { 14 Class f a c t o r y C l a s s = Class. forname ( classname ) ; 15 i f ( f a c t o r y C l a s s!= n u l l ) { 16 i n s t a n c e= ( AbstractGameFactory ) f a c t o r y C l a s s. newinstance ( ) ; 17 return true ; 18 } 19 } catch ( Exception i e ) {} 20 } 21 r eturn f a l s e ; 22 } 23 / / } Wer das Singleton Pattern aus anderen Programmiersprachen kennt, könnte versucht sein es lazy zu erstellen. Die aus anderen Programmiersprachen bekannten Versionen des Singleton Patterns für eine faule Initialisierung sind aber auf Grund von JVM Features und Features in der Programmiersprache falsch. Sollten sie versucht sein Lazy Initialization einzusetzen, muss die statische Methode zum Holen der Instanz synchronisiert sein. Es gibt, meines Wissens nach, keine andere Möglichkeit. Genauere Informationen, warum es nicht ohne weiteres möglich ist lazy loading in Java im Singleton Pattern zu implementieren, kann in When is a Singleton not a Singleton? [2] nachgelesen werden. 9

10 Abbildung 6: Decorator Pattern 2.2 Structural Patterns Nachdem wir uns mit dem Erstellungsprozess befasst haben, können wir uns dem eigentlichen strukturellen Aufbau mehrerer Objekte widmen. Die Structural Patterns befassen sich damit wie Klassen und Objekte zusammengesetzt sind, um größere Funktionsblöcke zu formen. Ein einfaches Beispiel hierfür ist die Vererbung in objektorientierten Sprachen. Die Vererbung ist jedoch nur ein sehr statisches Konstrukt, dass zu monolithischen Systemen führt, die nur schwer an neue Anforderungen angepasst werden können Decorator Das Prinzip, Objekte ineinander zu verschachteln, kann auch dazu verwendet werden den Objekten erweiterte Funktionalitäten hinzuzufügen. Es wird oft eingesetzt, wenn ein Objekt modelliert wird, das aus einigen Bestandteilen zusammen gesetzt ist. Die Zusammensetzung der Teile kann jedoch erst während der Ausführung des Programms bestimmt werden. Zum Beispiel ein belegtes Brötchen, besteht aus dem Bötchen und ein paar Sorten von Belag, die jedoch beliebig kombiniert werden können. Wenn man ein Programm schreibt, das den Preis berechnen soll, wird einem schnell klar, dass es sehr viele verschiedene belegte Brötchen geben kann. Man kann natürlich, die Bestandteile als Attribute betrachten und die Preisberechnung mit Hilfe der Abfragen bewerkstelligen. 10

11 1 p u b l i c c l a s s BelegteSemmel { 2 p r i v a t e boolean semmel ; 3 p r i v a t e boolean kaese ; 4 p r i v a t e boolean wurst ; 5 p r i v a t e boolean s a l a t ; 6 / / p u b l i c i n t b e r e c h n e P r e i s ( ) { 9 i n t p r e i s =0; 10 i f ( semmel ) p r e i s +=25; 11 i f ( kaese ) p r e i s +=50; 12 i f ( wurst ) p r e i s +=30; 13 i f ( s a l a t ) p r e i s +=15; 14 r eturn p r e i s ; 15 } p u b l i c void setsemmel ( boolean semmel ) { 18 t h i s. semmel=semmel ; 19 } p u b l i c boolean issemmel ( ) { 22 r eturn semmel ; 23 } 24 / /... 1 p u b l i c c l a s s NaiveDecoratorClient { 2 p u b l i c s t a t i c void main ( S t r i n g [ ] args ) { 3 BelegteSemmel kaesesemmel = new BelegteSemmel ( ) ; 4 kaesesemmel. setsemmel ( true ) ; 5 kaesesemmel. setkaese ( true ) ; 6 kaesesemmel. s e t S a l a t ( f a l s e ) ; 7 kaesesemmel. setwurst ( f a l s e ) ; 8 System. out. p r i n t l n ( Die Kaesesemmel k o s t e t : + kaesesemmel. b e r e c h n e P r e i s ( ) ) ; 9 } 10 } Noch sieht es ziemlich einfach aus. Was ist aber, wenn es mehr Sorten des Belages geben würde oder verschiedene Brötchen. Das Programm würde so sehr schnell unübersichtlich und schwer wartbar werden. Und nicht nur die Klasse BelegteSemmel, sondern auch die des Clients, weil man all die Attribute richtig setzen müsste. Einige Fälle, wie das Bestellen der doppelten Menge an Käse, werden gar nicht abgedeckt. Eine andere Herangehensweise an das Problem bietet das Decorator Pattern. 11

12 Abbildung 7: Semmel Decorator Betrachten wir Abbildung 7. Es wird mit der Klasse Zutat eine Abstraktion der Objekte gemacht, welche auch die öffentliche Schnittstelle ist. Das Objekt die Semmel, als Grundzutat, wird in unserem Fall, als zu dekorierendes spezifiziert. Da Designer Patterns keine strikte Vorgaben sind, kann die Klasse Semmel auch abstrakt definiert werden und weitere Unterklassen besitzen, wenn man mehr als ein Brötchen modellieren muss. Die anderen Zutaten werden als Unterklassen des ZutatenDekorators aufgefasst, weil sie einer Semmel weitere Funktionalität hinzufügen. Welche in unserem Beispiel die Erweiterung der Preisberechnung auf beliebig viele Zutaten ist. Die Dekoratoren müssen dabei aber genauso Zutaten sein, damit es für den Client nur eine zentrale Schnittstelle gibt. Dieser muss dann die Zutaten nur richtig verschachteln. Mit dieser 12

13 Implementierung ist es möglich eine beliebige Auswahl und Mengen an Zutaten hinzuzufügen. Außerdem reicht es, wenn wir einer Produktlinie eine neue Zutat hinzufügen einen neuen Dekorator anzulegen. Wir ersparen uns damit das Ändern der Semmel Klasse Facade Das Facade Pattern ist sehr wichtig, wenn es darum geht, Funktionsmodule klar voneinander abzugrenzen. Durch die Abgrenzung gewinnt man Flexibilität in der Auswahl der verwendeten Module. Ein über eine Facade abgegrenztes Modul kann leicht durch ein anderes ersetzt werden, das ein gleich- oder höherwertiges Interface anbietet. Die Klasse, die das Facade Muster implementiert, ist dafür zuständig alle Objekte zu erstellen und zu verbinden, die sie für die von ihr bereit gestellten Funktionalitäten benötigt. Es gibt die innere Struktur, die hinter der Facade liegt, im Allgemeinen nicht nach außen hin preis. Abbildung 8: Facade Pattern In Abbildung 8 wird dargestellt wie sich die Einführung einer Facade in eine Anwendung auswirken kann. Die linke Abbildung zeigt das System ohne eine Facade. Zu erkennen ist, dass die Verbindung zwischen den Objekten sehr chaotisch stattfindet. Ein auf diese Weise strukturiertes System braucht im allgemeinen mehr Speicher und ist sehr monolithisch. Es ist nicht einfach möglich einzelne Klassen auszutauschen, da alle verbundenen Objekte auf Seiteneffekte hin überprüft werden müssen. Die rechte Hälfte der Abbildung 8 zeigt die, durch 13

14 Anwendung des Facade Patterns klar abgegrenzten Bereiche. Dadurch wird es erleichtert Objekte hinter der Facade auszuwechseln, ohne daß Objekte dadurch beeinflusst würden. Beispielsweise könnte man in einer graphischen Anwendung, die Netzwerkverbindungen nutzt, vier Systeme extrahieren, die nur über Facades kommunizieren. Die vier Bereiche sind: Netzwerkkommunikation, User Interface, Persistenzebene und das Datenmodel. Das Datenmodell würde dabei die zentrale Schaltstelle darstellen, auf die alle Systeme zugreifen. Diese Abgrenzung macht Sinn, da über das Userinterface meist keine direkte Kontrolle über die offenen Datenverbindungen des Netzwerkkontrollers benötigt werden, bzw. es keine Relevanz für das Datenmodell hat, ob die Daten über das Netzwerk eingespielt werden oder aus einer Datei auf der Festplatte stammen. 2.3 Behavioral Patterns Im Kontrast zu Structural Patterns liegt der Schwerpunkt von Behavioral Patterns auf der Kommunikation zwischen verschiedenen Objekten. Sie stellen wiederkehrende Muster im Kontrollfluss von Objekten dar. Durch ihre Verwendung wird es den Programmierern erleichtert, komplexe Zusammenhänge in einer Applikation zu verstehen. Die Behavioral Patterns lassen sich in Class- und Objektpatterns unterteilen. Class Patterns benützen Vererbung, um Teilaufgaben an abgeleitete Klassen zu delegieren. Die Objekt Patterns setzen auf die Komposition von Objekten und sind dadurch dynamischer. In meiner Ausarbeitung möchte ich mir das Object Behavioral Pattern Observer genauer ansehen Observer Das Observer Pattern ermöglicht eine One-to-Many Kommunikation zwischen Objekten zu etablieren. Diese Verbindung ist nicht statisch aufgebaut. Sie kann jederzeit während der Laufzeit angepasst werden. Die Objekte, die miteinander kooperieren möchten, müssen sich dabei über ein Thema (Subject) verständigen. Bei diesem Subject müssen sich alle beteiligten Objekte registrieren. Die Registrierung findet in Abbildung 9 über die Methoden attach bzw. detach statt. Die Klasse Subject hält eine Liste mit registrierten Observern vor. Nachdem auf dem Subject die notify Methode aufgerufen wurde, ruft es bei allen registrierten Observern die update Methode auf. Um das Pattern besser zu verstehen, möchte ich es an einem praktischen Beispiel erklären. Dazu betrachten wir den Entwurf eines intelligenten Kühlschranks. Der Kühlschrank führt dabei Protokoll über alle Entnahmen und Zugänge von Lebensmitteln und zeigt eine Liste der vorhandenen Lebensmittel auf einem Frontdisplay an. Ein Ansatz das System zu entwerfen, wäre das Display fest in den Kühlschrank zu verdrahten. Dieser Weg hat aber das Problem, dass ich ausschließlich Kühlschränke mit Displays verkaufen könnte. Wenn aber ein Kunde einen Kühlschrank möchte, der dazu in der Lage ist automatisch Inhalte nachzubestel- 14

15 Abbildung 9: Observer Pattern len, oder er von außerhalb seines Hauses aus den Inhalt seines Kühlschrankes überprüfen möchte, braucht er das Display nicht. Durch den höheren Preis des Kühlschranks würde er sich gegebenenfalls für ein billigeres Konkurrenzprodukt entscheiden. Das Ziel ist eine modularere Lösung, so dass möglichst viel der Software in allen Kühlschränken verwendet werden kann. Das Observer Pattern bietet gerade diese Flexibilität. Es ermöglicht uns, dass sich dynamisch viele Objekte für die Veränderungen der im Kühlschrank enthaltenen Waren registrieren können. Abbildung 10 stellt die mit Hilfe des Observer Pattens entwickelte Struktur da. Wie sie sehen besteht keine Komposition zwischen RefrigeratorDisplay und dem Refrigerator selbst. Ein Display wäre so theoretisch auch dazu in der Lage, den Inhalt von mehreren Kühlschränken anzuzeigen. 3 Demoprojekt Die Idee meines Demoprojekts war es, eine Applikation zum kooperativen Editieren von Dokumenten zu entwickeln. Dabei sollte je nach Mime Type der Datei ein passendes Plugin zum Anzeigen und Editieren des Dokumentes ausgewählt werden. Die Plugin Komponente implementiert gleichzeitig die Server Funktionalität, so dass jeder Client auch als Server für Dokumente in Erscheinung treten kann. Die Benutzer Authentifizierung erfolgt durch ein zertifikat gestütztes System, die Autorisierung durch den Server. Durch Verwendung von 15

16 Abbildung 10: Refrigerator unterschiedlichen Netzwerkkonnektoren wird dem Benutzer ermöglicht sich mit dem Server zu verbinden bzw. nach anderen Nutzern des Programms im selben Subnetz zu suchen. 4 Schluss Wie wir gesehen haben, können Design Patterns uns als Programmierer dabei helfen Standardprobleme auf eine schnelle und effiziente Art zu lösen. Diese Ausarbeitung stellt nur eine Einführung in die Thematik der Design Patterns in objektorientierter Programmierung dar. Die GoF hat in ihrem Buch, nur 23 der bekannten Design Patterns behandelt. Es wird wahrscheinlich nie eine vollständig abgeschlossene Liste der Design Patterns geben, da stetig neue Lösungen entwickelt werden. Um Design Patterns vollständig zu betrachten, sollte man sich nicht nur auf die guten Muster konzentrieren, sondern auch in der Lage sein schlechte Software und fehlerhafte Prozesse zu erkennen. Dazu hilft es die Anti-Patterns zu betrachten, die einen guten Überblick über sehr häufig gemachte Fehler in der 16

17 Softwareentwicklung. Wie man aus den Beispielen nachvollziehen kann, sind Design Patterns nicht nur theoretische Konstrukte, die in der Realität keine Verwendung finden, sondern eine wirkliche Unterstützung des Programmierers. Sie helfen ihm dabei sich auf die Problematik des Fachgebietes, für das er Software entwickelt, zu konzentrieren, anstatt seine Zeit mit Standardproblemen zu verlieren. Literatur [1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, [2] Joshua Fox. When is a Singleton not a Singleton? JavaWorld, [3] Mark Grand. Patterns in Java: a catalog of reusable design patterns illustrated with UML. Wiley & Sons,