Design Patterns. 5. Juni 2013

Transkript

1 Design Patterns 5. Juni 2013

2 Ü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

3 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 ), Taentzer Softwarequalität

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 Problem: Verschiedene Formatierungen derselben Struktur Eine Formatierung erzeugt eine spezielle Instanz einer Struktur. Entkopple die Formatierung von der Struktur Taentzer Softwarequalität

16 Strategy Pattern Kapselung einer Familie von Algorithmen durch eine Schnittstelle Beispiel: Structure FormatingStrategy TreeFormat XMLFormat GraphicalFormat Taentzer Softwarequalität

17 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

18 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

19 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

20 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

21 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: Auffinden von Anti-Patterns und Ersetzen durch Design Patterns Anti Patterns Catalog: Wie weit geht dieses Verfahren? Taentzer Softwarequalität

22 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