Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Kapitel 6
Entwurfsmuster (Design Patterns)
Stand: 27.11.2007
© 2000-2007 Dr. Günter Kniesel
Einführung: Die Grundidee von Pattern
Pattern (Muster) wurden zuerst im Bereich der Architektur beschrieben.
Grundlegende Idee: Alle Ingenieurdisziplinen benötigen eineGrundlegende Idee: Alle Ingenieurdisziplinen benötigen eine Terminologie ihrer wesentlichen Konzepte sowie eine Sprache, die diese Konzepte in Beziehung zueinander setzt.
Ziele von Pattern in der Welt der Software:Dokumentation von Lösungen wiederkehrender Probleme umDokumentation von Lösungen wiederkehrender Probleme, um Programmierer bei der Softwareentwicklung zu unterstützen. Schaffung einer gemeinsamen Sprache, um über Probleme und ihre Lö hLösungen zu sprechen.Bereitstellung eines standardisierten Katalogisierungsschemas um erfolgreiche Lösungen aufzuzeichnen.
Bei Pattern handelt es sich weniger um eine Technologie (wie z.B. bei UML) als um eine Kultur der Dokumentation und Unterstützung guter
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-2 R O O T S
UML), als um eine Kultur der Dokumentation und Unterstützung guter Softwarearchitektur.
Einführung: Literatur zu Pattern und SoftwareErich Gamma Richard Helm Ralph Johnson John Vlissides (Gang of Four):Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four):"Design Patterns - Elements of Reusable Object-Oriented Software"Addison-Wesley, 1995
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal (Gang of Five): "Pattern-Oriented Software Architecture - A System of Patterns"John Wiley & Sons, 1996
Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: "Object Oriented Reengineering Patterns", Morgan Kaufman, 2002
Patterns im WWWPatterns Home Page: http://www.hillside.net/g pPortland Pattern Repository: http://c2.com/ppr/index.htmlBrad Appleton: "Patterns and Software: Essential Concepts and Terminology„ http://www.bradapp.net/docs/patterns-intro.htmlp pp pDoug Lea, Patterns-Discussion FAQ, http://gee.oswego.edu/dl/pd-FAQ/pd-FAQ.htmlBuchliste: http://c2.com/cgi/wiki?PatternRelatedBookList
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-3 R O O T S
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%b = 30% Modelc = 20%
- X - X
a = 50%b = 30%c = 20%
View + Controller View + Controller
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-4 R O O T S
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%b = 30%c = 20%Änderungen am
Modell werden propagiertpropagiert
- X - X
a = 50%b = 30%c = 20%Views melden sich an
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-5 R O O T S
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%b = 30%c = 20%
- X - X
a = 50%
- X
b = 30%c = 20%
• mehrere Views sind gleichzeitig möglich• neue Views können ohne Änderung des Modells hinzugefügt werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-6 R O O T S
• neue Views können ohne Änderung des Modells hinzugefügt werden
Einführung: Das MVC-Framework in Smalltalk als Beispiel
Propagierung von Änderungen: Observer Patternkommt z.B. auch bei Client/Server-Programmierung
a = 50%b = 30%c = 20%
zur Benachrichtigung der Clients zum Einsatz- X
- XGeschachtelte Views: Composite Pattern
View enthält weitere Views, wird aber wie ein einziger View behandelteinziger View behandelt.kommt z.B. auch bei Parsebäumen im Compilerbauzum Einsatz (Ausdrücke).
Reaktion auf Events im Controller: Strategy PatternEingabedaten können validiert werden - XEingabedaten können validiert werden (Daten, Zahlen, etc.).Controller können zur Laufzeit gewechselt werden.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-7 R O O T S
kommt z.B. auch bei der Codeerzeugung im Compilerbauzum Einsatz (Code für verschiedene CPUs).
Überblick
Einführung Grundidee, Literatur, MVC-Framework als Beispiel
Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandFacade, Singleton, Proxy, Adapter, BridgeFactory Method, Abstract FactoryComposite, Visitor
Patterns Create ArchitecturesPatterns Create ArchitecturesBridge, Abstract Factory, Singleton
Nutzen von PatternsZusammenfassung und Ausblick
Arten von Patterns, AbgrenzungWeiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-8 R O O T S
Das Observer Pattern: Einführung
AbsichtStellt eine 1-zu-n Beziehung zwischen Objekten herWenn das eine Objekt seinen Zustand ändert, werden die davon abhängigen Objekte benachrichtigt und entsprechend aktualisiert
Andere Namen"Dependents", "Publish-Subscribe", "Listener"
MotivationVerschiedene Objekte sollen zueinander konsistent gehalten werdenVerschiedene Objekte sollen zueinander konsistent gehalten werdenAndererseits sollen sie dennoch nicht eng miteinander gekoppelt sein. (bessere Wiederverwendbarkeit)
Diese Ziele stehen in einem gewissen Konflikt zueinander. Man spricht von „conflicting forces“, also gegenläufig wirkenden Kräften.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-9 R O O T S
g g g g
Das Observer Pattern: Beispiel
Trennung von Daten und DarstellungWenn in einer Sicht Änderungen vorgenommen werden, werden alle anderen Sichten aktualisiert – Sichten sind aber unabhängig voneinander.
a = 50%a = 50%b = 30%c = 20%
- X - X- X
a = 50%b = 30%
20%
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-10 R O O T S
c = 20%
Das Observer Pattern: Anwendbarkeit
Das Pattern ist im folgenden Kontext anwendbar:
AbhängigkeitenEin Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt. Aufteilung dieser Aspekte in verschiedene Objekte erhöht Variationsmöglichkeit und Wiederverwendbarkeit.
FolgeänderungenÄnderungen an einem Objekt erfordert Änderungen an anderen Objekten. E i t i ht b k t i i l Obj kt ä d t d üEs ist nicht bekannt, wieviele Objekte geändert werden müssen.
Lose Kopplungpp gObjekte sollen andere Objekte benachrichtigen können, ohne Annahmen über die Beschaffenheit dieser Objekte machen zu müssen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-11 R O O T S
Rollenaufteilung / Verantwortlichkeiten
Observer („Beobachter“ auch: Subscriber, Listener)update (auch: handleEvent)
Reaktion auf Zustandsänderung des Subjects
Subject („Subjekt“ auch: Publisher)attach(auch: register addListener)attach(auch: register, addListener)
Observer registrierendetach (auch: unregister, removeListener)
registrierte Observer entfernennotify
update-Methoden aller registrierten Observer aufrufenp g
setStatezustandsändernde Operation(en)zustandsändernde Operation(en)für beliebige Clients
getStatebf d kt ll Z t d
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-13 R O O T S
abfrage des aktuellen Zustandsdamit Observer feststellen können was sich genau geändert hat
Das Observer Pattern: Zusammenarbeit der Objekte
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-14 R O O T S
Das Observer Pattern: KonsequenzenUnabhängigkeitUnabhängigkeit
„Subjekte“ und „Beobachter“ können unabhängig voneinander variiert werden.„Beobachter“ können hinzugefügt werden, ohne „Subjekte“ oder andere Beobachter“ zu ändern„Beobachter zu ändern.
„Subjekte“ können ohne „Beobachter“ wiederverwendet werden. Umgekehrt ebenfalls.
„Broadcast“-NachrichtenSubjekt benachrichtigt alle angemeldeten BeobachterB b ht t h id b i N h i ht b h d l d i iBeobachter entscheiden, ob sie Nachrichten behandeln oder ignorieren
Abstrakte KopplungSubjekte aus tieferen Schichten eines Systems können mit Beobachtern aus höheren Schichten kommunizieren, ohne die Schichten zu verletzen.
Unerwartete Aktualisierungen Kleine Zustandsänderungen des Subjekts können komplexe Folgen haben.Auch uninteressante Zwischenzustände können unnötige Aktualisierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-15 R O O T S
auslösen.
Das Observer Patterns: Implementierung
Speicherung der Beziehung zwischen Subjekt und BeobachterInstanzvariable im Subjekt oder ...globale (Hash-)Tabelleglobale (Hash )Tabelle
Beobachtung mehrer SubjekteDie graphische Darstellung einer Tabelle könnte mehrere Subjekte beobachten. Dann muss die „update()“-Methode einen zusätzlichen Parameter haben, der das Subjekt angibt.
Wer ruft "notify()" auf?) " tSt t ()" M th d d S bj kta) "setState()"-Methode des Subjekts:
+ Klienten können Aufruf von "notify()" nicht vergessen.– Aufeinanderfolgende Aufrufe von "setState()" führen zu überflüssigen Aktualisierungen.
b) Klienten:+ Mehrere Änderungen können akkumuliert werden.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-16 R O O T S
– Klienten vergessen möglicherweise Aufruf von "notify()".
Implementierung des Observer Patterns
KonsistenzZustand eines Subjekts muss vor Aufruf von "notify()" konsistent sein.Vorsicht bei Vererbung bei Aufruf jeglicher geerbert Methoden die möglicherweise „notify()“ -aufrufen :
public class MySubject extends Subject {public void doSomething(State newState) {
d S thi ( St t ) // ft " tif ()" fsuper.doSomething(newState); // ruft "notify()" auf
this.modifyMyState(newState); // zu spät!}
}}
Dokumentation von „notify()“-Aufrufen erforderlich„ y()Besser: In Oberklsse „Template-Method Pattern“ anwenden um sicherzustellen, dass „notify()“-Aufrufe immer am Schluß einer Methode stattfinden
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-17 R O O T S
stattfinden.
Das Observer Patterns: Implementierung
Wie werden die Informationen über eine Änderung weitergegeben: h“ ll“„push“ vs. „pull“
push: Subjekt übergibt in „update()“ detaillierte Informationen über Änderungen.p j g p () g+ Berechnungen werden seltener durchgeführt.– Beobachter sind weniger wiederverwendbar
pull: Subjekt übergibt in „update()“ keinerlei Informationen, aber die Beobachter müssen sich die Informationen vom Subjekt holen
+ Geringere Kopplung zwischen Subjekt und Beobachter.– Berechnungen werden häufiger durchgeführt.
Zwischenformen sind möglich
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-18 R O O T S
Das Observer Patterns: Implementierung
Fortgeschrittene Techniken
Differenzierung von EreignissenDifferenzierung von EreignissenBeobachter-Registrierung nur für spezielle Ereignisseweniger "Rückfragen" / höhere Effizienz
ChangeManagerlt t B i h i h S bj kt d B b htverwaltet Beziehungen zwischen Subjekt und Beobachter.
(Speicherung in Subjekt und Beobachter kann entfallen.)definiert die Aktualisierungsstrategiebenachrichtigt alle Beobachterverzögerte Benachrichtigung möglich
Insbesondere wenn mehrere Subjekte verändert werden müssen bevor dieInsbesondere wenn mehrere Subjekte verändert werden müssen, bevor die Aktualisierungen der Beobachter Sinn macht
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-19 R O O T S
Das Observer Patterns: Bekannte Anwendungen
Bekannte AnwendungenModel-View-Controller-Framework in SmalltalkJava Foundation Classes / SwingOberon SystemDiverse Client/Server Modelle z B Java RMIDiverse Client/Server-Modelle, z.B. Java RMI
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-20 R O O T S
Einführung: Das MVC-Framework in Smalltalk als Beispiel
Propagierung von Änderungen: Observer Patternkommt z.B. auch bei Client/Server-Programmierung
a = 50%b = 30%c = 20%
zur Benachrichtigung der Clients zum Einsatz- X
- XGeschachtelte Views: Composite Pattern
View enthält weitere Views, wird aber wie ein einziger View behandelteinziger View behandelt.kommt z.B. auch bei Parsebäumen im Compilerbauzum Einsatz (Ausdrücke).
Reaktion auf Events im Controller: Strategy PatternEingabedaten können validiert werden - XEingabedaten können validiert werden (Daten, Zahlen, etc.).Controller können zur Laufzeit gewechselt werden.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-21 R O O T S
kommt z.B. auch bei der Codeerzeugung im Compilerbauzum Einsatz (Code für verschiedene CPUs).
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Let's play patterns!
Aufgabe
IntegerBagMenge von integers
IntegerAdderAddiert alles was sich im Bag befindet und gibt Ergebnis aus
I t P i tIntegerPrinterGibt den kompletten Inhalt eines IntegerBag aus
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-23 R O O T S
Mögliche Lösung
Siehe http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-24 R O O T S
Das Strategy Pattern: Einführung
AbsichtKapselung einer Familie von Algorithmen mit der Möglichkeit, sie beliebig auszutauschen.
MotivationBerechnung von ZeilenumbrüchenBerechnung von Zeilenumbrüchen
mehrere Algorithmen können eingesetzt werdenneue Varianten sollen später hinzugefügt werden können
S (f )Struktur (für obiges Beispiel)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-25 R O O T S
Das Strategy Pattern: Anwendbarkeit und Struktur
Anwendbar in folgendem KontextEinige ähnliche Klassen unterscheiden sich nur in gewissen Aspekten des Verhaltens. Diese können in ein Strategie-Objekt ausgelagert werden.g j g gVerhalten ist abhängig von äußeren RandbedingungenVerschiedene Varianten eines Algorithmus werden benötigt
B it t hi dli h Z it /Pl t k l itätz.B. mit unterschiedlicher Zeit-/Platzkomplexität.Kapselung von Daten eines komplexen Algorithmus
Struktur (allgemein)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-26 R O O T S
Das Strategy Pattern: Implementierung
Alternative Schnittstellen zwischen Kontext und Strategien1. Kontext übergibt alle relevanten Daten an die Strategie-Methode2. Kontext übergibt this an Strategie-Methode flexibelste Lösung3. Strategie-Objekt speichert bei Initialisierung feste Referenz auf Kontext
Implementierung von Default-Verhalten möglichIn der Kontext-Klasse wird ein Default-Verhalten verwendet, wenn kein Strategie-Objekt gesetzt ist.
(T1,...,Tn)(Context)
default
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-27 R O O T S
(T1,...,Tn) (T1,...,Tn) (T1,...,Tn)(Context) (Context) (Context)
Implementierung: Fallunterscheidung in Kontext
ContextInterface() {if ( ll)
...if (strategy == null)
... default ...else strategy.AlgorithmInterface();
}
Vorteile???
NachteileUneinheitliche Lösung: Kontext muss Default-Strategie kennen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-28 R O O T S
Implementierung: „Default-Strategie“-Klasse
ContextInterface() {...
...strategy.AlgorithmInterface();...
}
AlgorithmInterface() {d f lt
Dies Variante ist als das "Null Pattern"
bekannt.
Dies Variante ist als das "Null Pattern"
bekannt.
Dies ist eine Anwendung des "Null Object Pattern"
Ideejede Zuweisung "Strategy s = null;" ersetzen durch "Strategy s = new DefaultStrategy();"
... default ...}
Abfragen auf null und entsprechende Fallunterscheidungen löschenVorteile
einheitliche Lösung, klare Trennung von Kontext und Strategien
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-29 R O O T S
einheitliche Lösung, klare Trennung von Kontext und Strategien lesbarerer Code
Das Strategy Pattern: Konsequenzen
KonzeptuellFamilie von zusammengehörigen AlgorithmenAuswahl verschiedener Implementierungen desselben Verhaltensdynamische Alternative zu UnterklassenbeziehungPolymorphismus statt Fallunterscheidungen (if then else switch case)Polymorphismus statt Fallunterscheidungen (if-then-else, switch-case)leichtere Erweiterbarkeit
Konsequenzen aus ImplementierungKontext übergibt evtl. Parameter, die nicht jedes Strategie-Objekt benötigt
thi üb b i t ll ithis zu übergeben ist allgemeinerZusätzliche Nachrichten zwischen Kontext und Strategie Erhöhte Anzahl an Objekten
Möglicherweise können aber Strategie-Objekte gemeinsam verwendet werdenFlyweight-Pattern
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-30 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Zwischenfazit: Was also sind Patterns?
Definition: Was ist jetzt also ein Pattern?
Definitionsvorschlag
"A pattern is the abstraction from a concrete formwhich keeps recurring in specific non-arbitrary contexts."which keeps recurring in specific non arbitrary contexts.
Dirk Riehle, Heinz Züllighoven:"Understanding and Using Patterns in Software Development",
TAPOS 2, 1 (1996).( )
Definitionsvorschlag
"Each pattern is a three-part rule, which expresses a relation between a certain context,p ,
a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve
themselves "
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-32 R O O T S
themselves.Richard Gabriel, on the Patterns Home Page
Aber nicht...
"A pattern is a solution to a problem in a context."anonym ;-)
GegenbeispielProblem: Wie werden Objekte im Speicher alloziert?K t t Ei ß OO S t i i R h it i t llKontext: Ein großes OO-System in einem Rechner mit virtuellem Speicher.Lösung: Führe einige typische Anwendungen durch und stelle fest, g g yp g ,welche Objekte häufig miteinander kommunizieren. Plaziere diese Objekte auf derselben Seite im virtuellen Speicher.
BegründungDas ist kein Pattern - es ist "nur" eine Lösung für ein Problem in einem Kontext. Damit es zu einem Pattern werden kann, muss ein Lösungsprinzip abstrahiert werden das auch für andere wiederkehrende Probleme in
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-33 R O O T S
abstrahiert werden, das auch für andere wiederkehrende Probleme in ähnlichen Kontexten eingesetzt werden kann.
Bestandteile eines Patterns: Kontext, Problem, Forces
KontextDie Vorbedingungen unter denen das Pattern benötigt wird. ( Anwendbarkeit des Pattern)( Anwendbarkeit des Pattern)
ProblemBeschreibung des Problems oder der Absicht des PatternsZiel und gewünschte Eigenschaften die in einem bestimmten Kontext mit bestimmten Randbedingungen/Kräften erreicht werden sollen. Die Kräfte und die Ziele scheinen sich zu widersprechen.
Randbedingung / Kräfte (Forces)Randbedingung / Kräfte (Forces)Die relevanten Randbedingungen und Einschränkungen, die berücksichtigt werden müssen.Wi di it i d i t i d i K flikt t hWie diese miteinander interagieren und im Konflikt stehen.Die daraus entstehenden Kosten.Typischerweise durch ein motivierendes Szenario illustriert.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-34 R O O T S
Bestandteile eines Patterns: Lösung
Die Lösung wird beschrieben durch die Teilnehmer, ihre Rollen, ihre statischen Beziehungen und dynamische Zusammenarbeitg y
TeilnehmerDie Typen (Interfaces und Klassen) die in der Lösung eine Rolle spielen.
RollenAlle Namen in der Beschreibung eines Patterns bezeichnen nur die Rollen der entsprechenden Interfaces, Klassen, Methoden, Felder, Assotiationen.p , , , ,Sie werden bei der Implementierung durch zur Anwendung und Rolle passende Namen ersetztBeispiel: RolleBeispiel: Rolle
Statische Beziehungen und dynamische ZusammenarbeitKlassendiagramm, dynamisches Diagramm, TextMeistens ist das Verständnis des dynamischen Verhaltens entscheidendDenken in Objekten (Instanzen) statt Klassen (Typen)!
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-35 R O O T S
Übersicht aller Bestandteile eines Patterns
Name des PatternsProblem, das vom Pattern gelöst wirdgKontext, in dem das Pattern angewendet werden kannRandbedingungen/Kräfte (forces), die das Pattern beeinflussenLösung. Beschreibung, wie das gewünschte Ergebnis erzielt wirdBeispiele der Anwendung des PatternsR lti d K t t d A d d P ttResultierender Kontext aus der Anwendung des PatternsErläuterung (rationale), warum das Pattern funktioniertBezug zu anderen PatternsBezug zu anderen PatternsBekannte Verwendungen des Patternsoptional: Zusammenfassung (auch: "pattern thumbnail")g ( )
(Es wurden auch andere Schemata für die Beschreibung von Pattern definiert Dieses hier ist recht ausführlich )
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-36 R O O T S
von Pattern definiert. Dieses hier ist recht ausführlich.)
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Wichtige Design Patterns
StrukturVerhalten
"Gang of Four"-Patterns: Überblick und KlassifikationStrukturVerhalten
VisitorObserver
CompositeFlyweight
CommandTemplate MethodCh i f R ibilit
y g
Bisher Chain of Responsibility
StateDecoratorProxy
Bisher
JetztStrategyMultiple Vererbung
yAdapterBridgeF d
Jetzt
Facade
Split Objects
FactoryFactory Method
PrototypeSingleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-38 R O O T S
Objekt-Erzeugung
Factory MethodBuilder
Singleton
Erläuterung zur Klassifikation
Verhaltens-PatternsVerhalten leicht erweiterbar, komponierbar, dynamisch änderbar oder explizit manipulierbar machen
Struktur-PatternsObjekte mit fehlendem Zustand rekursive StrukturenObjekte mit fehlendem Zustand, rekursive StrukturenVerschiedenste Formen der Entkopplung (Schnittstelle / Implementierung, Identität / physikalische Speicherung, ...)
Split Object PatternsZiel: Dynamisch änderbares Verhalten, gemeinsame Verwendung oder Entkopplung von Teilobjektenpp g jWeg: Aufteilung eines konzeptionellen Gesamtobjektes in modellierte Teilobjekte die kooperieren um das Verhalten des konzeptionellen Gesamtobjektes zu realisierenGesamtobjektes zu realisieren
Erzeugungs-PatternsFlexibilität indem die Festlegung von konkret zu erzeugenden Objekte ( XYZ()) it i ö li h ö t i d d tl L f it
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-39 R O O T S
(new XYZ()) so weit wie möglich verzögert wird und evtl. sogar zur Laufzeit immer noch verändert werden kann.
Selbsttest
Ordnen Sie beim Nacharbeiten die auf der vorherigen Folie genannten Ziele den Ihnen dann
bekannten Patterns zu!bekannten Patterns zu!
Diskutieren Sie ihre Einschätzung mit Ihren Kollegen!
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-40 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Facade Pattern
Facade Pattern
AbsichtMenge von Interfaces eines Subsystems zusammenfassenAbhängigkeiten der Clients von der Struktur des Subsystems reduzieren
client classes client classes
subsystem Facade
subsystem yclasses
yclasses
Motivation / BeispielCompiler mit Subsystemen
Scanner
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-42 R O O T S
...CodeGenerator
Facade Pattern: Beispiel
compilersubsystem
Compiler
compile()
Stream
subsystemclasses
Scanner Token
compile()
Parser Symbol
BytecodeStream ProgramNodeBuilder ProgramNode
CodeGenerator ExpressionNodeStatementNode VariableNode
StackMachineCodeGen. RISCCodeGenerator
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-43 R O O T S
Facade Pattern: Anwendbarkeit
einfaches Interface zu einem komplexen Subsystemeinfache Dinge einfach realisierbar (aus Client-Sicht)anspruchsvolle Clients dürfen auch "hinter die Facade schauen"
zB für seltene, komplexe Anpassungen des Standardverhaltens
viele Abhängigkeiten zwischen Klassenreduzieren durch Facade-Objekte
hierarchische Strukturierung eines Systemi F d l Ei ti kt i j d Ebeine Facade als Einstiegspunkt in jede Ebene
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-44 R O O T S
Facade Pattern
Implementierung: Konfigurierbarkeit einer Facadeeigene Facade-Subklasse pro Konfiguration
oder andere Subsystem-Objekte instantiieren
Abgrenzung: SingletonFacaden sind meist Singletons (man braucht nur eine einzige)g ( g )
Abgrenzung: Abstract Factoryzur Erzeugung konsistenter Sätze von Subsystem-Objektenals Alternative zu Facade "Verstecken" plattform-spezifischer Klassen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-45 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Singleton Pattern
Singleton: Motivation
Beschränkung der Anzahl von Exemplaren zu einer Klasse
Meist: nur ein einzelnes ExemplarZ.B. Facade, Repository, System, Factory (vgl. Abstract Factory)
Aber auch: festen Menge von ExemplarenMotivation 1: begrenzte RessourcenMotivation 1: begrenzte Ressourcen.Motivation 2: Teure Objekterzeugung durch „Object Pool“ vermeiden
z.B. 1000 Enterprise Java Beans vorhalten, nach Nutzung zurück in den Poolden Pool
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-47 R O O T S
Singleton: Struktur + ImplementierungBesitzt keinen öffentlichen Konstruktor:
Singleton
private Singleton() {this.Singleton(arg1, ..., argN);
}private Singleton(...) { Liefert eine Instanz (typischerweise immer die
getInstance()instanceOperation()
-instancePooli t D t
...}
Liefert eine Instanz (typischerweise immer die Selbe):
public static Singleton getInstance() {if (instancePool == null)
-instanceDataSpeichert die einzige Instanz oder begrenzte Menge an Instanzen
( )instancePool = new Singleton();
return instancePool;}
Kein öffentlicher Konstruktordadurch wird verhindert, dass Clients beliebig viele Instanzen erzeugen g gkönnenin Java muss explizit ein nicht-öffentlicher Konstruktor mit leerer Argumentliste implementiert werden, damit kein impliziter öffentlicherg p , pKonstruktor vom Compiler erzeugt wird
instancePool als Registry für alle Singleton-Instanzenl k M h i f d li h i lt i I t ähl
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-48 R O O T S
lookup-Mechanismus erforderlich um gezielt eine Instanz auszuwählen
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Adapter Pattern
Adapter Pattern (auch: Wrapper)
AbsichtSchnittstelle existierender Klasse an Bedarf existierender Clients anpassen
Motivation Graphik-Editor bearbeitet Shapes
Li i R ht kLinien, Rechtecke, ...durch "BoundingBox" beschrieben
Textelemente sollen auch möglich seinKlasse TextView vorhandenbietet keine "BoundingBox"-Operation
Integration ohnegÄnderung der gesamten Shape-Hierarchie und ihrer ClientsÄnderung der TextView-Klasse
IdeeIdeeAdapter-Klasse stellt Shape-Interface zur Verfügung... implementiert Shape-Interface anhand der verfügbaren TextView-
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-50 R O O T S
Methoden
Adapter Pattern: Beispiel
*
Existierende Klassen
Shape
BoundingBox()CreateManipulator()
DrawingEditorAdapter-Klasse
CreateManipulator()
Line TextViewtext
TextShape
BoundingBox()CreateManipulator()
BoundingBox()CreateManipulator()
getExtent()...
return text.getExtent()
return new TextManipulator()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-51 R O O T S
return new TextManipulator()
Adapter Pattern (Objekt-Adapter): Schema
Target
request()
Adapteeother()
Clientadaptee
f()q ()f()
Adapter
f()
Adapterrequest()
f()adaptee.other()
Adaptee_N ……
:Adapter:Client :Adaptee_N
request()request()other()
f()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-52 R O O T S
Adapter Pattern (Objekt-Adapter): Konsequenzen
Target
request()
Adapteeother()
Clientadaptee
f()q ()f()
Adapter
f()
Adapterrequest()
f()adaptee.other()
Adaptee_N ……
Adaptiert eine ganze Klassenhierarchie B li bi Ad t S bt kö it b li bi Ad t S btBeliebige Adapter-Subtypen können mit beliebigen Adaptee-Subtypen kombiniert werden ( siehe Objektdiagram auf vorheriger Folie)Kombination wird erst zur Laufzeit, auf Objektebene, festgelegt
Overriding nicht möglichDie f()-Definition aus Adapter wird nicht anstelle der f()-Definition aus Adaptee für den f()-Aufruf aus der Methode other() verwendet
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-53 R O O T S
Adaptee für den f() Aufruf aus der Methode other() verwendet( siehe Objektdiagram auf vorheriger Folie)
Adapter Pattern (Object Adapter): Variante
Target
request()
Adapteeother()
Clientadaptee
f()q ()f()
Adapter
f()
Adapterrequest()
f()
Adaptee_N ……
Ad t N‘ ‘‘f()f() f()
Adaptee_N‘ …‘…‘
Object Adapter mit Overridingzu Adapteee und jede Unterklasse des Adaptees eine weitere Unterklasse
i fü i di d d fi i t V h lt i fü t i d ( l B f())einfügen, in die das redefinierte Verhalten eingefügt wird (also z.B. f())Warum neue Unterklassen? Weil die Adaptee-Hierarchie nicht veränderbar ist!
Problem: Redundanz!
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-54 R O O T S
Was konzeptionell nur ein mal in Adapter stehen sollte wird in jeder neuen Unterklasse von Adaptee redundant eingefügt Wartungsprobleme!
Class Adapter Idiom: Schema„Vererbung ohne Subtyping“:
Erbender erbt Methoden die nicht als Teil seines Interface sichtbar werden.
"private inheritance" in C++"closed inheritance" in Eiffel
Target
()
Adapteeth ()
Client
request() other()f()
f()
<<implementation inheritance>>
Adapterrequest()
f()
Adaptee_N ……
anAdaptedAdaptee:Adapter:Client
f()
p p p:Client
request() other()
f()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-55 R O O T S
f()
Class Adapter Idiom: Konsequenzen
T t Ad tCli t Target
request()
Adapteeother()
f()
Client
f()
AdapterAdaptee N
<<implementation inheritance>>
request()f()
Adaptee_N ……
Overriding des Adaptee Verhaltens leicht möglich
anAdaptedAdaptee:Adapter:Client
Overriding des Adaptee-Verhaltens leicht möglichDa Adapter eine Unterklasse von Adaptee ist, funktioniert das Overridingvon f()
Keine zusätzliche Indirektionnur ein Objekt statt zwei
Adaptiert nur eine Klasse
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-56 R O O T S
Adaptiert nur eine Klassenicht ihre Unterklassen
Adapter Pattern: Konsequenzen
Class Adapteradaptiert nur eine Klasse
Targetrequest()
Adapteef()
m()
Client
AdapterAdapt N
... nicht ihre UnterklassenOverriding des Adaptee-Verhaltens leicht möglichkeine zusätzliche Indirektion (nur ein Objekt)
request()
:Adapter:Client :Adaptee
Adapt_Nf()
m()
keine zusätzliche Indirektion (nur ein Objekt)
Object Adapter
:Adapter:Client :Adaptee
jadaptiert eine ganze KlassenhierarchieOverriding schwieriger
d fi i t V h lt i ifi h U t kl d Ad t i füredefiniertes Verhalten in spezifische Unterklasse des Adaptees einfügenAdapter benutzt diese UnterklasseKombinierbarkeit mit anderen Unterklassen geht verloren
Object Adapter mit Delegation (roots.iai.uni-bonn.de/research/darwin)adaptiert eine ganze Klassenhierarchie
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-57 R O O T S
adaptiert eine ganze KlassenhierarchieOverriding des Adaptee-Verhaltens leicht möglich
Class Adapter Idiom: Schema
TargetClient„Vererbung ohne Subtyping“:
request()"private inheritance" in C++
oder"closed inheritance" in Eiffel
Adaptee
<<implementation inheritance>>
specificRequest()
Adapter
req est()request() specificRequest()
anAdaptedAdaptee:Adapter:Client
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-58 R O O T S
anAdaptedAdaptee:Adapter:Client
Zweiweg-Adapter ("Two-way adapters")
Adapter soll auch das Adaptee-Interface erfüllen Beispiel: QOCA (constraint solving toolkit) und Unidraw (Graphischer editor)Explizite Variablen-Repräsentation in beiden SystemenIntegration erfordert Zwei-Weg-AdapterIntegration erfordert Zwei Weg Adapter
Implementierungmultiple Vererbung
lti l D l ti
(QOCA class hierarchy) (Unidraw class hierarchy)
multiple DelegationEinfach-Vererbung und einfach-Delegation
ConstraintVariable StateVariable
(QOCA class hierarchy) (Unidraw class hierarchy)
ConstraintStateVariable
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-59 R O O T S
ConstraintStateVariable
Adapter Pattern: Konsequenzen (2)
Aufwand des Adapterseinfache Namens-Anpassung
show() --> print()beliebiges anderes Interface
ganz andere Semantikganz andere Semantik
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-60 R O O T S
Adapter Pattern: Anwendbarkeit
Nachträgliche AnpassungSchnittstelle einer existierenden Klasse anpassen
Bisherige Adpater-VariantenVorausschauend Anpassungs-Möglichkeit einbauen
Kl t f d i b k t Cli t b t t dKlasse so entwerfen, dass sie von unbekannten Clients benutzt werden kann, die andere Interfaces erwarten
„Pluggable Adapters“
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-61 R O O T S
Adapter Pattern: Pluggable Adapters
Motivation TreeDisplay soll beliebige Baumstrukturen darstellenBeispiel: Datei-Hierarchie, Vererbungs-Hierarchie
IdeeIdeeSchnittstellen-Anpassbarkeit in TreeDisplay "einbauen"Minimales Interface identifizieren das TreeDisplay von den angezeigten p y g gEntities kennen mussAdaptierbarkeit dieses Interface an verschiedene Hierarchien vorsehen
ImplementierungsvariantenVererbungSimulierte DelegationParametrisierung mit "Blöcken"
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-62 R O O T S
a) Pluggable Adapter mit Vererbung und Abstrakten Operationen
<<Client, Target>>TreeDisplay
getChildren (Node)
Anpassungs-Interface ist Teil des TreeDisplayAbstrakte Methodeng ( )
createGraphicNode(Node)display()buildTree (Node n)
Adapter sind Unterklassen von TreeDisplay
<<Adapter>>DirectoryTreeDisplay
<<Adaptee>>FileSystemEntity
getChildren (Node)createGraphicNode(Node)
getChildren(n) Was, wenn ich getChildren(n)for each child {
addGraphicNode(createGraphicNode(child))
buildTree(child)
,die Art der
Anzeige zur Laufzeit ändern
ill?
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-63 R O O T S
buildTree(child)}
will?
b) Pluggable Adapter mit „Delegate Objects“
<<Client>>TreeDisplay
setDelegate(Delegate)
<<Target>>TreeAccessorDelegate
getChildren (TreeDisplay Node)
delegate
g ( g )display()buildTree (Node n)
getChildren (TreeDisplay, Node)createGraphicNode(TreeDisplay, Node)
<<Adapter>>DirectoryBrowser
<<Adaptee>>FileSystemEntitybackreference
getChildren (TreeDisplay, Node)createGraphicNode(TreeDisplay, Node)createFile()deleteFile()
delegate getChildren(this n)
Eigenes Anpassungs-InterfaceAbstrakte Methodendelegate.getChildren(this,n)
for each child {addGraphicNode(
delegate.createGraphicNode(this,child))buildTree(child)
Abstrakte MethodenAdapter implementieren InterfaceAdapter muessen an TreeDisplay rückfragen können, um dessen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-64 R O O T S
buildTree(child)}
rückfragen können, um dessen Operationen zu nutzen
c) Pluggable Adapter Idiom in Smalltalk und Java
V l M d l
Smalltalk
V l M d l
Pseudo-Java
ValueModel
value:value
ValueModel
setValue()getValue()
adaptee adapteePluggableAdaptor
getBlocksetBlock
Objekt PluggableAdaptor Objekt
getBlocksetBlock GetBlock
value:value
setValue(Oject val)getValue()
getValue(Obj)
SetBlock
^ l k l d
setValue(Obj,Val)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-65 R O O T S
^getBlock value: adaptee return getBlock.getValue(adaptee)
Blöcke in Smalltalk und Java
SmalltalkBlöcke sind Objekte die auf die Nachricht „value“ reagieren
Analog zu einem „Command“-Objekt das auf „run“ reagiertBlöcke können auf den Kontext zugreifen, in dem Sie definiert wurden!
können z B direkt auf Variablen des erzeugenden Kontexts zugreifenkönnen z.B. direkt auf Variablen des erzeugenden Kontexts zugreifen
JavaInstanzen einer „Inner Class“ können auf den Kontext der sie erzeugenden „Outer Class“-Instanz zugreifengetBlock und setBlock als inner classes der anzupassenden KlasseLeider ist damit ist keine unvorhergesehene Adaptierung realisierbar (Änderungen der anzupassenden Klasse wären erforderlich).
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-66 R O O T S
Adapter Pattern: Pluggable Adapter Implementierung
Vererbungmanchmal zu starr
Simulierte Delegationflexibler, da Anpassungsstrategie austauschbar
P t i i it "Blö k "Parametrisierung mit "Blöcken"flexibelste Varianteleider nur Smalltalk-Idiome de u S a ta d o„Innere Klassen“ in Java haben nicht die Ausdruckskraft von Smalltalk-Blöcken
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-67 R O O T S
Adapter Pattern: Abgrenzung
Bridgegleiches Interface
Decoratorgleiches Interface
kontrolliert Zugriff"Implementierungs-Detail"
zusätzliche / veränderte Funktion"konzeptionelle Eigenschaft"konzeptionelle Eigenschaft
Adapterverschiedenes Interfaceähnlich Protection-Adapter
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-68 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Proxy Pattern
Proxy Pattern (auch: Surogate, Smart Reference)
AbsichtStellvertreter für ein anderes Objektbietet Kontrolle über Objekt-Erzeugung und -Zugriff
MotivationMotivation kostspielige Objekt-Erzeugung verzögern (zB: große Bilder)verzögerte Objekterzeugung soll Programmstruktur nicht global veränderng j g g g g
IdeeBild-Stellvertreter (Proxy) verwendenBild-Stellvertreter verhält sich aus Client-Sicht wie BildBild-Stellvertreter erzeugt Bild bei BedarfBild Stellvertreter erzeugt Bild bei Bedarf
aTextDocumentimage
anImageProxyfile
anImage
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-70 R O O T S
Hauptspeicher Platte
Proxy Pattern: Beispiel
DocumentEditor
draw()getExtent()
Graphic *
getExtent()store()load()
ImagefileName
ImageProxyif (image == 0){
image = loadImage(filename);}image.draw() imageData
<<creates>>
extent
draw()getExtent()
image
g ()
if (image == 0){return extent;
gextent
draw()getExtent() g
store()load()
return extent;} else {
return image.getExtent();}
gstore()load()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-71 R O O T S
Proxy Pattern: Schema
ClientSubject *
request()...
...realSubject request();
RealSubject ProxyrealSubject
request()...
request()...
realSubject.request();...
aProxyaRealSubject aClient← request()← request()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-72 R O O T S
q ()← request()
Proxy Pattern: Verantwortlichkeiten
Proxybietet gleiches Interface wie "Subject"referenziert eine "RealSubject"-Instanzkontrolliert alle Aktionen auf dem "RealSubject"
Subjectdefiniert das gemeinsame Interfaceg
RealSubjectdas Objekt das der Proxy vertritteigentliche Funktionalität
Zusammenspielselektives Forwarding
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-73 R O O T S
Proxy Pattern: Anwendbarkeit
Virtueller Proxyverzögerte Erzeugung "teurer" Objekte bei BedarfBeispiel: Bilder in Dokument, persistente Objekte
Remote ProxyyZugriff auf entferntes ObjektObjekt-MigrationB i i l CORBA RMI bil A tBeispiele: CORBA, RMI, mobile Agenten
Concurrency Proxyi di kt R f f R lS bj tnur eine direkte Referenz auf RealSubject
locking des RealSubjects vor Zugriff (threads)
C W itCopy-on-Writekopieren erhöht nur internen "CopyCounter"wirkliche Kopie bei Schreibzugriff und "CopyCounter">0
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-74 R O O T S
wirkliche Kopie bei Schreibzugriff und CopyCounter 0Verzögerung teurer Kopier-Operationen
Proxy Pattern: Anwendbarkeit
Protection Proxy (Zugriffskontrolle)Schmaleres Interface
"Kritische" Operationen ausgeblendetandere via Forwarding implementiert
ganz anderes Interfaceganz anderes InterfaceAutorisierung prüfendirekten Zugriff gewähren oder Forwarding
Beispiel: "CHOICES" Betriebssystem JDKBeispiel: "CHOICES" Betriebssystem, JDK
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-75 R O O T S
Protection-Proxy im JDK (ab 1.2): GuardedObject
ProblemSichere Weitergabe eines schützenwerten Objektes an unbekannten EmpfängerObjektspezifische Zugriffsrechtej p gVerzögerte Überprüfung der Zugriffsrechte
Idee: GuardedObjectIdee: GuardedObjectEnthält "bewachtes Objekt" und "Wächter" (Guard)Guard-Interface enthält nur die Methode checkGuard(Object)
Referenz auf bewachtes Objekt wird nur dann herausgegeben wenn
Guard
Referenz auf bewachtes Objekt wird nur dann herausgegeben, wenn checkGuard(Object)erfolgreich ist (sonst SecurityException)
checkGuard(...)
bewachtesObj kt
Requestor GuardedObjectgetObject()
Objekt
Verbleibendes ProblemMan muß sich darauf verlassen daß der "Requestor" das "bewachte
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-76 R O O T S
Man muß sich darauf verlassen, daß der Requestor das bewachte Objekt" selbst nur in ein GuardedObject verpackt weitergibt!
Proxy Pattern: Implementierung
„Consultation“Allgemein: manuell erstellte Forwarding-MethodenC++: Operator-Overloading
Proxy redefiniert Dereferenzierungs-Operator:*anImageProxy redefiniert Member-Accesss-Operator:anImage->extent()Proxy redefiniert Member Accesss Operator:anImage >extent()
Smalltalk: ReflektionProxy redefiniert Methode "doesNotUnderstand: aMessage"
L i S hk t ktLava: eigenes SprachkonstruktProxy deklariert "consultee"-Variableclass Proxy {
private consultee RealImage realImage;private consultee RealImage realImage;...
}
Falls der Typ von "RealSubject dem Proxy bekannt sein muß:Falls der Typ von RealSubject„ dem Proxy bekannt sein muß: Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ
... dem Proxy nicht bekannt sein muß:
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-77 R O O T S
yNur eine Proxy-Klasse für verschiedene RealSubject-Typen
Beispiel: „Guarded Object“ (vorherige Folie)
Proxy Pattern: Implementierung
Refenrenzierung des RealSubject vor InstantiierungOrts- und Zeit-unabhängige "Ersatz-Referenzen"Beispiele
DateinamenCORBA IOR (Interoperable Object Reference)CORBA IOR (Interoperable Object Reference)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-78 R O O T S
Proxy Pattern: Abgrenzung
Proxygleiches Interface
Decoratorgleiches Interface
kontrolliert Zugriff"Implementierungs-Detail"
zusätzliche / veränderte Funktion"konzeptionelle Eigenschaft"konzeptionelle Eigenschaft
Adapterverschiedenes Interfaceähnlich Protection-Proxy
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-79 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Bridge Pattern
Bridge Pattern (auch: Handle / Body)
AbsichtSchnittstelle und Implementierung trennen... unabhängig variieren
Motivation portable "Window"-Abstraktion in GUI-Toolkitmehrere Variations-Dimensionen
Fenster-Arten:Fenster-Arten: – normal / als Icon, – schließbar / nicht schließbar, – ...
Implementierungen: – X-Windows, – IBM Presentation ManagerIBM Presentation Manager,– MacOS, – Windows XYZ, – ...
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-81 R O O T S
...
Bridge Pattern: Warum nicht einfach Vererbung einsetzen?
Window Window
Neue Fenster-Art:"iconifizierbare" Fenster
XWindow PMWindow IconWindowPMWindowXWindow
XIconWindow PMIconWindow
Probleme dieses LösungsversuchsEi Kl fü j d K bi ti F t A t / Pl ttfEigene Klasse für jede Kombination Fenster-Art / Plattform
unwartbarClient wählt Kombination Fenster-Art / Plattform (bei der Objekterzeugung)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-82 R O O T S
plattformabhängiger Client-Code
Bridge Pattern: Idee
Trennung vonKonzeptueller Hierarchie
bridge
Implementierungs-Hierarchie
drawText()drawRect()
WindowdevDrawText()devDrawLine()
WindowImp
bridgeimp
drawRect() devDrawLine()
imp devDrawLine()imp.devDrawLine()imp.devDrawLine()imp.devDrawLine()imp.devDrawLine()
d B d ()
IconWindow
devDrawLine()
PMWindowImp
devDrawText()
XWindowImp
d Cl B ()
TransientWindow
drawBorder() devDrawLine()devDrawText()
devDrawText()devDrawLine()
drawCloseBox()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-83 R O O T S
drawRect()drawText()
drawRect() XDrawLine() XDrawString()
Bridge Pattern: Schema
Client
ImplementorAbstraction imp
basicOperation()operation()
imp.basicOperation()
RefinedAbstraction ConcreteImplementorA ConcreteImplementorB
basicOperation() basicOperation()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-84 R O O T S
Bridge Pattern: Verantwortlichkeiten
Abstractiondefiniert Interfacereferenziert Implementierung
RefinedAbstractionRefinedAbstractionerweitert das Interface
ImplementorInterface der Implementierungs-Hierarchiekann von Abstraction abweichenkann von Abstraction abweichen
ConcreteImplementorwirkliche Implementierung
Zusammenspiel
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-85 R O O T S
ZusammenspielForwarding
Bridge Pattern: Anwendbarkeit
D i h Ä d b k itDynamische ÄnderbarkeitImplementierung erst zur Laufzeit auswählen
Unabhängige Variabilitätneue Unterklassen in beiden Hierarchien beliebig kombinierbar
Implementierungs-Transparenz für ClientsÄnderungen der Implementierung erfordern keine Änderung / g p g gNeuübersetzung der Clients
Vermeidung von "Nested Generalisations"Vermeidung von Nested Generalisationskeine Hierarchien der Art wie in der Motivations-Folie gezeigtkeine kombinatorische Explosion der Klassenanzahl
Sharingmehrere Clients nutzen gleiche Implementierung
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-86 R O O T S
mehrere Clients nutzen gleiche Implementierungz.B. Strings
Bridge Pattern: Implementierung
Instantiierung des richtigen ConcreteImplementor
Falls Abstraction alle ConcreteImplementor-Klassen kennt:Fallunterscheidung im KonstruktorAuswahl des ConcreteImplementor anhand von Parametern desAuswahl des ConcreteImplementor anhand von Parametern des Konstruktors
Beispiel: Collectioni El t I l ti l k tt t Li twenig Elemente: Implementierung als verkettete Liste
viele Elemente: Implementierung als HashtableAlternativ: Default-Initialisierung und spätere situationsbedingte Änderung
Falls Abstraction völlig unabhängig von ConcreteImplementor-Klassen sein soll:sein soll:
Entscheidung anderem Objekt überlassenAbstract Factory Pattern
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-87 R O O T S
Bridge Pattern: Abgrenzung
Bridgeantizipierte Entkopplung von
Adapternachträgliche Anpassung der
Schnittstelle und Implementierung
Schnittstelle einer Implementierung
Abstract Factorynutzbar zur Erzeugung und Konfiguration einer BridgeKonfiguration einer Bridge
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-88 R O O T S
Patterns für Subsysteme ( siehe „Systementwurf“)
FacadeSubsystem abschirmen
SingletonNur eine einzige Facade-Instanz erzeugen
PProxyStellvertreter für entferntes Subsystem
AdapterAdapterAnpassung der realen an die erwartete Schnittstelle
Bridge Entkopplung der Schnittstelle von der Implementierung
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-89 R O O T S
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Teil 2Teil 2- Object Design Patterns -
Command, Factory Method, Abstract Factory, Composite, Visitor„Patterns Create Architectures“
Rückblick: „Was nutzen Patterns?“
© 2000-2007 Dr. Günter Kniesel
Das Command Pattern: Motivation
KontextGUI-Toolkits mit Buttons, Menüs, etc.
ForcesVielfalt trotz EinheitlichkeitVielfalt trotz Einheitlichkeit
Einheitlicher Code in allen GUI-Elementen .. trotzdem verschiedene Effekte
Wi d dWiederverwendungÜber verschiedene GUI-Elemente ansprechbare Operationen nur ein mal programmieren
Dynamikdynamische Änderung der Aktionen von Menu-Einträgenkontext-sensitive Aktionen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-91 R O O T S
Das Command Pattern: Idee
O i l Obj k i M h d d llOperationen als Objekte mit Methode execute() darstellenin den GUI-Elementen speichern
Einheitlicher Aufruf
VerschiedeneImplementierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-92 R O O T S
Das Command Pattern: Anwendbarkeit
Operationen als Parameter Variable Aktionen
referenziertes Command-Objekt austauschenZeitliche Trennung
Befehl zur Ausführung, Protokollierung, Ausführungg, g, gSpeicherung und Protokollierung von Operationen
History-ListeSerialisierungSerialisierung
"Undo" von OperationenCommand-Objekte enthalten neben execute() auch unexecute()werden in einer History-Liste gespeichert
Recover-Funktion nach SystemabstürzenHistory-Liste wird gespeicherty g pZustand eines Systems ab letzter Speicherung wiederstellbar
Unterstützung von TransaktionenTransaktionen können sowohl einfache ("primitive") als auch komplexe Command
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-93 R O O T S
Transaktionen können sowohl einfache ( primitive ), als auch komplexe Command-Objekte sein.
Implementierung des Command Patterns
Unterschiedliche Grade von IntelligenzCommand-Objekte können "nur" Verbindung zwischen Sender und Empfänger sein, oder aber alles selbstständig erledigenoder aber alles selbstständig erledigen.
Unterstützung von "undo"Semantik
Undo (unexecute()) und redo (execute()) müssen den exakt gegenteiligen Effekt haben!Problem: In den wenigsten Fällen gibt es exact inverse Operationen
Die Mathematik ist da eine Ausnahme...Daher Zusatzinfos erforderlich
Damit ein Command-Objekt "undo" unterstützen kann, müssen evtl. zusätzliche Informationen gespeichert werden.Typischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werdenTypischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werden sollen.
History-ListeFür mehrere Levels von undo/redoFür mehrere Levels von undo/redo
Clonen vor Speicherung in der History-ListeEs reicht nicht eine Referenz auf die Objekte zu setzen! Man muss das Objekt "tief" Clonen, um sicherzustellen dass sein Zustand nicht verändert
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-94 R O O T S
j ,wird.
Das Command Pattern: Konsequenzen
Entkopplung von Aufruf einer Operation und Spezifikation einer Operation.
Kommandos als ObjekteCommand-Objekte können wie andere Objekte auch manipuliert und erweitert werdenerweitert werden.
KompositionFolgen von Command-Objekte können zu weiteren Command-Objekten zusammengefasst werden.
ErweiterbarkeitNeue Command Objekte können leicht hinzugefügt werden da keineNeue Command-Objekte können leicht hinzugefügt werden, da keine Klassen geändert werden müssen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-95 R O O T S
Aufgabe
die sich mit
ObserverStrategyCommand
lö lä tlösen lässt.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-96 R O O T S
StrukturVerhalten
Patterns-ÜberblickStrukturVerhalten
VisitorObserver
CompositeFlyweight
CommandTemplate MethodCh i f R ibilit
y g
Chain of Responsibility
StateDecoratorAdapter
StrategyMultiple Vererbung
pProxyBridgeF dFacade
Split Objects
FactoryFactory Method
PrototypeSingleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-97 R O O T S
Objekt-Erzeugung
Factory MethodBuilder
Singleton
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Das Command und Observer PatternDas Command und Observer Patternin Java
© 2000-2007 Dr. Günter Kniesel
Verbindung von Observer und Command in Java (1)
<<interface>>ActionListener
void actionPerfomed(ActionEvent evt)
MyPasteCommand
<<implements>>
:MenuItemvoid actionPerfomed(ActionEvent evt)
:Button
: MyPasteCommand
:JComponent( S )
← addActionListener(ActionListener)
→ actionPerformed(ActionEvent)
ObserverButtons, Menue-Einträge und Tasten
← registerKeyboardAction(ActionListener, KeyStroke, ...)
Command & Observergleiche Methode (z.B. actionPerformed)Buttons, Menue Einträge und Tasten
generieren "ActionEvents"Interface "ActionListener" ist vordefiniert"ActionListener" implementieren
gleiche Methode (z.B. actionPerformed) spielt die Rolle der run() Methode eines Commands und die Rolle der update() Methode eines Observersimplementierende Klasse (z.B. MyPasteCommand) ist gleichzeitig ein
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-99 R O O T S
... und Instanzen davon bei Buttons, MenuItems, etc registrieren
MyPasteCommand) ist gleichzeitig ein Command und ein Observer
Verbindung von Observer und Command in Java (2)Zusätzliche Unterstützung für "Command"Zusätzliche Unterstützung für Command
Interface "Action" und Klasse "AbstractAction" <<interface>>
ActionListener
Akti i /
ActionListener
void actionPerfomed(ActionEvent evt)
<<extends>>
<<interface>>Action
void putValue(String key, Object value)Object getValue(String key) Einheitliche Schnittstelle zur
Aktivierung / Deaktivierung
von MenuItems denen diese nt
halte
n
Object getValue(String key)
boolean isEnabled()void setEnabled(boolean b)void addPropertyChangeListener(PropertyChangeListener listener)
Einheitliche Schnittstelle zur Speicherung von Parametern
für "Action" ...
denen diese "Action"
zugeordnet ist
m J
DK
en
void addPropertyChangeListener(PropertyChangeListener listener)void removePropertyChangeListener(PropertyChangeListener listener)
<<implements>>... Parameter
können allerdings
im
AbstractAction// alles ausser void actionPerfomed(ActionEvent evt)
allerdings auch direkt als
Instanz-Variablen realisiert
<<extends>>
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-100 R O O T S
MyPasteCommandvoid actionPerfomed(ActionEvent evt)
realisiert werden.
Beispiel: Änderung der Hintergrundfarbe (1)
class ColorAction extends AbstractAction{ public ColorAction(..., Color c, Component comp)
{ ...color = c;color = c;target = comp;
}
public void actionPerformed(ActionEvent evt){ target.setBackground(color);
target.repaint();}}
private Component target;private Color color;
class ActionButton extends JButton{ public ActionButton(Action a)
{} { ...addActionListener(a);
}}
ColorActionÄndern der Hintergrundfarbe einer GUI-Komponente
ActionButton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-101 R O O T S
ActionButtonButtons die sofort bei Erzeugung mit einer Action verknüpft werden
Beispiel: Änderung der Hintergrundfarbe (2)
Nutzung der ColorActionErzeugung einer Instanz
class SeparateGUIFrame extends JFrame{ public SeparateGUIFrame(){
Registrierung
{ ...JPanel panel = new JPanel();
Action blueAction = new ColorAction("Blue", ...,..., panel);( , , , p );
panel.registerKeyboardAction(blueAction,...);
l dd( A ti B tt (bl A ti ))panel.add(new ActionButton(blueAction));
JMenu menu = new JMenu("Color");menu.add(blueAction);( );...
}}
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-102 R O O T S
Beispiel: Änderung der Hintergrundfarbe (2)
Nutzung der ColorActionErzeugung einer Instanz
class SeparateGUIFrame extends JFrame{ public SeparateGUIFrame(){
Registrierung
{ ...JPanel panel = new JPanel();
Action blueAction = new ColorAction("Blue", ...,..., panel);( , , , p );
panel.registerKeyboardAction(blueAction,...);
l dd( A ti B tt (bl A ti ))panel.add(new ActionButton(blueAction));
JMenu menu = new JMenu("Color");menu.add(blueAction);( );...
}} Der komplette Code des Beispiels steht auf der Website.
Beispiel und Erläuterung siehe: "Core Java 2" Kapitel 8
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-103 R O O T S
Beispiel und Erläuterung siehe: Core Java 2 , Kapitel 8, Abschnitt "Separating GUI and Application Code".
Fazit
Elegante Verbindung von Observer und CommandCommands sind ActionListener von Buttons, Menus, etc.
Einheitlicher Aufru via actionPerformed(ActionEvent evt)Buttons und Menus sind PropertyChangeListener von Commands
Aktivierung / DeaktivierungAktivierung / Deaktivierung
Wiederverwendunggleiche Action für Menu, Button, Key
DynamikDynamikWie ändert man die aktuelle Aktion?... konsistent für alle betroffenen MenuItems, Buttons, etc.???
Strategy Pattern!
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-104 R O O T S
StrukturVerhalten
"Gang of Four"-Patterns: Überblick und KlassifikationStrukturVerhalten
VisitorObserver
CompositeFlyweight
CommandTemplate MethodCh i f R ibilit
y g
Chain of Responsibility
StateDecoratorProxy
StrategyMultiple Vererbung
yAdapterBridgeF dFacade
Split ObjectsJetzt
FactoryFactory Method
PrototypeSingleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-105 R O O T S
Objekt-Erzeugung
Factory MethodBuilder
Singleton
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Factory Method Pattern
Factory Method
ZielEntscheidung über konkreter Klasse neuer Objekte verzögern
MotivationF k it d fi i t Kl "D t" d "A li ti "Framework mit vordefinierten Klassen "Document" und "Application"Template-Methode, für das Öffnen eines Dokuments:
1. Check ob Dokument-Art bekannt2. Erzeugung einer Document-Instanz !?!
Erzeugung von Instanzen noch nicht bekannter Klassen!
Ideeaktuelle Klasse entscheidet wann Objekte erzeugt werden
Aufruf einer abstrakten MethodeSubklasse entscheidet was für Objekte erzeugt werden
implementiert abstrakte Methode passend
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-107 R O O T S
implementiert abstrakte Methode passend
Factory Method: Beispiel
Framework
D t A li ti*Document ApplicationnewDocument()
doCreateDocument()
Document doc = doCreateDocument();
docs.add(doc);doc.open();
docs
MyDocument MyApplicationdoCreateDocument() return new MyDocument()
Applikation
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-108 R O O T S
Applikation
Factory Method: Schema
ProductanOperation()
Creator ...product = factoryMethod();anOperation()
factoryMethod()product factoryMethod();...
ConcreteProductfactoryMethod()
ConcreteCreatorreturn new ConcreteProduct()
Factory Method kann abstrakt seinkann abstrakt seinkann Default-Implementierung haben
Creator (Aufrufer der Factory Method)kann Klasse sein, die die Factory Method definiertkann Client Klasse sein
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-109 R O O T S
kann Client-Klasse seinBeispiel: parallele Vererbungs-Hierarchien
Factory Method: Anwendbarkeit
Klasse neuer Objekte unbekannt
Verzögerte Entscheidung über Instantiierungerst in Subklasseerst beim Clienterst beim Client
Mehrere HilfsklassenWissen über konkrete Hilfsklassen an einer Stelle lokalisierenBeispiel: Parallele Hierarchien (nächste Folie)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-110 R O O T S
Factory Method: Anwendbarkeit
Figure ManipulatorClientcreateManipulator()...
downClick()drag()upClick()
T tFiLi Fi Li M i l t T t i l tcreateManipulator()...
TextFigurecreateManipulator()...
LineFiguredownClick()drag()upClick()
LineManipulatordownClick()drag()upClick()
Textmanipulator
upClick() upClick()
Verbindung paralleler KlassenhierarchienFactory Method lokalisiert das Wissen über zusammengehörige KlassenR li h C d d Fi Hi hi d Cli C d i ölli
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-111 R O O T S
Restlicher Code der Figure-Hierarchie und Client-Code ist völlig unabhängig von spezifischen Manipulators (nur vom Manipulator-Interface)
Factory Method: Implementierung
Fester "Produkt-Typ"jede Unterklasse erzeugt festgelegte Produkt Art
class Creator {Product create(){ MyProduct(); }
}festgelegte Produkt-Art
class Creator {
}
Codierter "Produkt-Typ"Parameter oder Objekt-Variable {
Product create(int id) {if (id==1) return MyProduct1();if (id==2) return MyProduct2();...
Parameter oder Objekt-Variable kodiert "Produkt-Typ"Fallunterscheidung anhand Code
}}
mehrere Produktemehr Flexibilität Idiom reflektiver Sprachen
• Smalltalk• Java
class Creator {Object create(Class prodType) {return prodType.getInstance();
Klassen-Objekt als "Produkt-Typ"Parameter oder Objekt-Variable ist "Produkt-Typ"di k I ii
• Java
}}
direkte Instantiierungmehr Flexibilitätbessere Wartbarkeit
Reflektiver Aufruf des parameterelosen Default-Konstruktors
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-112 R O O T S
kein statischer Typ-Check
Factory Method: Konsequenzen
Code wird abstrakter / wiederverwendbarerkeine festen Abhängigkeiten von spezifischen Klassen
Verbindung paralleler KlassenhierarchienF t M th d l k li i t d Wi üb Z hö i k itFactory Method lokalisiert das Wissen über Zusammengehörigkeiten
evtl. künstliche Subklassennur zwecks Objekterzeugung
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-113 R O O T S
Factory Method: Anwendungen
überall in Toolkits, Frameworks, Class LibrariesUnidraw: Beispiel "Figure und Manipulator" MacApp und ET++: Beispiel "Document und Application"
Smalltalk's Model View Controller FrameworkSmalltalk's Model-View-Controller FrameworkFactoryMethoden-Template: defaultControllerHook-Methode: defaultControllerClass
OrbixErzeugung des richtigen Proxy
leichte Ersetzung von Standard-Proxy durch Caching Proxy
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-114 R O O T S
Factory Method: Abgrenzung
Template Methodruft oft Factory Method auf
Abstract Factoryft it F t M th d i l ti toft mit Factory Methods implementiert
gleiche Motivation
Prototypeerfordert keine Unterklassenbildung... dafür aber explizite initialize()-Methode
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-115 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Abstract Factory Pattern
Abstract Factory
Zielzusammengehörige Objekte verwandter Typen erzeugen... ohne deren Klassenzugehörigkeit fest zu codieren
M ti tiMotivationGUI-Toolkit für mehrere PlattformenAnwendungsklassen nicht von plattformspezifischen Widgets abhängig e du gs asse c t o p att o spe sc e dgets ab ä g gmachenTrotzdem soll die Anwendung
alle Widgets konsistent zu einem "look and feel" erzeugen könnenalle Widgets konsistent zu einem look and feel erzeugen können"look and feel" umschalten können
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-117 R O O T S
Abstract Factory: Motivation
createWindow()createScrollBar()
WidgetFactory Client
Window
createWindow()createScrollBar()
MotifWidgetFactorycreateWindow()createScrollBar()
PMWidgetFactory PMWindow MotifWindow
Scrollbar
PMScrollbar MotifScrollBar
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-118 R O O T S
Abstract Factory: Schema
createProductA()createProductB()
AbstractFactory Client
AbstractProductA
createProductA()createProductB()
ConreteFactory1createProductA()createProductB()
ConreteFactory2 ProductA2 ProductA1
AbstractProductB
ProductB2 ProductB1
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-119 R O O T S
Abstract Factory: Implementierung
ConcreteFactories sind SingletonsProdukt-Erzeugung via Factory-Methodsf t P d kt T ( i M th d fü j d P d kt)fester Produkt-Typ (eine Methode für jedes Produkt)
Nachteilneues Produkt erfordert Änderung der gesamten Factory-Hierarchie
Codierter "Produkt-Typ" (eine parametrisierte Methode für alle Produkte)
Vorteilleichte Erweiterbarkeit um neues Produkt
Nachteile:alle Produkte müssen gemeinsamen Obertyp habenalle Produkte müssen gemeinsamen Obertyp habenClients können nur die Operationen des gemeinsamen Obertyps nutzenVerzicht auf statische Typsicherheit
Klassen-Objekt als "Produkt-Typ" (eine parametrisierte Methode)Klassen Objekt als Produkt Typ (eine parametrisierte Methode)Vorteil
neues Produkt erfordert keinerlei Änderungen der FactoryNachteil
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-120 R O O T S
NachteilVerzicht auf jegliche statische Typinformation / Typsicherheit
Abstract Factory: Implementierung
Produktfamilie = SubklasseVorteil
Konsistenz der ProdukteNachteil
neue Produktfamilie erfordert neue Subklasse auch bei geringenneue Produktfamilie erfordert neue Subklasse, auch bei geringen Unterschieden
Produktfamilie = von Clients konfigurierte assoziative DatenstrukturProduktfamilie = von Clients konfigurierte assoziative DatenstrukturVarianten
Prototypen und CloningKlassen und Instantiierung
Vorteilkeine Subklassenbildung erforderlichg
NachteilVerantwortlichkeit an Clients abgegebenkonsistente Produktfamilien können nicht mehr garantiert werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-121 R O O T S
konsistente Produktfamilien können nicht mehr garantiert werden
Abstract Factory: KonsequenzenAbschirmung von Implementierungs-KlassenAbschirmung von Implementierungs-Klassen
Namen von Implementierungsklassen erscheinen nicht im Code von ClientsClients benutzen nur abstraktes InterfaceClients benutzen nur abstraktes Interface
leichte Austauschbarkeit von ProduktfamilienN i C t F t h i t i l i C dName einer ConcreteFactory erscheint nur ein mal im Code
bei ihrer Instantiierungleicht austauschbar gegen andere ConcreteFactoryBeispiel: Dynamisches Ändern des look-and-feel
andere ConcreteFactory instantiierenalle GUI-Objekte neu erzeugen
konsistente Benutzung von Produktfamilienkeine Motif-Scrollbar in Macintosh-Fenster
schwierige Erweiterung um neue ProduktartenSchnittstelle der AbstractFactory legt Produktarten fest
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-122 R O O T S
Schnittstelle der AbstractFactory legt Produktarten festNeue Produktart = Änderung der gesamten Factory-Hierarchie
Abstract Factory: Anwendbarkeit
System soll unabhängig sein vonObjekt-ErzeugungObjekt-KompositionObjekt-Darstellung
System soll konfigurierbar seinAuswahl aus verschiedenen Produkt-Familien
konsistente Produktfamiliennur Objekte der gleichen Familie "passen zusammen"
Library mit Produktfamilie anbietenLibrary mit Produktfamilie anbietenClients sollen nur Schnittstelle kennen... nicht die genauen Teilprodukt-Arten / -Implementierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-123 R O O T S
StrukturVerhalten
"Gang of Four"-Patterns: Überblick und KlassifikationJetzt StrukturVerhalten
VisitorObserver
CompositeFlyweight
Jetzt
CommandTemplate MethodCh i f R ibilit
y g
Chain of Responsibility
StateDecoratorProxy
StrategyMultiple Vererbung
yAdapterBridgeF dFacade
Split Objects
FactoryFactory Method
PrototypeSingleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-124 R O O T S
Objekt-Erzeugung
Factory MethodBuilder
Singleton
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Composite Pattern
Composite Pattern
Zielrekursive Aggregations-Strukturen darstellen ("ist Teil von")Aggregat und Teile einheitlich behandeln
M ti tiMotivationGruppierung von Graphiken
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-126 R O O T S
Composite Pattern: Beispiel
Graphicdraw() childrendraw()
add(Graphic)remove(Graphic)
getChildren()
PictureText draw() {for all c in childrenc.operation()
draw()add(Graphic)
draw()
Linedraw()
}remove(Graphic)getChildren()
aText
aLine
aPicture aPicture
aText
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-127 R O O T S
aText aPicture aPicture
Composite Pattern: Struktur
Componentoperation() children
Client*
operation()add(Component)
remove(Component)getChildren()
CompositeLeaf operation() {for all c in childrenc.operation()
operation()add(Component)
operation()
}remove(Component)getChildren()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-128 R O O T S
Composite Pattern: Verantwortlichkeiten*
Component (Graphic)gemeinsames Interface aller Teilobjekte
Componentoperation()
add(Component)(C t)
children
*
default-VerhaltenInterface für Zugriff auf Teilobjekte (!)evtl Interface für Zugriff auf Elternobjekte
remove(Component)getChildren()
evtl. Interface für Zugriff auf Elternobjekte
Leaf (Rectangle, Line, Text) CompositeLeaf( g )"primitive" Teil-Objekteimplementieren gemeinsames Interfacel I l ti fü T il iff I t f
operation()add(Component)
remove(Component)getChildren()
operation()
leere Implementierungen für Teilzugriffs-Interface
Composite (Picture)p ( )speichert Teilobjekteimplementiert gemeinsames Interface durch forwarding
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-129 R O O T S
implementiert Teilzugriffs-Interface
Composite Pattern: Anwendbarkeit*
Componentoperation()
add(Component)(C t)
children
*
remove(Component)getChildren()
CompositeLeafoperation()
add(Component)remove(Component)
getChildren()
operation()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-130 R O O T S
Composite Pattern: Implementierung*
Composites sollen wissen wovon sie Teil sindExplizite Referenzen auf Composite in Component Klasse
Component
operation()add(Component)
remove(Component)getChildren()
children
Component KlasseMehrere Composites sollen Components gemeinsam nutzen
CompositeLeaf
operation()add(Component)
(C )
operation()
parent1
schließt explizite Referenz der Components auf Composite aus odererfordert, dass Components wissen, dass sie Teile mehrerer Composites i d
remove(Component)getChildren()
sindComponent Interface
"Sauberes Design": Verwaltungs-Operationen (add, remove, getChildren) g g p ( g )in Composite, da sie für Leafs nicht anwendbar sind.Wunsch nach einheitlicher Behandlung aller Graphic-Objekte durch Clients
Verwaltungs-Operationen in Component mit default-Implementierung di i ht t tdie nichts tut
Leaf-Klassen sind damit zufrieden, Composites müssen die Operationen passend implementieren.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-131 R O O T S
Composite Pattern: Konsequenzen
einheitliche BehandlungTeileGanzes
einfache Clientsd i bi di t tt F ll t h iddynamic binding statt Fallunterscheidungen
leichte Erweiterbarkeitneue Leaf-Klasseneue ea asseneue Composite-Klassenohne Client-Änderung
evtl. zu allgemeinEinschränkung der Komponenten-Typen schwerrun-time type checks (instanceof)run time type checks (instanceof)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-132 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Das Visitor Pattern
Das Visitor Pattern
AbsichtRepräsentation von Operationen auf Elementen einer Objektstruktur Neue Operationen definieren, ohne dass die Klassen dieser Objekte zu ändern
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-134 R O O T S
Das Visitor Pattern: Motivation
Beispiel: Compiler enthält Klassenhierarchie für Ausdrücke einer Programmiersprache
ProblemCode einer Operation ist über mehrere Klassen verteiltN O ti f d t Ä d d t Hi hi
Node
Neue Operation erfordert Änderung der gesamten Hierarchie
TypeCheck()GenerateCode()PrettyPrint()
AssignmentNodeVariableRefNode
TypeCheck()GenerateCode()PrettyPrint()
g
TypeCheck()GenerateCode()PrettyPrint()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-135 R O O T S
Das Visitor Pattern: Idee (1)
Operation = ObjektZusammenfassung aller Methoden einer Operation in einer Klasse
visit -Methodenvisit...-MethodenAusprägung der Operation auf bestimmtem Objekttyp
visitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)
NodeVisitor
visitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)
TypeCheckingVisitorvisitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)
CodeGeneratingVisitor
visitVariableRef(VariableRefNode) visitVariableRef(VariableRefNode)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-136 R O O T S
Das Visitor Pattern: Idee (2)
"akzeptierende" Methoden in der betroffenen Klassenhierarchierufen die jeweils passende visit...-Methode auf
*
accept(NodeVisitor)
NodeProgram *
accept(NodeVisitor v)
AssignmentNode
accept(NodeVisitor v)
VariableRefNode
accept(NodeVisitor v) accept(NodeVisitor v)
v visitAssignment(this) v visitVariableRef(this)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-137 R O O T S
v.visitAssignment(this) v.visitVariableRef(this)
Das Visitor Pattern: Schema
visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)
VisitorClient
visitConcreteElementA(ConcreteElementA)
ConcreteVisitor1visitConcreteElementA(ConcreteElementA)
ConcreteVisitor2visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)
visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)
accept(Visitor)
ElementObjectStructure *
accept(Visitor v)
ConcreteElementA
accept(Visitor v)
ConcreteElementB
accept(Visitor v)operationA()
accept(Visitor v)operationB()
v visitConcreteElementB(this)v visitConcreteElementA(this)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-138 R O O T S
v.visitConcreteElementB(this)v.visitConcreteElementA(this)
Visitor Pattern: Verantwortlichkeiten / Implementation
Objektstruktur-Hierarchieeinheitliche accept-Methode
Visitor-Hierarchie je eine visit-Methode für jede Klasse der Objektstrukturj j j
Accept-Methodenhaben Visitor als Parameterhaben Visitor als Parameter"Welche Operation soll auf mir ausgeführt werden?"
Visit MethodenVisit-Methodenhaben Parameter vom Typ der jeweilige Klasse der Objektstruktur"Wie soll Operation X auf Objekten des Typs Y ausgeführt werden?"
Traversierung der Objektstruktur kann definiert sein in der Objektstruktur (Methode accept(...)) oder
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-139 R O O T S
j ( p ( ))im Visitor-Objekt (Method visit...(...))
Das Visitor Pattern: Zusammenarbeit
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-140 R O O T S
Das Visitor Pattern: Konsequenzen
Funktionale DekompositionEin Visitor fasst Methoden der gleichen Operation zusammen... und trennt Methoden verschiedener Operationen
HeterogenitätObjekt-Klassen können aus verschiedenen Hierarchien stammenj
Hinzufügen neuer Operationen ist einfachneue Visitor-Klasse
Hi fü Obj kt Kl i t h f diHinzufügen neuer Objekt-Klassen ist sehr aufwendigneue Objekt-Klasseneue visit... - Methode in allen Visitors
Sammeln von Zuständenwährend der Abwanderung eines Objektbaumsdafür keine zusätzlichen Parametern nötigdafür keine zusätzlichen Parametern nötig
Verletzung von KapselungKlassen der Objekstruktur müssen den Visitors ausreichend Funktionalität bieten
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-141 R O O T S
bietenOft müssen ihre Schnittstellen mehr preisgeben als sonst nötig
Das Visitor Pattern: Anwendbarkeit
Funktionale DekompositionZusammengehörige Operationen sollen zusammengefasst werden ... statt in einer Klassenhierarchie verteilt zu sein
Stabile Objekt-Hierarchielt Klselten neue Klassen
aber oft neue OperationenHeterogene Hierarchieg
viele Klassen mit unterschiedlichen Schnittstellen Operationen die von den Klassen abhängen
AnwendungsbeispielJava-Compiler des JDK 1 3Java Compiler des JDK 1.3
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-142 R O O T S
Überblick
Einführung Grundidee, Literatur, MVC-Framework als Beispiel
Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandBridge, Factory Method, Abstract Factory
Patterns Create ArchitecturesBridge, Abstract Factory, Singleton
N t P ttNutzen von PatternsZusammenfassung und Ausblick
Bestandteile eines Patterns, DefinitionBestandteile eines Patterns, DefinitionArten von Patterns, AbgrenzungWeiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-143 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
„Patterns Create Architectures“
Ein Beispiel zum Zusammenspiel von PatternsPatterns
Bridge & Abstract Factory & Singleton
„Patterns Create Architectures“
IdeeWenn man Patterns wohlüberlegt zusammen verwendet, entsteht ein Grossteil einer Software-Architektur aus dem Zusammenspiel der Patterns.
BeispielBeispielZusammenspiel von Bridge, Factory und Singleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-145 R O O T S
Erinnerung ans Abstract Factory Pattern
createWindow()createScrollBar()
WidgetFactory Client
Windowin der Praxis müsste WidgetFactory ein
Singleton seinSingleton sein
createWindow()createScrollBar()
MotifWidgetFactorycreateWindow()createScrollBar()
PMWidgetFactory PMWindow MotifWindow
Scrollbar
PMScrollbar MotifScrollBar
in der Praxis müsste hier das Bridge-
Pattern angewendet werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-146 R O O T S
werden
Erinnerung ans Bridge Pattern
Trennung vonKonzeptueller Hierarchie Implementierungs-
HierarchieClient
devDrawText()devDrawLine()
WindowImpdrawText()drawRect()
Window impClient
devDrawLine()drawRect()
devDrawLine()
XWindowImpdevDrawText()
PMWindowImp
()
IconWindow
C ()
TransientWindowdevDrawLine()devDrawText()
devDrawText()devDrawLine()
drawBorder() drawCloseBox()
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-147 R O O T S
Zusammenspiel: Bridge, Factory, Singleton<< konfiguriert >>
Client WidgetFactory<< konfiguriert >>
SingletonWidgetFactory setFactory(WidgetFactory MOTIF)
PMWidgetFactorycreateWindow()MotifWidgetFactory
WidgetFactory.setFactory(WidgetFactory.MOTIF)WidgetFactory.getFactory()
Wi d IWi d imp
createWindow()createScrollBar()<< benutzt >>
WindowImpWindow imp
PMWindow MotifWindowIconWIndow TransientWindow
ScrollbarImpScrollbar imp ScrollbarImpScrollbar imp
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-148 R O O T S
PMScrollbar MotifScrollBarFixedSB ProportionalSB
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Rückblick: Was nützen Patterns?
Nutzen von Design Patterns (1)
Objekte / Klassen identifizierenAbstraktionen, die kein Gegenstück in der realen Welt / dem Analyse-Modell habenBeispiel:
Composite PatternComposite PatternAbstraktionen von ProzessenStrategyState
"Strict modelling of the real world leads to a system that reflects today's realities but not necesarilly tomorrow's. The abstractions that y yemerge during design are key to making a design flexible."
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-150 R O O T S
Nutzen von Design Patterns (2)
Granularität der Objekte festlegenFacade
ein "Riesen-Objekt"Flyweight
viele kleine gemeinsam verwendbare Teilobjekteviele kleine, gemeinsam verwendbare TeilobjekteBuilder
Komposition von Gesamt-Objekt aus TeilobjektenVisitor
Gruppe von konsistenten AktionenCommandCommand
einzelne Aktion
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-151 R O O T S
Nutzen von Design Patterns (3)
Schnittstellen identifizierenwas gehört dazuwas gehört nicht dazu (Bsp. Memento)
Beziehungen zwischen Schnittstellen festlegenBeziehungen zwischen Schnittstellen festlegenSubtyping
DecoratorProxy
Je eine Methode pro Klasse aus einer anderen ObjekthierarchieAbstract FactoryAbstract FactoryBuilderVisitor
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-152 R O O T S
Nutzen von Design Patterns (4)
Wahl der ImplementierungInterface, Abstrakte Klasse oder konkrete Klasse
Grundthema fast aller PatternsAbstrakte Methode oder Hook Methode
von template method aufgerufene Methodenvon template method aufgerufene MethodenOverriding oder fixe Implementierung
Factory methodT l t th dTemplate method
Vererbung oder Subtyp-BeziehungAdapter, Decorator, State, Strategy, Command, Chain of Responsibility: Gemeinsamer Obertyp, nicht gemeinsame Implementierung
Vererbung oder AggregationVererbung ist statischEs wird oft mehr vererbt als gewünschtBeispiel: alle "split object patterns"
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-153 R O O T S
Nutzen von Design Patterns (5):
Patterns erkörpern Gr ndprin ipien g ten DesignsPatterns verkörpern Grundprinzipien guten Designs
Implementierungen austauschbar machenImplementierungen austauschbar machenTypdeklarationen mit Interfaces statt mit KlassenDesign an Interfaces orientieren, nicht an KlassenClient-Code wiederverwendbar für neue Implementierungen des gleichen Interface
Objekt-Erzeugung änderbar gestalten"Creational Patterns" statt "new MyClass()"Cli C d i d db fü I l i d l i hClient-Code wiederverwendbar für neue Implementierungen des gleichen Interface
Funktionalität änderbar gestaltenAggregation und Forwarding statt Vererbung
ät K fi i b k it D ik
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-154 R O O T S
späte Konfigurierbarkeit, Dynamikweniger implizite Abhängigkeiten (kein "fragile base class problem")
Überblick
Einführung Grundidee, Literatur, MVC-Framework als Beispiel
Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandFacade, Singleton, Proxy, Adapter, BridgeFactory Method, Abstract FactoryComposite, Visitor
Patterns Create ArchitecturesPatterns Create ArchitecturesBridge, Abstract Factory, Singleton
Nutzen von PatternsZusammenfassung und Ausblick
Arten von Patterns, AbgrenzungWeiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-155 R O O T S
Arten von Design Patterns
Analysis Patternwiederkehrende Problemen in der Analysephase eines SoftwareprojektsMartin Fowler: "Analysis Patterns", Addison-Wesley, 1997
Architektur Patternb h ibt ö li h f d t l St kt S ft t... beschreibt mögliche fundamentale Strukturen von Softwaresystemen.
... enthält vordefinierte Subsysteme und ihre Verantwortlichkeiten.
... enthält Regeln und Richtlinien für die Organisation ihrer Beziehungen.g g gBeispiel: Das Model-View-Controller Framework
Design PatternSchema für die Realisation von Subsystemen oder Komponenten eines Softwaresystems
Idiom (auch: Coding Pattern)( g )low-level design patterns für eine gegebene Programmiersprache.Beispiel: Wie stelle ich sicher, dass eine Instanz einer Java-Klasse nur innerhalb dieser Klasse erzeugt werden kann?
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-156 R O O T S
innerhalb dieser Klasse erzeugt werden kann?
Weitere Arten von Pattern
Organizational PatternsStruktur und Praxis von Organisationen; also Gruppen, die ein gemeinsames Ziel verfolgen http://www.bell-labs.com/cgiuser/ OrgPatterns/OrgPatterns?OrganizationalPatternsg g g
Anti-Patternsbeschreiben typische Fehlerbeschreiben typische Fehler... und bestenfalls auch wie man sie wieder beseitigt
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-157 R O O T S
Abgrenzung: Pattern sind keine Algorithmen
Patterns versus AlgorithmenAlgorithmen lösen feinkörnigere Probleme als Patterns (z.B. Suchen, Sortieren)Algorithmen sind deterministischer (weniger Implementierungs-Freiheitsgrade)g )Komplexität von Algorithmen lässt sich leichter fassen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-158 R O O T S
Abgrenzung: Pattern sind keine Frameworks
Pattern versus FrameworksFramework
Menge von kooperierenden Klassen für einen spezifischen Anwendungsbereicherweiterbar durch Unterklassenbildung und Komposition von InstanzenHollywood-Prinzip ("Don't call us, we'll call you." --> Template Method Pattern)
Patterns sind abstrakterFrameworks existieren als konkreter wiederverwendbarer Code – PatternsFrameworks existieren als konkreter, wiederverwendbarer Code Patterns enthalten nur Beispiele von Code
Patterns sind weniger spezifischFrameworks werden für konkrete Anwendungsbereiche eingesetzt PatternsFrameworks werden für konkrete Anwendungsbereiche eingesetzt – Patterns können fast überall eingesetzt werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-159 R O O T S
Weiterführende Themen
Pattern Catalogs Sammlungen von lose zusammenhängenden Patterns
Pattern Systems S l t k hä d P tt itSammlungen von stark zusammenhängenden Patterns mit engen Verzahnungen
Pattern Languages verfolgen ein gemeinsames Ziel, dass durch die Zusammenarbeit der enthaltenen Patterns erreicht werden kannenthaltenen Patterns erreicht werden kann inkl. einer Art "Grammatik", die alle mögliche Kombinationen aufzeigt
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-160 R O O T S
Pattern: Zusammenfassung
Betonung von PraktikabilitätPatterns sind bekannte Lösungen für erwiesenermaßen wiederkehrende Probleme Sie sollen Softwareentwickler bei ihrer Arbeit unterstützen, nicht mehr und nicht wenigerg
"Aggressive Hintanstellung von Originalität"Lösungen, die sich noch nicht in der Praxis bewährt haben, sind keine PatternPattern.
Patterns sind kein AllheilmittelOriginalität bei der Anwendung von Patterns ist nach wie vor gefragt.g g g gEs muss immer noch abgewägt werden, welche Patterns, Pattern Languages, etc. eingesetzt werden.
GesamteffektGesamteffektAufgabe des Softwarearchitekten verlagert sich von der Erfindung des Rads zur Auswahl des richtigen Rads und seiner kreativen Verwendung
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-161 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Rückblick, Selbsttest
Im Kapitel „Systementwurf“ kommen die 2 folgenden Folien vor.
Sie sollten nun in der Lage sein für die inzwischen besprochenen Design Patterns die auf den folgenden 2Sie sollten nun in der Lage sein, für die inzwischen besprochenen Design Patterns die auf den folgenden 2 Folien genannten Hinweise nachvollziehen.
Wenn nicht, schauen Sie sich die Pattern-Beschreibungen noch mal genau an!
Nichtfunktionale Anforderungen geben Hinweise zur Nutzung von Design Patterns (Entwurfsmustern)g g ( )
IdeeIdentifikation von Design Patterns anhand von Schlüsselwörtern in der Beschreibung nichtfunktionaler AnforderungenAnalog zu Abbots Objektidentifikation durch Textanalyse
Hinweise auf Abstract Factory Pattern“Herstellerunabhängig”, “Geräteunabhängig”, “muss eine Produktfamilie unterstützen”
Hinweise auf Adapter Pattern“muss mit einem existierenden Objekt zusammenarbeiten”muss mit einem existierenden Objekt zusammenarbeiten
Hinweise auf Bridge Pattern„muss sich um die Schnittstelle zu unterschiedlichen Systemen kümmern von denen einige erst noch entwickelt werden.“„ein erster Prototyp muss vorgeführt werden“
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-163 R O O T S
Nichtfunktionale Anforderungen geben Hinweise zur Nutzung von Design Patterns (Fortsetzung)
Hinweise auf Composite Pattern“komplexe Struktur”, “muss variable Tiefe und Breite haben”
g g ( g)
Hinweise auf Façade Pattern“muss mit einer Menge existierender Objekte zusammenarbeiten”, "stellt
-Dienst bereit"...-Dienst bereitHinweise auf Proxy Pattern
“muss ortstransparent sein”Hinweise auf Observer Pattern
“muss erweiterbar sein”, “muss skalierbar sein” Hi i f St t P ttHinweise auf Strategy Pattern
“muss Funktionalität X in unterschiedlichen Ausprägungen bereitstellen können”
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-164 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s
Ausgeblendete Folien
Verbreitung von Patterns
ProzesseUnified Process
NotationenUML
P i hProgrammiersprachen Patterns als Sprachkonstrukte
LibrariesLibraries Java APIs
automatische Erkennung von Patternsre-engineering
Tools Generierung von Quelltexten (z B Together/J)Generierung von Quelltexten (z.B. Together/J)
Formalisierung von Patterns
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-167 R O O T S
Advanced Topics
Pattern LanguagesDescriptions of systems of patterns with matching initial and resulting contexts, together with a "grammar" that describes how to compose them.
Pattern SequencesConcrete sequences of patterns from a pattern languageConcrete sequences of patterns from a pattern language.Repeated application of pattern sequences lead to new higher-level patterns.This seems to be a fruitful basis for a formalization of patterns.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-168 R O O T S
Das Command Pattern
Bekannte Anwendungenjavax.swing.undo.UndoableEdit
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-169 R O O T S
Das Visitor Pattern: Bekannte Anwendungen
Java-Compiler des JDK 1.3
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-170 R O O T S
Observer Aufgabe
Terminkalender-Einträge werden geändertVisuelle Anzeige aktualisierenMail-Benachrichtigungen verschickenBenachrichtigungsstrategie soll sehr weitgehend konfigurierbar sein
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-171 R O O T S
Änderungen gegenüber Vorlage (Patterns-Vorlesung aus SS2002))
Vieles gelöschtDesign-Vorlage eine Stufe größer (20 statt 18 Punkt auf 1 Ebene)g g g ( )
Folgeänderung: Verschiebung fixer Objekte auf vielen FolienFolgeänderung: Löschung von Leerzeilen auf Folien mit viel Text
Komplett überarbeitete Visitor-Pattern-Folien neu eingefügt (auf Basis von Pascal‘s Satz aus 2001))
Folie zu cloning im Prototype Pattern umfangreich überarbeitet (incl. f di A i ti )aufwendiger Animation)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-172 R O O T S
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Vorlesung Design PatternsSommersemester 2002
Dr. Günter KnieselInstitut für Informatik III
Universität BonnRömerstr. 164, 53117 Bonn
© 2000-2007 Dr. Günter Kniesel
Dieses Material is nur für die Hörer der Vorlesung Design Patterns“ Dieses Material is nur für die Hörer der Vorlesung „Design Patterns (Sommersemester 2002) bestimmt. Es darf ausschliesslich zur Vor-und Nachbereitung der Vorlesung bzw. zur Vorbereitung auf die entsprechende Prüfung verwendet werdenentsprechende Prüfung verwendet werden.
Die Weitergabe an Personen außerhalb des oben erwähnten Personenkreises ist ohne ausdrückliche Genehmigung des Autors Personenkreises ist ohne ausdrückliche Genehmigung des Autors nicht zulässig.
Das komplette Material umfaßt 299 Folien. Die Einleitung und die p gBeschreibung des Observer und Command Patterns (Seite 6 bis 40) basieren auf Folien von Pascal Costanza. Die Folien zum Singleton Pattern (Seite 86 bis 89) sind ein Beitrag von Holger Mügge.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-174 R O O T S