Design Patterns 5. Juni 2013
Überblick Was sind Design Patterns? Welche Design Patterns gibt es? Wann sollte man Design Patterns einsetzen? Refactoring und Design Patterns: Welchen Zusammenhang gibt es hier? Taentzer Softwarequalität 2013 128
Was sind Design Patterns? Muster, die sich im Softwareentwurf bewährt haben Gute Design Patterns entstammen direkt der Praxis. Antwort auf wiederkehrende Probleme im SW-Entwurf kein fertiges Stück Code, das direkt in eigenen Code gesetzt werden kann eher eine Art Schablone für die Lösung eines Problems Kritik: Design Patterns müssen immer wieder neu implementiert werden. Literatur: E.Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software(ISBN 0-201- 63361-2), http://en.wikipedia.org/wiki/design_patterns_(book) Taentzer Softwarequalität 2013 129
Sinn und Zweck von Design Patterns Zwecke: Stärkere Modularisierung von Software Integration von unabhängig entwickelten Komponenten Variantenmanagement: Gemeinsamkeiten von Objekten herauskehren, sodass verschiedene Objekte gleich behandelt werden können Arten: Erzeugungsmuster: Factory, Singleton, etc. Strukturmuster: Adapter, Decorator, Fassade, Composite, Proxy, etc. Verhaltensmuster: Observer, Visitor, Iterator, Strategy, etc. Taentzer Softwarequalität 2013 130
Design Patterns zum Entkoppeln Ziel: Software stärker modularisieren Module: gruppiere Komponenten (z.b. Klassen) in ein Modul (z.b. Paket), entwirf Schnittstellen Abstract Data Type: verstecke Datenstrukturen hinter stabilen Schnittstellen Repository: erstelle eine zentrale Datenstruktur mit Schnittstellen zu verschiedenen Clients Layers: verstecke Basisfunktionalität in unteren Schichten, Benutztbeziehung muss azyklisch sein Facade: erstelle eine einfache (spezialisierte) Schnittstelle auf Basis einer umfangreichen (allgemeinen) Proxy: erstelle oder lösche ungeplante Funktionalitäten in transparenter Weise Visitor: füge neue Funktionalität einer stabilen Klassenhierarchie hinzu Iterator: durchlaufe eine Gruppe von Objekten, ohne in die Gruppenstruktur zu schauen Taentzer Softwarequalität 2013 131
Facade Pattern Szenario: Eine Softwarekomponente ist sehr komplex. Deshalb: Bau einer Fassade, hinter der die Komplexität versteckt wird. Beispiel: Implementierung des UML-Metamodells Paket 1 Paket 2 Fassade Client1 Client2 Paket 3 delegiert benutzt Taentzer Softwarequalität 2013 132
Proxy Pattern Proxy als Schnittstelle zu einem anderen Ding typisches Beispiel: ein Remote-Proxy Ein Objekt liegt auf einer anderen Maschine. Das Remote- Proxy ist die Schnittstelle zum entfernt liegenden Objekt. :Client :MyProxy :RemoteSubject Taentzer Softwarequalität 2013 133
Proxy Pattern Client kommuniziert nur über eine Schnittstelle mit dem Proxy bzw. realen Subjekt. Client <<interface>> Subject action() Proxy action() RealSubject action() Taentzer Softwarequalität 2013 134
Design Patterns zur Integration Ziel: Integration von unabhängig entwickelten Komponenten Adapter: konvertiere eine Schnittstelle in eine andere Pipes and Filters: schicke Daten durch eine Reihe von Transformationen Propagator: leite Informationen durch ein Netzwerk von abhängigen Objekten spezieller Propagator: Observer: Untere Objekte benachrichtigen obere über Änderungen. Taentzer Softwarequalität 2013 135
Observer Pattern Subject void attach() void detach() void notify() 0..* Observer void update() Wirkungsweise: attach(): Observer anmelden detach(): Observer abmelden notify(): Observer benachrichtigen for all o:observer { o.update() } Eigenschaften: Broadcast-Benachrichtigung Objekte niederer Schichten können mit Objekten höherer Schichten kommunizieren, ohne die Schichtung zu verletzen. Taentzer Softwarequalität 2013 136
Design Patterns zum Variantenmanagement Ziel: Gemeinsamkeiten von Objekten werden herausgekehrt, sodass verschiedene Objekte gleich behandelt werden können. Superclass: ziehe Gemeinsamkeiten von Objekten in eine gemeinsame Oberklasse Strategy: erstelle eine gemeinsame Schnittstelle für verschiedene Varianten von Algorithmen Delegation: leite Aufgaben von Klasse A an Klasse B weiter Composite: behandle Teil- Ganzes-Hierarchien, atomare und komponierte Objekte werden gleichartig behandelt (Abstract) Factory: bündele die Erzeugung von zusammengehörigen Objekten in einer Klasse Decorator Pattern: füge zusätzliche Funktionalität während der Laufzeit zu Taentzer Softwarequalität 2013 137
Delegation Pattern Client Stack push() pop() List add() remove() Ein Objekt zeigt Funktionalität nach außen, die es intern an andere delegiert. Kritik an der Einführung dieses Patterns? Taentzer Softwarequalität 2013 138
Problem: Strukturierung von graphischen Elementen Text und Graphiken sollen in derselben Weise behandelt werden. Komplexe und simple Strukturen sollen möglichst gleich implementiert werden. Verschiedene Varianten von Graphiken sollen integriert werden können. Taentzer Softwarequalität 2013 139
Composite Pattern Einzelne Instanzen und Gruppen von Instanzen können gleich behandelt werden. Component Beispiel: Graphics Atomic Composite Primitive Composite Circle Rectangle Polygon Taentzer Softwarequalität 2013 140
Problem: Verschiedene Formatierungen derselben Struktur Eine Formatierung erzeugt eine spezielle Instanz einer Struktur. Entkopple die Formatierung von der Struktur Taentzer Softwarequalität 2013 141
Strategy Pattern Kapselung einer Familie von Algorithmen durch eine Schnittstelle Beispiel: Structure FormatingStrategy TreeFormat XMLFormat GraphicalFormat Taentzer Softwarequalität 2013 142
Problem: Verschönerung der Benutzerschnittstelle Mögliche Verschönerungen für einen ListView: Trenner zwischen Einträgen Scroll Bar, um lange Listen anzuzeigen Ein Suchfeld Probleme: Das Benutzerschnittstellenobjekt soll über die Verschönerungen nichts wissen. Explosion von Klassen vermeiden: Eine Lösung durch Vererbung würde eine Unterklasse per Kombination von Verschönerungen erzeugen. Taentzer Softwarequalität 2013 143
Decorator Pattern Das Pattern kann einem Objekt weitere Funktionalität hinzufügen. Alternative zur Vererbung: Unterklassen fügen Funktionalität während der Übersetzung zu. Das Decorator-Pattern kann Objekt während der Laufzeit mit neuem Verhalten versehen. Mehrere Dekorierungen sind möglich. Taentzer Softwarequalität 2013 144
Weitere interessante Design Patterns Command: separate Komposition eines Kommandos vor Ausführung, Standardfunktionalität wie Undo/Redo Singleton: Instanziierung einer Klasse durch nur ein Objekt Memento: Speichere den Inhalt eines Objekts zeitweise so, dass die Speichermethode gewechselt werden kann. Taentzer Softwarequalität 2013 145
Wesentliches zusammengesetztes Design Pattern: Model-View-Controller Ziel: mehrere Sichten auf gemeinsamen Daten Schichtenbildung: Observer Pattern View-Objekte können andere View-Objekte enthalten: Composite Pattern Controller wählt View: Strategy Pattern Controller1 View1 Model Controller2 View2 Controller3 View3 Taentzer Softwarequalität 2013 146
Design Patterns und Refactoring Refactoring, um Design Patterns in die eigene Anwendung zu integrieren Joshua Kerievsky, Refactoring To Patterns, Addison Wesley, 2004 Refactoring To Patterns Catalog: http://industriallogic.com/xp/refactoring/catalog.html Auffinden von Anti-Patterns und Ersetzen durch Design Patterns Anti Patterns Catalog: http://c2.com/cgi/wiki?antipatternscatalog Wie weit geht dieses Verfahren? Taentzer Softwarequalität 2013 147
Zusammenfassung Design Patterns kondensieren das Wissen von erfahrenen Softwareentwicklern. Design Patterns tragen konstruktiv zur Qualitätssicherung bei. Refactoring to Patterns ist der Versuch, ein Design systematisch zu verbessern. Bad Smells Refactorings Design Patterns kaum Werkzeugunterstützung: frühzeitige Einführung von Design Patterns z.b. PatternBox Taentzer Softwarequalität 2013 148