Patterns Entwurfsmuster - Wie spart man sich Arbeit ?

Überblick Was sind Patterns Historie Klassifikation, Dokumentation Beispiele Singleton Flyweight Observer Patterns vs. Libraries Anwendung beim Design Probleme

Aufbau Name soll direkt das Problem (und die Lösung) darstellen --> schwierig zu finden Problem das gelöst werden soll Lösung Allgemeine Anordnung von Elementen (Klassen,...), mit denen das Problem lösbar ist kein "konkretes" Design Konsequenzen Einschränkungen time/space tradeoff

Historie Ursprung Architektur Christopher Alexander: A pattern language 1977 „Each pattern describes a problem witch occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way, that you can use the solution a million times over, without ever doing it the same way twice“ Seit ca. 1990: Patterns in Software 1994 GOF: Design Patterns Seither weit akzeptiert XP

Patterntypen Idioms Auf Ebene einer Klasse (z.B. Singleton) Spezifisch für die verwendete Sprache Design patterns Mehrere Klassen, Interaktion (z.B. Observer) Architectural patterns Systemarchitektur (z.B. Client Server) Andere Analysis patterns Datamodel patterns Organizational patterns Antipattern (häufig verwendete falsche Lösung)

Beschreibung von Patterns NameName des Patterns Intentdas zu lösende Problem Also known asandere verbreitete Namen Example Beispiel (-Anwendung) Context Wo kommt dieses Problem vor Problem formale Beschreibung d. Problems Solution Die Lösung (abstrakt) Structure Klassen-, Sequenzdiagramm,... Example code Beispiel-Implementierung Implementation guidelines Variants Known uses

Beispiel: Singleton Intent Eine Klasse soll genau eine Instanz haben Motivation Für manche Klassen ist es wichtig, nur eine Instanz zu haben. Beispielsweise können in einem System viele Drucker sein, aber nur ein Drucker-Spooler (ein Dateisystem, ein Fenstermanager, eine Verbindung zur Datenbank,...). Ein digitales Filter hat einen A/D Wandler. Eine globale Variable erlaubt den Zugriff auf ein gemeinsames Objekt, stellt aber nicht sicher, daß genau eine Instanz existiert. Besser ist es deshalb, wenn die Klasse selbst dafür Sorge trägt, daß nur eine Instanz existiert. Structure public class Singleton { private static Singleton Instance = new Singleton(); private Singleton() {}; public Singleton getInstance(){ return Instance; }

Beispiel: Flyweight Intent Erlaubt die effiziente Verwendung großer Zahlen von Objekten durch gemeinsame Nutzung z.B. Strings, Knoten in Algorithmen, State-Pattern, Buchstabe in Editor,...

Anwendungsbeispiel Daten (z.B. Temperatur) werden vom Sensor erfaßt und vom Prozessor gespeichert. Die Daten sollen zeitsynchron dargestellt werden (mehrfach!) Trennung der Darstellung von der Erfassung (Cohesion) zwei Objekte: Processor und View Wie wird sichergestellt, daß alle Darstellungen immer die gleichen, aktuellen Daten zeigen ? Processor benachrichtigt die Views bei Änderungen Processor muß die Views kennen, z.B. müssen sich diese beim Processor registrieren

Lösung: Sensor gibt neuen Wert an Processor, dieser benachrichtigt Views Gute Lösung ?

Probleme Lösung funktioniert zwar, aber Nur für diesen Fall: Update Mimik ist „hart“ kodiert Integration anderer „Verbraucher“ ? Z.B. Drucker-Objekt: Klasse Processor muß geändert werden Hohe Kopplung Kein Update ohne den Rest des Systems Wenig Cohesion Processor ist für Update-Mechanismus und für Verwaltung des Temperatur-Sensors zuständig

Pattern-Lösung: Observer Define a one-to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. GOFGOF

Observer cont‘d.

Observer Zusammenfassung Durch Abstraktion wird enge Kopplung zwischen Observer und Subject vermieden Cohesion verbessert Möglicherweise Performanceverlust durch unnötige update() Eventuell müssen bei der konkreten Applikation nur bestimmte (eins) Observer benachrichtigt werden, die (allgemeine) Basisklasse weiß dies nicht

Offene Fragen Wie werden Observer gehalten ? Update (-Prozeß) synchron oder asynchron ? Für alle gleich ? Ungültige Observer (Absturz,...) Registrieren sich die Observer für alle Events oder nur für bestimmte ? Genügend Freiraum für die Implementierung Diese wichtigen Aspekte werden vom Pattern nicht festgelegt (Unterschied zu Code-Bibliotheken)

Wichtige Patterns (subjektiv) Singleton Flyweight Iterator Observer Abstract Factory Facade Decorator Proxy

Design (mit) Patterns Low Level Design Aufgabe des Moduls ist bekannt, konkrete Implementierung noch offen Identifikation von Patterns anhand (technischer) Problemstellung durch Abstraktion Analogien zu anderen Systemen (known uses) Patternkataloge Refactoring Anhand des Codes wird Problem identifiziert Dazu passendes Patterns ausgewählt und implementiert Antipatterns High Level Design, Analyse Architectural patterns Data model patterns

Probleme „unpassende“ Patterns Problem wird dem gefundenen Pattern angepasst Tritt auf, wenn zunächst nach „vielversprechenden“ Patterns gesucht wird, ohne das Problem gründlich analysiert zu haben Falsches Vorgehen, richtig: Identifikation des Problems Abstraktion Identifikation des Patterns Eindeutige Beschreibung von Patterns Performance Kann durch allgemeine Lösungen schlechter sein Gegenbeispiel: Flyweight, besseres Design führt trotz Abstraktion zu schnellerer Lösung („Algorithmen“ entscheiden stärker über Performance als Implementierung)

Literatur Alexander et al, A pattern language, Oxford University Press, 1977 Gamma, Helm, Johnson, Vlissides, Design Patterns, Addison Wesley, 1995 Grand, Patterns in Java, Wiley, 1998 Hay, Data model patterns, Dorset House, 1996 Fowler, Analysis Patterns, Addison Wesley, 1997 Buschmann et al, A System of patterns, Wiley, 1996 Waite, Lafore, Object oriented design in java, Waite Group, 1998