14 Design Patterns 14.1 Einführung 14.2 Composite Pattern
14.1 Einführung 14.1.1 Motivation 14.1.2 Was ist ein Design Pattern? 14.1.3 Beschreibung eines Design Patterns 14.1.4 Katalog von Design Patterns 14.1.5 Organisation des Katalogs 14.1.6 Beziehungen zwischen Design Patterns 14.1.7 Wie Design Patterns Probleme lösen 14.1.8 Literatur
14.1.1 Motivation Das Entwerfen von objektorientierter Software ist schwierig, insbesondere das Entwerfen wiederverwendbarer objektorientierter Software Erfahrene Software-Entwickler vermeiden es, jedes Problem neu zu lösen, stattdessen verwenden sie erfolgreiche Lösungen wieder Daraus entstehen wiederkehrende Muster von Klassen und kommunizierenden Objekten
14.1.2 Was ist ein Design Pattern? Christopher Alexander: Jedes Muster beschreibt ein in unserer Umwelt beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem, so dass diese Lösung beliebig oft angewendet werden kann, ohne sie jemals ein zweites Mal gleich auszuführen. Definition: Ein Design Pattern ist eine Beschreibung zusammenarbeitender Klassen und Objekte, um ein allgemeines Design-Problem in einem bestimmten Kontext zu lösen. Ein Design Pattern besteht aus folgenden Elementen: der Name benennt das Design-Problem und ermöglicht, Software auf einer höheren Abstraktionsebene zu entwerfen das Problem beschreibt die Situation, in welcher das Pattern anzuwenden ist, welches Design-Problem damit adressiert wird und was sein Kontext ist die Lösung beschreibt die Klassen und Objekte, aus denen der Design besteht, sowie ihre Zuständigkeiten und Interaktionen die Konsequenzen beschreiben die Vor- und Nachteile des resultierenden Designs und diskutieren verschiedene Varianten
14.1.3 Beschreibung eines Design Patterns Name vermittelt knapp und präzise den wesentlichen Inhalt des Patterns Klassifizierung definiert den Aufgabenbereich und den Gültigkeitsbereich des Patterns Auch bekannt als gibt andere wohlbekannte Namen für das Pattern an Zweck beschreibt kurz, was das Pattern macht und welche Fragestellungen oder Probleme es behandelt Motivation besteht aus einem Szenario, welches ein konkretes Design-Problem schildert und wie das Pattern dieses Problem löst Anwendbarkeit beschreibt, in welchen Situationen das Pattern angewendet werden kann Struktur besteht aus einer grafischen Repräsentation des Patterns (Klassen-, Objekt-, Sequenzdiagramm) Teilnehmer beschreibt die am Pattern beteiligten Klassen und Objekte sowie ihre Zuständigkeiten Interaktionen beschreibt, wie die Teilnehmer zur Erfüllung der gemeinsamen Aufgabe zusammenarbeiten Konsequenzen beschreibt die Vor- und Nachteile des Patterns und welche Varianten es gibt Implementierung präsentiert Fallen, Tipps oder Techniken für die Implementierung des Patterns Beispielcode diskutiert Codefragmente zur Veranschaulichung des Patterns Bekannte Verwendungen führt Beispiele von existierenden Systemen auf, in denen das Pattern eingesetzt wird Verwandte Patterns setzt das Pattern in Bezug zu andern Patterns, diskutiert die Unterschiede und erläutert mögliche Kombinationen
14.1.4 Katalog von Design Patterns Abstract Factory Biete eine Schnittstelle zum Erzeugen von Familien verwandter oder voneinander abhängiger Objekte, ohne ihre konkreten Klassen zu benennen. Adapter Passe die Schnittstelle einer Klasse an eine andere von ihren Klienten erwartete Schnittstelle an. Das Adapter Pattern lässt Klassen zusammenarbeiten, die wegen inkompatibler Schnittstellen sonst nicht in der Lage dazu wären. Bridge Entkopple eine Abstraktion von ihrer Implementierung, so dass beide unabhängig voneinander variiert werden können. Builder Trenne die Konstruktion eines komplexen Objekts von seiner Repräsentation, so dass derselbe Konstruktionsprozess unterschiedliche Repräsentationen erzeugen kann. Chain of Responsibility Vermeide die Koppelung des Auslösers einer Anfrage an seinen Empfänger, indem mehr als ein Objekt die Möglichkeit erhält, die Anfrage zu erledigen. Verkette die empfangenden Objekte und leite die Anfrage an der Kette entlang, bis ein Objekt sie erledigt. Command Kapsle einen Befehl als ein Objekt. Dies ermöglicht es, Klienten mit verschiedenen Anfragen zu parametrisieren, Operationen in eine Warteschlange zu stellen, ein Logbuch zu führen und Operationen rückgängig zu machen. Composite Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien zu repräsentieren. Das Composite Pattern ermöglicht es Klienten, einzelne Objekte sowie Kompositionen von Objekten einheitlich zu behandeln. Decorator Erweitere ein Objekt dynamisch um Zuständigkeiten. Ein Decorator bietet eine flexible Alternative zur Subklassierung, um die Funktionalität einer Klasse zu erweitern. Façade Biete eine einheitliche Schnittstelle zu einer Menge von Schnittstellen eines Subsystems. Die Façade Klasse definiert eine abstrakte Schnittstelle, welche die Verwendung des Subsystems vereinfacht. Factory Method Definiere eine Klassenschnittstelle mit Operationen zum Erzeugen eines Objekts, aber lasse Unterklassen entscheiden, von welcher Klasse das zu erzeugende Objekt ist. Factory Methoden ermöglichen es einer Klasse, die Erzeugung von Objekten an Unterklassen zu delegieren. Flyweight Nutze Objekte kleinster Granularität gemeinsam, um grosse Mengen von ihnen effizient verwenden zu können.
Interpreter Definiere für eine gegebene Sprache eine Repräsentation der Grammatik sowie einen Interpreter, der die Repräsentation nutzt, um Sätze in der Sprache zu interpretieren. Iterator Biete eine Möglichkeit, um auf die Elemente eines zusammengesetzten Objekts sequentiell zugreifen zu können, ohne die zugrundeliegende Repräsentation offenzulegen. Mediator Definiere ein Objekt, welches das Zusammenspiel einer Menge von Objekten in sich kapselt. Ein Mediator fördert die lose Koppelung, indem er Objekte davon abhält, aufeinander explizit Bezug zu nehmen, und ermöglicht, das Zusammenspiel der Objekte unabhängig zu variieren. Memento Erfasse und externalisiere den internen Zustand eines Objekts, ohne seine Kapselung zu verletzen, so dass das Objekt später in diesen Zustand zurückversetzt werden kann. Observer Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustands eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt und automatisch aktualisiert werden. Prototype Bestimme die Arten zu erzeugender Objekte durch die Verwendung eines prototypischen Exemplars, und erzeuge neue Objekte durch Kopieren dieses Prototypen. Proxy Kontrolliere den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts. Singleton Sichere ab, dass eine Klasse genau ein Exemplar besitzt, und stelle einen globalen Zugriffspunkt darauf bereit. State Ermögliche es einem Objekt, sein Verhalten zu ändern, wenn sein interner Zustand sich ändert. Es wird so aussehen, als ob das Objekt seine Klasse gewechselt hat. Strategy Definiere eine Familie von Algorithmen, kapsele jeden einzelnen und mache sie austauschbar. Das Strategy Pattern ermöglicht es, den Algorithmus unabhängig von den nutzenden Klienten zu variieren. Template Method Definiere das Skelett eines Algorithmus in einer Operation und delegiere einzelne Schritte an Unterklassen. Die Verwendung einer Template Method ermöglicht es Subklassen, bestimmte Schritte eines Algorithmus zu überschreiben, ohne seine Struktur zu verändern. Visitor Kapsle eine auf den Elementen einer Objektstruktur auszuführende Operation als ein Objekt. Das Visitor Pattern ermöglicht es, eine neue Operation zu definieren, ohne die Klassen der von ihr bearbeiteten Elemente zu verändern.
14.1.5 Organisation des Katalogs Design Patterns können nach ihrer Aufgabe klassifiziert werden: Erzeugungsmuster betreffen den Prozess der Objekterzeugung Strukturmuster befassen sich mit der Zusammensetzung von Klassen und Objekten Verhaltensmuster definieren, wie Klassen und Objekte zusammenarbeiten und ihre Zuständigkeiten aufteilen Design Patterns können nach ihrem Gültigkeitsbereich klassifiziert werden: Klassenbasierte Patterns befassen sich mit Klassen und ihren Unterklassen (statische Beziehungen) Objektbasierte Patterns befassen sich mit Objektbeziehungen, die sich zur Laufzeit ändern können (dynamische Beziehungen) Erzeugungsmuster Strukturmuster Verhaltensmuster klassenbasiert Factory Method Adapter Interpreter Template Method objektbasiert Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
14.1.6 Beziehungen zwischen Design Patterns Manche Patterns werden oft zusammen genutzt (z.b. Composite und Iterator) Manche Patterns stellen Alternativen zueinander dar (z.b. Prototype und Abstract Factory) Manche Patterns führen zu einem ähnlichen Design, obschon sie unterschiedliche Ziele verfolgen (z.b. Composite und Decorator) Manche Patterns haben Beziehungen zu andern Patterns
14.1.7 Wie Design Patterns Probleme lösen Finden passender Objekte, insbesondere solcher, die keine Entsprechung in der realen Welt haben Bestimmen der Objektgranularität (Grösse und Anzahl von Objekten) Spezifizieren von Objektschnittstellen durch Identifikation der zentralen Operationen und zu vermittelnden Daten Spezifizieren von Objektimplementierungen (z.b. Programmieren gegen Schnittstellen) Anwenden von Wiederverwendungsmechanismen wie Klassenvererbung und Objektkomposition (Delegation) Verstehen von Laufzeitstrukturen wie Assoziations- und Aggregationsbeziehungen Vorsehen von Veränderungen im Design durch Einbau von Flexibilität: Erzeugen von Objekten ohne explizite Nennung ihrer Klassen Unabhängigkeit von spezifischen Operationen Unabhängigkeit von Hardware- oder Software-Plattformen Unabhängigkeit von Algorithmen Lose Kopplung zwischen Klassen Möglichkeit zur Erweiterung von Funktionalität Möglichkeit zur Änderung bestehender Klassen Design Patterns können einen Design unnötig kompliziert machen oder zu Performance-Einbussen führen Design Patterns sollten nur angewendet werden, wenn die gebotene Flexibilität auch wirklich benötigt wird!
14.1.8 Literatur Erich Gamma, Richard Helm, Ralph E. Johnson Design Patterns. Elements of Reusable Object-Oriented Software Addison Wesley, 1995 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad A System of Patterns. Pattern-Oriented Software Architecture John Wiley & Sons, 1996 Douglas C. Schmidt, Michael Stal, Hans Rohnert Pattern-Oriented Software Architecture 2. Patterns for Concurrent and Networked Objects John Wiley & Sons, 2000 Eric Freeman, Elisabeth Freeman, Kathy Sierra Head First Design Patterns O'Reilly, 2004 Steven J. Metsker, William C. Wake Design Patterns in Java Addison Wesley, 2006
14.2 Composite Pattern Objektbasiertes Strukturmuster 14.2.1 Zweck 14.2.2 Motivation 14.2.3 Anwendbarkeit 14.2.4 Struktur 14.2.5 Teilnehmer 14.2.6 Interkationen 14.2.7 Konsequenzen 14.2.8 Implementierung 14.2.9 Beispielcode 14.2.10 Bekannte Verwendungen 14.2.11 Verwandte Patterns
14.2.1 Zweck Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien zu repräsentieren. Das Composite Pattern ermöglicht es Klienten, einzelne Objekte sowie Kompositionen von Objekten einheitlich zu behandeln.
14.2.2 Motivation Kontext: Zeicheneditoren ermöglichen es oft, komplexe Figuren aus einfachen Figuren wie Linien, Rechtecke, Kreise usw. zusammenzusetzen. Problem: Wie können sowohl einfache als auch zusammengesetzte Figuren einheitlich behandelt (zeichnen, verschieben, drehen usw.) werden? Lösung: Es wird eine abstrakte Basisklasse Figure definiert, welche sowohl einfache als auch zusammengesetzte Figuren repräsentiert. Die Schnittstelle von Figure enthält Operationen für das Zeichnen von Figuren und für die Verwaltung von Kindobjekten. Die Unterklassen Line, Rectangle und Circle definieren einfache Figuren und implementieren die Zeichen-Operationen. Die Klasse ComposedFigure definiert eine zusammengesetzte Figur und delegiert die Zeichen-Operationen an ihre Kindobjekte. Eine zusammengesetzte Figur kann wieder zusammengesetzte Figuren enthalten. Dadurch können beliebig tiefe Baumstrukturen aufgebaut werden:
14.2.3 Anwendbarkeit Das Composite Pattern wird angewendet, wenn Teil-Ganzes-Hierarchien von Objekten repräsentiert werden sollen Klienten sowohl einzelne als auch zusammengesetzte Objekte einheitlich behandeln sollen
14.2.4 Struktur Das folgende Klassendiagramm zeigt die Strukur des Composite Patterns: Eine typische Objektstruktur sieht wie folgt aus:
14.2.5 Teilnehmer Component Leaf Composite Client deklariert die Schnittstelle aller Objekte der Baumstruktur implementiert eventuell ein Defaultverhalten deklariert eine Schnittstelle für die Verwaltung von Kindobjekten definiert optional eine Schnittstelle für den Zugriff auf die Elternkomponente repräsentiert Blattobjekte definiert das Verhalten für die einfachen Objekte definiert das Verhalten für Komponenten mit Kindobjekten speichert die Kindobjekte implementiert die Kindobjekt-spezifischen Operationen manipuliert Objekte in der Baumstruktur über die gemeinsame Schnittstelle
14.2.6 Interaktionen Klienten interagieren mit den Objekten der Baumstruktur über die Schnittstelle von Component Ein Leaf-Objekt behandelt eine Anfrage selbst Ein Composite-Objekt leitet die Anfrage an seine Kindobjekte weiter
14.2.7 Konsequenzen Vorteile: Nachteile: Einfache Objekte können rekursiv zu komplexeren Objekten zusammengesetzt werden Klienten können einfache und zusammengesetzte Objekte gleich behandeln Neue Komponenten können einfach hinzugefügt werden Der Design kann zu allgemein sein, indem z.b. die Typen der Kindobjekte einer Komponente nicht eingeschränkt werden können
14.2.8 Implementierung Explizite Referenzen auf das Elternobjekt können die Traversierung und Verwaltung der Baumstruktur vereinfachen Die gemeinsame Nutzung von Komponenten kann den Speicherbedarf senken Die Maximierung der Komponentenschnittstelle erlaubt, den Unterschied zwischen einfachen und zusammengesetzten Objekten weitgehend zu verstecken Das Deklarieren der Verwaltungsoperationen für Kindobjekte in der Component-Klasse verschafft Transparenz, weil alle Komponenten gleich behandelt werden Composite-Klasse gibt die Sicherheit, dass keine Kindobjekte zu Blattkomponenten hinzugefügt werden Der Behälter für die Kindobjekte sollte in der Composite-Klasse definiert werden Die Ordnung der Kindobjekte kann in einer Anwendung relevant sein Zwischenspeichern von Information beim Traversieren der Baumstruktur kann das Laufzeitverhalten verbessern Das Löschen von Komponenten erfolgt normalerweise durch die Elternkomponente
14.2.9 Beispielcode Widerstände sind elektrische Bauteile mit einem bestimmten Widerstandswert. Aus einzelnen Widerständen lassen sich hierarchisch Widerstandsnetze zusammensetzen: Dabei gelten folgende Regeln: Ein einzelner Widerstand ist ein Netz Zwei Netze können in Serie, d.h. hintereinander, geschaltet werden Das resultierende Netz hat den Widerstandswert R = R 1 + R 2 Zwei Netze können parallel, d.h. nebeneinander, geschaltet werden Der Widerstandswert des resultierenden Netzes erfüllt die Gleichung 1/R = 1/R 1 + 1/R 2 Das folgende Klassendiagramm zeigt die Umsetzung mithilfe des Composite Patterns: Das Interface ResistorNet definiert die Schnittstelle eines Widerstandsnetzes und enthält Methoden zum Bestimmen des Widerstandswerts und zum Verwalten von Teilnetzen: public interface ResistorNet { public double getvalue(); public void add(resistornet net); public void remove(resistornet net); public List getsubnets();
Die Unterklasse Resistor implementiert einen einfachen Widerstand: public class Resistor implements ResistorNet { private final double value; public Resistor(double value) { this.value = value; public double getvalue() { return value; public void add(resistornet net) { throw new UnsupportedOperationException(); public void remove(resistornet net) { throw new UnsupportedOperationException(); public List getsubnets() { throw new UnsupportedOperationException(); Die abstrakte Unterklasse Connection repräsentiert eine allgemeine Schaltung und implementiert die Methoden zum Verwalten von Teilnetzen: public abstract class Connection implements ResistorNet { protected List subnets = new ArrayList(); public void add(resistornet net) { subnets.add(net); public void remove(resistornet net) { subnets.remove(net); public List getsubnets() { return subnets; Die konkreten Unterklassen Serial und Parallel implementieren eine serielle bzw. parallele Schaltung und berechnen die entsprechenden Widerstandswerte: public class Serial extends Connection { public double getvalue() { double value = 0; for (ResistorNet subnet : subnets) value += subnet.getvalue(); return value; public class Parallel extends Connection { public double getvalue() { double value = 0; for (ResistorNet subnet : subnets) value += 1 / subnet.getvalue(); return 1 / value;
Die Klasse Client implementiert einen Klienten, welcher ein Widerstandsnetz aufbaut und seinen Widerstandswert bestimmt: public class Client { public static void main(string[] args) { Resistor r1 = new Resistor(100); Resistor r2 = new Resistor(200); Resistor r3 = new Resistor(300); Resistor r4 = new Resistor(400); Resistor r5 = new Resistor(500); Resistor r6 = new Resistor(600); ResistorNet n1 = new ParallelNet(); n1.add(r1); n1.add(r2); ResistorNet n2 = new SerialNet(); n2.add(n1); n2.add(r3); ResistorNet n3 = new SerialNet(); n3.add(r4); n3.add(r5); ResistorNet n4 = new ParallelNet(); n4.add(n2); n4.add(n3); n4.add(r6); System.out.println(n4.getValue());
14.2.10 Bekannte Verwendungen Ursprüngliche View-Klasse von Smalltalk Klassenbibliotheken und Frameworks für grafische Benutzeroberflächen Anwendungen der Finanzwelt, in welchen Portfolios mehrere Anlagen zusammenfassen
14.2.11 Verwandte Patterns Die Verbindung zwischen Komponente und Elternobjekt wird oft zur Implementierung des Chain of Responsibility Pattern verwendet Das Decorator Pattern wird oft mit dem Composite Pattern kombiniert Das Flyweight Pattern ermöglicht, Komponenten gemeinsam zu nutzen Das Iterator Pattern kann verwendet werden, um die Baumstruktur zu traversieren Das Visitor Pattern kann Operationen lokalisieren, die sonst in die Composite- und Leaf-Klasse verteilt werden müssen