Kapitel 6 Entwurfsmuster (Design Patterns)

Vorlesung Softwaretechnologie 2007/8
Dr. Günter Kniesel
ROOTS
Kapitel 6
Entwurfsmuster (Design Patterns)
Stand: 27.11.2007
© 2000-2007 Dr. Günter Kniesel
Einführung: Die Grundidee von Pattern
z Pattern (Muster) wurden zuerst im Bereich der Architektur beschrieben.
z Grundlegende Idee: Alle Ingenieurdisziplinen benötigen eine
Terminologie ihrer wesentlichen Konzepte sowie eine Sprache, die
diese Konzepte in Beziehung zueinander setzt.
z Ziele von Pattern in der Welt der Software:
‹Dokumentation von Lösungen wiederkehrender Probleme
Probleme, um
Programmierer bei der Softwareentwicklung zu unterstützen.
‹Schaffung einer gemeinsamen Sprache, um über Probleme und ihre
Lö
Lösungen
zu sprechen.
h
‹Bereitstellung eines standardisierten Katalogisierungsschemas um
erfolgreiche Lösungen aufzuzeichnen.
z Bei Pattern handelt es sich weniger um eine Technologie (wie z.B. bei
UML), als um eine Kultur der Dokumentation und Unterstützung guter
UML)
Softwarearchitektur.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-2
ROOTS
Einführung: Literatur zu Pattern und Software
z
Erich Gamma
Gamma, Richard Helm
Helm, Ralph Johnson
Johnson, John Vlissides (Gang of Four):
"Design Patterns - Elements of Reusable Object-Oriented Software"
Addison-Wesley, 1995
z
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
z
Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz:
"Object Oriented Reengineering Patterns", Morgan Kaufman, 2002
z
Patterns im WWW
‹ Patterns Home Page:
g http://www.hillside.net/
p
‹ Portland Pattern Repository: http://c2.com/ppr/index.html
‹ Brad Appleton: "Patterns and Software: Essential Concepts and Terminology„
http://www.bradapp.net/docs/patterns-intro.html
p
pp
p
‹ Doug Lea, Patterns-Discussion FAQ, http://gee.oswego.edu/dl/pd-FAQ/pd-FAQ.html
‹ Buchliste: http://c2.com/cgi/wiki?PatternRelatedBookList
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-3
ROOTS
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
-
X
Model
-
X
a = 50%
b = 30%
c = 20%
View + Controller
Vorlesung Softwaretechnologie, Wintersemester 2007/8
View + Controller
06-4
ROOTS
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
Änderungen am
Modell werden
propagiert
-
-
X
Views melden sich an
Vorlesung Softwaretechnologie, Wintersemester 2007/8
X
a = 50%
b = 30%
c = 20%
06-5
ROOTS
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
-
X
-
X
-
X
a = 50%
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
ROOTS
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
z Propagierung von Änderungen: Observer Pattern
‹ kommt z.B. auch bei Client/Server-Programmierung
zur Benachrichtigung der Clients zum Einsatz
z Geschachtelte Views: Composite Pattern
‹ View enthält weitere Views, wird aber wie ein
einziger View behandelt
behandelt.
‹ kommt z.B. auch bei Parsebäumen im Compilerbau
zum Einsatz (Ausdrücke).
-
-
X
X
z Reaktion auf Events im Controller: Strategy Pattern
‹ Eingabedaten können validiert werden
(Daten, Zahlen, etc.).
‹ Controller können zur Laufzeit gewechselt werden.
‹ kommt z.B. auch bei der Codeerzeugung im Compilerbau
zum Einsatz (Code für verschiedene CPUs).
Vorlesung Softwaretechnologie, Wintersemester 2007/8
-
06-7
X
ROOTS
Überblick
z Einführung
‹ Grundidee, Literatur, MVC-Framework als Beispiel
z Beispiele wichtiger Patterns
‹ Observer, Strategy, Command
‹ Facade, Singleton, Proxy, Adapter, Bridge
‹ Factory Method, Abstract Factory
‹ Composite, Visitor
z Patterns Create Architectures
‹ Bridge, Abstract Factory, Singleton
z Nutzen von Patterns
z Zusammenfassung und Ausblick
‹ Arten von Patterns, Abgrenzung
‹ Weiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-8
ROOTS
Das Observer Pattern: Einführung
z Absicht
‹ Stellt eine 1-zu-n Beziehung zwischen Objekten her
‹ Wenn das eine Objekt seinen Zustand ändert, werden die davon
abhängigen Objekte benachrichtigt und entsprechend aktualisiert
z Andere Namen
‹ "Dependents", "Publish-Subscribe", "Listener"
z Motivation
‹ Verschiedene Objekte sollen zueinander konsistent gehalten werden
‹ Andererseits sollen sie dennoch nicht eng miteinander gekoppelt sein.
(bessere Wiederverwendbarkeit)
‹ Diese Ziele stehen in einem gewissen Konflikt zueinander. Man spricht von
g forces“, also g
gegenläufig
g
g wirkenden Kräften.
„conflicting
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-9
ROOTS
Das Observer Pattern: Beispiel
z Trennung von Daten und Darstellung
‹ Wenn in einer Sicht Änderungen vorgenommen werden, werden alle
anderen Sichten aktualisiert – Sichten sind aber unabhängig voneinander.
a = 50%
b = 30%
c = 20%
-
X
-
X
-
X
a = 50%
b = 30%
c = 20%
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-10
ROOTS
Das Observer Pattern: Anwendbarkeit
Das Pattern ist im folgenden Kontext anwendbar:
z Abhängigkeiten
‹ Ein Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt.
‹ Aufteilung dieser Aspekte in verschiedene Objekte erhöht
Variationsmöglichkeit und Wiederverwendbarkeit.
z Folgeänderungen
‹ Änderungen an einem Objekt erfordert Änderungen an anderen Objekten.
‹ Es
E ist
i t nicht
i ht b
bekannt,
k
t wieviele
i i l Obj
Objekte
kt geändert
ä d t werden
d müssen.
ü
pp g
z Lose Kopplung
‹ Objekte sollen andere Objekte benachrichtigen können, ohne Annahmen
über die Beschaffenheit dieser Objekte machen zu müssen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-11
ROOTS
Das Observer Pattern: Struktur
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-12
ROOTS
Rollenaufteilung / Verantwortlichkeiten
z Observer („Beobachter“ auch: Subscriber, Listener)
‹ update (auch: handleEvent)
Ö Reaktion auf Zustandsänderung des Subjects
z Subject („Subjekt“ auch: Publisher)
‹ attach(auch: register,
register addListener)
Ö Observer registrieren
‹ detach (auch: unregister, removeListener)
Ö registrierte Observer entfernen
‹ notify
Ö update-Methoden
p
aller registrierten
g
Observer aufrufen
‹ setState
Ö zustandsändernde Operation(en)
Ö für beliebige Clients
‹ getState
Ö abfrage
bf
des
d aktuellen
kt ll Z
Zustands
t d
Ö damit Observer feststellen können was sich genau geändert hat
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-13
ROOTS
Das Observer Pattern: Zusammenarbeit der Objekte
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-14
ROOTS
Das Observer Pattern: Konsequenzen
z
Unabhängigkeit
‹ „Subjekte“ und „Beobachter“ können unabhängig voneinander variiert werden.
‹ „Beobachter“ können hinzugefügt werden, ohne „Subjekte“ oder andere
„Beobachter
Beobachter“ zu ändern
ändern.
‹ „Subjekte“ können ohne „Beobachter“ wiederverwendet werden. Umgekehrt
ebenfalls.
z
„Broadcast“-Nachrichten
‹ Subjekt benachrichtigt alle angemeldeten Beobachter
‹ Beobachter
B b ht entscheiden,
t h id
ob
b sie
i N
Nachrichten
h i ht b
behandeln
h d l oder
d iignorieren
i
z
Abstrakte Kopplung
‹ Subjekte aus tieferen Schichten eines Systems können mit Beobachtern aus
höheren Schichten kommunizieren, ohne die Schichten zu verletzen.
z
Unerwartete Aktualisierungen
‹ Kleine Zustandsänderungen des Subjekts können komplexe Folgen haben.
‹ Auch uninteressante Zwischenzustände können unnötige Aktualisierungen
auslösen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-15
ROOTS
Das Observer Patterns: Implementierung
z Speicherung der Beziehung zwischen Subjekt und Beobachter
‹ Instanzvariable im Subjekt oder ...
‹ globale (Hash-)Tabelle
(Hash )Tabelle
z Beobachtung mehrer Subjekte
‹ Die graphische Darstellung einer Tabelle könnte mehrere Subjekte
beobachten. Dann muss die „update()“-Methode einen zusätzlichen
Parameter haben, der das Subjekt angibt.
z Wer ruft "notify()" auf?
‹ a)) "setState()"-Methode
" tSt t ()" M th d d
des S
Subjekts:
bj kt
Ö + 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.
Ö – Klienten vergessen möglicherweise Aufruf von "notify()".
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-16
ROOTS
Implementierung des Observer Patterns
z Konsistenz
‹ Zustand 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) {
super.doSomething(newState);
d S
thi (
St t )
// ruft
ft "
"notify()"
tif ()" auf
f
this.modifyMyState(newState); // zu spät!
}
}
‹ Dokumentation von „„notify()“-Aufrufen
y()
erforderlich
‹ Besser: In Oberklsse „Template-Method Pattern“ anwenden um
sicherzustellen, dass „notify()“-Aufrufe immer am Schluß einer Methode
stattfinden
stattfinden.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-17
ROOTS
Das Observer Patterns: Implementierung
z
Wie werden die Informationen über eine Änderung weitergegeben:
„push“
h“ vs. „pull“
ll“
‹ p
push: Subjekt
j
übergibt
g in „update()“
p
() detaillierte Informationen über Änderungen.
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
ROOTS
Das Observer Patterns: Implementierung
Fortgeschrittene Techniken
z Differenzierung von Ereignissen
‹ Beobachter-Registrierung nur für spezielle Ereignisse
‹ weniger "Rückfragen" / höhere Effizienz
z ChangeManager
‹ verwaltet
lt t Beziehungen
B i h
zwischen
i h S
Subjekt
bj kt und
dB
Beobachter.
b ht
(Speicherung in Subjekt und Beobachter kann entfallen.)
‹ definiert die Aktualisierungsstrategie
‹ benachrichtigt alle Beobachter
‹ verzögerte Benachrichtigung möglich
Ö Insbesondere wenn mehrere Subjekte verändert werden müssen
müssen, bevor die
Aktualisierungen der Beobachter Sinn macht
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-19
ROOTS
Das Observer Patterns: Bekannte Anwendungen
z Bekannte Anwendungen
‹ Model-View-Controller-Framework in Smalltalk
‹ Java Foundation Classes / Swing
‹ Oberon System
‹ Diverse Client/Server
Client/Server-Modelle,
Modelle zz.B.
B Java RMI
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-20
ROOTS
Einführung: Das MVC-Framework in Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
z Propagierung von Änderungen: Observer Pattern
‹ kommt z.B. auch bei Client/Server-Programmierung
zur Benachrichtigung der Clients zum Einsatz
z Geschachtelte Views: Composite Pattern
‹ View enthält weitere Views, wird aber wie ein
einziger View behandelt
behandelt.
‹ kommt z.B. auch bei Parsebäumen im Compilerbau
zum Einsatz (Ausdrücke).
-
-
X
X
z Reaktion auf Events im Controller: Strategy Pattern
‹ Eingabedaten können validiert werden
(Daten, Zahlen, etc.).
‹ Controller können zur Laufzeit gewechselt werden.
‹ kommt z.B. auch bei der Codeerzeugung im Compilerbau
zum Einsatz (Code für verschiedene CPUs).
Vorlesung Softwaretechnologie, Wintersemester 2007/8
-
06-21
X
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Let's play patterns!
Aufgabe
z IntegerBag
‹ Menge von integers
z IntegerAdder
‹ Addiert alles was sich im Bag befindet und gibt Ergebnis aus
z IntegerPrinter
I t
Pi t
‹ Gibt den kompletten Inhalt eines IntegerBag aus
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-23
ROOTS
Mögliche Lösung
z Siehe http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-
0525-observer.html
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-24
ROOTS
Das Strategy Pattern: Einführung
z Absicht
‹ Kapselung einer Familie von Algorithmen mit der Möglichkeit, sie beliebig
auszutauschen.
z Motivation
‹ Berechnung von Zeilenumbrüchen
Ö mehrere Algorithmen können eingesetzt werden
Ö neue Varianten sollen später hinzugefügt werden können
z S
Struktur (f
(für obiges Beispiel))
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-25
ROOTS
Das Strategy Pattern: Anwendbarkeit und Struktur
z Anwendbar in folgendem Kontext
‹ Einige ähnliche Klassen unterscheiden sich nur in gewissen Aspekten des
Verhaltens. Diese können in ein Strategie-Objekt
g
j
ausgelagert
g g werden.
‹ Verhalten ist abhängig von äußeren Randbedingungen
‹ Verschiedene Varianten eines Algorithmus werden benötigt
Ö
z.B.
B mitit unterschiedlicher
t
hi dli h Z
Zeit-/Platzkomplexität.
it /Pl t k
l ität
‹ Kapselung von Daten eines komplexen Algorithmus
z Struktur (allgemein)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-26
ROOTS
Das Strategy Pattern: Implementierung
z Alternative Schnittstellen zwischen Kontext und Strategien
1. Kontext übergibt alle relevanten Daten an die Strategie-Methode
2. Kontext übergibt this an Strategie-Methode Æ flexibelste Lösung
3. Strategie-Objekt speichert bei Initialisierung feste Referenz auf Kontext
z Implementierung von Default-Verhalten möglich
‹ In der Kontext-Klasse wird ein Default-Verhalten verwendet, wenn kein
Strategie-Objekt gesetzt ist.
(Context)
(T1,...,Tn)
default
(Context)
(T1,...,Tn)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
(Context)
(T1,...,Tn)
(Context)
(T1,...,Tn)
06-27
ROOTS
Implementierung: Fallunterscheidung in Kontext
ContextInterface() {
if (
(strategy == null)
ll)
... default ...
else strategy.AlgorithmInterface();
}
...
z Vorteile
‹ ???
z Nachteile
‹ Uneinheitliche Lösung: Kontext muss Default-Strategie kennen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-28
ROOTS
Implementierung: „Default-Strategie“-Klasse
ContextInterface() {
...
strategy.AlgorithmInterface();
...
}
...
Dies Variante ist als das
Dies ist eine Anwendung
"Null Pattern"
des "Null Object Pattern"
bekannt.
AlgorithmInterface() {
... default
d f lt ...
}
z
Idee
‹ jede Zuweisung "Strategy s = null;"
ersetzen durch "Strategy s = new DefaultStrategy();"
‹ Abfragen auf null und entsprechende Fallunterscheidungen löschen
z
Vorteile
‹ einheitliche Lösung, klare Trennung von Kontext und Strategien
‹ lesbarerer Code
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-29
ROOTS
Das Strategy Pattern: Konsequenzen
z Konzeptuell
‹ Familie von zusammengehörigen Algorithmen
‹ Auswahl verschiedener Implementierungen desselben Verhaltens
‹ dynamische Alternative zu Unterklassenbeziehung
‹ Polymorphismus statt Fallunterscheidungen (if
(if-then-else,
then else switch
switch-case)
case)
‹ leichtere Erweiterbarkeit
z Konsequenzen aus Implementierung
‹ Kontext übergibt evtl. Parameter, die nicht jedes Strategie-Objekt benötigt
Ö this
thi zu übergeben
üb
b iistt allgemeiner
ll
i
‹ Zusätzliche Nachrichten zwischen Kontext und Strategie
‹ Erhöhte Anzahl an Objekten
Ö Möglicherweise können aber Strategie-Objekte gemeinsam verwendet werden
Ö Flyweight-Pattern
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-30
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
Zwischenfazit: Was also sind Patterns?
ROOTS
Definition: Was ist jetzt also ein Pattern?
z Definitionsvorschlag
"A pattern is the abstraction from a concrete form
which keeps recurring in specific non-arbitrary
non arbitrary contexts.
contexts."
Dirk Riehle, Heinz Züllighoven:
"Understanding and Using Patterns in Software Development",
TAPOS 2, 1 (1996).
(
)
z Definitionsvorschlag
"Each pattern is a three-part rule,
which expresses
p
a relation between a certain context,,
a certain system of forces which occurs repeatedly in that context, and
a certain software configuration which allows these forces to resolve
themselves "
themselves.
Richard Gabriel, on the Patterns Home Page
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-32
ROOTS
Aber nicht...
"A pattern is a solution to a problem in a context."
anonym ;-)
Gegenbeispiel
z Problem: Wie werden Objekte im Speicher alloziert?
z Kontext:
K t t Ein
Ei großes
ß OO
OO-System
S t
in
i einem
i
R
Rechner
h
mit
it virtuellem
i t ll
Speicher.
z Lösung:
g Führe einige
g typische
yp
Anwendungen
g durch und stelle fest,,
welche Objekte häufig miteinander kommunizieren. Plaziere diese
Objekte auf derselben Seite im virtuellen Speicher.
Begründung
z Das ist kein Pattern - es ist "nur" eine Lösung für ein Problem in einem
Kontext.
z Damit es zu einem Pattern werden kann, muss ein Lösungsprinzip
abstrahiert werden,
werden das auch für andere wiederkehrende Probleme in
ähnlichen Kontexten eingesetzt werden kann.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-33
ROOTS
Bestandteile eines Patterns: Kontext, Problem, Forces
z Kontext
‹ Die Vorbedingungen unter denen das Pattern benötigt wird.
(Æ Anwendbarkeit des Pattern)
z Problem
‹ Beschreibung des Problems oder der Absicht des Patterns
‹ Ziel 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.
z Randbedingung / Kräfte (Forces)
‹ Die relevanten Randbedingungen und Einschränkungen, die berücksichtigt
werden müssen.
‹ Wie
Wi diese
di
miteinander
it i
d iinteragieren
t
i
und
d iim K
Konflikt
flikt stehen.
t h
‹ Die daraus entstehenden Kosten.
‹ Typischerweise durch ein motivierendes Szenario illustriert.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-34
ROOTS
Bestandteile eines Patterns: Lösung
z Die Lösung
‹ wird beschrieben durch die Teilnehmer, ihre Rollen, ihre statischen
Beziehungen
g und dynamische
y
Zusammenarbeit
z Teilnehmer
‹ Die Typen (Interfaces und Klassen) die in der Lösung eine Rolle spielen.
z Rollen
‹ Alle Namen in der Beschreibung eines Patterns bezeichnen nur die Rollen
der entsprechenden
p
Interfaces,, Klassen,, Methoden,, Felder,, Assotiationen.
‹ Sie werden bei der Implementierung durch zur Anwendung und Rolle
passende Namen ersetzt
‹ Beispiel: Rolle
z Statische Beziehungen und dynamische Zusammenarbeit
‹ Klassendiagramm, dynamisches Diagramm, Text
‹ Meistens ist das Verständnis des dynamischen Verhaltens entscheidend
‹ Denken in Objekten (Instanzen) statt Klassen (Typen)!
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-35
ROOTS
Übersicht aller Bestandteile eines Patterns
z Name des Patterns
z Problem, das vom Pattern g
gelöst wird
z Kontext, in dem das Pattern angewendet werden kann
z Randbedingungen/Kräfte (forces), die das Pattern beeinflussen
z Lösung. Beschreibung, wie das gewünschte Ergebnis erzielt wird
z Beispiele der Anwendung des Patterns
z Resultierender
R
lti
d K
Kontext
t t aus der
d A
Anwendung
d
d
des P
Patterns
tt
z Erläuterung (rationale), warum das Pattern funktioniert
z Bezug zu anderen Patterns
z Bekannte Verwendungen des Patterns
z optional: Zusammenfassung
g ((auch: "pattern thumbnail"))
(Es wurden auch andere Schemata für die Beschreibung
von Pattern definiert
definiert. Dieses hier ist recht ausführlich
ausführlich.))
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-36
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Wichtige Design Patterns
"Gang of Four"-Patterns: Überblick und Klassifikation
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
y
g
z Command
z Template Method
Bisher
z Chain
Ch i off R
Responsibility
ibilit
z Decorator
z State
z Proxy
y
z Strategy
z Adapter
z Multiple Vererbung
z Bridge
Jetzt
z Facade
F
d
Split Objects
z Factory
z Prototype
z Factory Method
z Singleton
z Builder
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Objekt-Erzeugung
06-38
ROOTS
Erläuterung zur Klassifikation
z Verhaltens-Patterns
‹ Verhalten leicht erweiterbar, komponierbar, dynamisch änderbar oder
explizit manipulierbar machen
z Struktur-Patterns
‹ Objekte mit fehlendem Zustand
Zustand, rekursive Strukturen
‹ Verschiedenste Formen der Entkopplung (Schnittstelle / Implementierung,
Identität / physikalische Speicherung, ...)
z Split Object Patterns
‹ Ziel: Dynamisch änderbares Verhalten, gemeinsame Verwendung oder
pp g von Teilobjekten
j
Entkopplung
‹ Weg: Aufteilung eines konzeptionellen Gesamtobjektes in modellierte
Teilobjekte die kooperieren um das Verhalten des konzeptionellen
Gesamtobjektes zu realisieren
z Erzeugungs-Patterns
‹ Flexibilität indem die Festlegung von konkret zu erzeugenden Objekte
(
(new
XYZ()) so weitit wie
i möglich
ö li h verzögert
ö t wird
i d und
d evtl.
tl sogar zur Laufzeit
L f it
immer noch verändert werden kann.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-39
ROOTS
Selbsttest
Ordnen Sie beim Nacharbeiten die auf der
vorherigen Folie genannten Ziele den Ihnen dann
bekannten Patterns zu!
Diskutieren Sie ihre Einschätzung mit Ihren
Kollegen!
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-40
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Facade Pattern
Facade Pattern
z Absicht
‹ Menge von Interfaces eines Subsystems zusammenfassen
‹ Abhängigkeiten der Clients von der Struktur des Subsystems reduzieren
client classes
client classes
Facade
subsystem
y
classes
subsystem
y
classes
z Motivation / Beispiel
‹ Compiler mit Subsystemen
Ö Scanner
Ö ...
Ö CodeGenerator
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-42
ROOTS
Facade Pattern: Beispiel
Compiler
compiler
subsystem
classes
compile()
Stream
BytecodeStream
CodeGenerator
StackMachineCodeGen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Scanner
Token
Parser
Symbol
ProgramNodeBuilder
StatementNode
ProgramNode
ExpressionNode
VariableNode
RISCCodeGenerator
06-43
ROOTS
Facade Pattern: Anwendbarkeit
z einfaches Interface zu einem komplexen Subsystem
‹ einfache Dinge einfach realisierbar (aus Client-Sicht)
‹ anspruchsvolle Clients dürfen auch "hinter die Facade schauen"
Ö zB für seltene, komplexe Anpassungen des Standardverhaltens
z viele Abhängigkeiten zwischen Klassen
‹ reduzieren durch Facade-Objekte
z hierarchische Strukturierung eines System
‹ eine
i F
Facade
d als
l Ei
Einstiegspunkt
ti
kt iin jjede
d Eb
Ebene
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-44
ROOTS
Facade Pattern
z Implementierung: Konfigurierbarkeit einer Facade
‹ eigene Facade-Subklasse pro Konfiguration
oder
‹ andere Subsystem-Objekte instantiieren
z Abgrenzung: Singleton
‹ Facaden sind meist Singletons
g
((man braucht nur eine einzige)
g )
z Abgrenzung: Abstract Factory
‹ zur Erzeugung konsistenter Sätze von Subsystem-Objekten
‹ als Alternative zu Facade Æ "Verstecken" plattform-spezifischer Klassen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-45
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Singleton Pattern
Singleton: Motivation
z Beschränkung der Anzahl von Exemplaren zu einer Klasse
z Meist: nur ein einzelnes Exemplar
‹ Z.B. Facade, Repository, System, Factory (vgl. Abstract Factory)
z Aber auch: festen Menge von Exemplaren
‹ Motivation 1: begrenzte Ressourcen
Ressourcen.
‹ Motivation 2: Teure Objekterzeugung durch „Object Pool“ vermeiden
Æ z.B. 1000 Enterprise Java Beans vorhalten, nach Nutzung zurück in
den Pool
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-47
ROOTS
Singleton: Struktur + Implementierung
Besitzt keinen öffentlichen Konstruktor:
Singleton
getInstance()
instanceOperation()
private Singleton() {
this.Singleton(arg1, ..., argN);
}
private Singleton(...) {
Liefert eine Instanz (typischerweise immer die
...
Selbe):
}
-instancePool
-instanceData
i t
D t
Speichert die einzige
Instanz oder begrenzte
Menge an Instanzen
public static Singleton getInstance() {
if (
(instancePool == null)
)
instancePool = new Singleton();
return instancePool;
}
z Kein öffentlicher Konstruktor
‹ dadurch wird verhindert, dass Clients beliebig
g viele Instanzen erzeugen
g
können
‹ in Java muss explizit ein nicht-öffentlicher Konstruktor mit leerer
Argumentliste
g
implementiert
p
werden,, damit kein impliziter
p
öffentlicher
Konstruktor vom Compiler erzeugt wird
z instancePool als Registry für alle Singleton-Instanzen
‹ lookup-Mechanismus
l k M h i
erforderlich
f d li h um gezielt
i lt eine
i IInstanz
t
auszuwählen
ähl
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-48
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Adapter Pattern
Adapter Pattern (auch: Wrapper)
z Absicht
‹ Schnittstelle existierender Klasse an Bedarf existierender Clients anpassen
z Motivation
‹ Graphik-Editor bearbeitet Shapes
Ö Linien,
Li i
R
Rechtecke,
ht k ...
Ö durch "BoundingBox" beschrieben
‹ Textelemente sollen auch möglich sein
Ö Klasse TextView vorhanden
Ö bietet keine "BoundingBox"-Operation
‹ Integration
g
ohne
Ö Änderung der gesamten Shape-Hierarchie und ihrer Clients
Ö Änderung der TextView-Klasse
z Idee
‹ Adapter-Klasse stellt Shape-Interface zur Verfügung
‹ ... implementiert Shape-Interface anhand der verfügbaren TextViewMethoden
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-50
ROOTS
Adapter Pattern: Beispiel
Existierende Klassen
DrawingEditor
*
Shape
Adapter-Klasse
BoundingBox()
CreateManipulator()
Line
TextShape
BoundingBox()
CreateManipulator()
BoundingBox()
CreateManipulator()
text
TextView
getExtent()
...
return text.getExtent()
return new TextManipulator()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-51
ROOTS
Adapter Pattern (Objekt-Adapter): Schema
adaptee
Client
Target
Adaptee
request()
q
()
other()
f()
f()
Adaptee_N
…
Adapter
…
request()
f()
adaptee.other()
:Client
:Adapter
:Adaptee_N
request()
other()
f()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-52
ROOTS
Adapter Pattern (Objekt-Adapter): Konsequenzen
adaptee
Client
Target
Adaptee
request()
q
()
other()
f()
f()
Adaptee_N
…
Adapter
…
request()
f()
adaptee.other()
z Adaptiert eine ganze Klassenhierarchie
‹ Beliebige
B li bi Ad
Adapter-Subtypen
t S bt
kö
können mit
it b
beliebigen
li bi
Ad t S bt
Adaptee-Subtypen
kombiniert werden (Æ siehe Objektdiagram auf vorheriger Folie)
‹ Kombination wird erst zur Laufzeit, auf Objektebene, festgelegt
z Overriding nicht möglich
‹ Die f()-Definition aus Adapter wird nicht anstelle der f()-Definition aus
Adaptee für den f()-Aufruf
f() Aufruf aus der Methode other() verwendet
(Æ siehe Objektdiagram auf vorheriger Folie)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-53
ROOTS
Adapter Pattern (Object Adapter): Variante
adaptee
Client
Target
Adaptee
request()
q
()
other()
f()
f()
…
Adaptee_N
…
…‘‘
Ad t
Adaptee_N‘
N‘
…‘‘
f()
f()
f()
Adapter
request()
f()
z Object Adapter mit Overriding
‹ zu Adapteee und jede Unterklasse des Adaptees eine weitere Unterklasse
einfügen,
i fü
iin di
die d
das redefinierte
d fi i t Verhalten
V h lt eingefügt
i
fü t wird
i d ((also
l z.B.
B f())
Ö Warum neue Unterklassen? Weil die Adaptee-Hierarchie nicht veränderbar ist!
‹ Problem: Redundanz!
Ö Was konzeptionell nur ein mal in Adapter stehen sollte wird in jeder neuen
Unterklasse von Adaptee redundant eingefügt Æ Wartungsprobleme!
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-54
ROOTS
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
Client
Target
Adaptee
request()
()
other()
th ()
f()
f()
Adaptee_N
…
<<implementation inheritance>>
Adapter
request()
f()
…
anAdaptedAdaptee:Adapter
p
p
p
:Client
request()
other()
f()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-55
ROOTS
Class Adapter Idiom: Konsequenzen
Cli t
Client
T
Target
t
Ad t
Adaptee
request()
other()
f()
f()
Adaptee N
Adaptee_N
…
<<implementation inheritance>>
Adapter
request()
f()
:Client
…
anAdaptedAdaptee:Adapter
z Overriding des Adaptee-Verhaltens
Adaptee Verhaltens leicht möglich
‹ Da Adapter eine Unterklasse von Adaptee ist, funktioniert das Overriding
von f()
z Keine zusätzliche Indirektion
‹ nur ein Objekt statt zwei
z Adaptiert nur eine Klasse
‹ nicht ihre Unterklassen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-56
ROOTS
Adapter Pattern: Konsequenzen
Client
z Class Adapter
‹ adaptiert nur eine Klasse
‹ ... nicht ihre Unterklassen
‹ Overriding des Adaptee-Verhaltens leicht möglich
‹ keine zusätzliche Indirektion (nur ein Objekt) :Client
Target
request()
Adapter
request()
Adaptee
f()
m()
Adapt_N
Adapt
N
f()
m()
:Adapter
:Adaptee
z Object
j
Adapter
‹ adaptiert eine ganze Klassenhierarchie
‹ Overriding schwieriger
Ö redefiniertes
d fi i t Verhalten
V h lt iin spezifische
ifi h U
Unterklasse
t kl
d
des Adaptees
Ad t
einfügen
i fü
Ö Adapter benutzt diese Unterklasse
Ö Kombinierbarkeit mit anderen Unterklassen geht verloren
z Object Adapter mit Delegation (roots.iai.uni-bonn.de/research/darwin)
‹ adaptiert eine ganze Klassenhierarchie
‹ Overriding des Adaptee-Verhaltens leicht möglich
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-57
ROOTS
Class Adapter Idiom: Schema
Client
Target
request()
„Vererbung ohne Subtyping“:
"private inheritance" in C++
oder
"closed inheritance" in Eiffel
Adaptee
specificRequest()
<<implementation inheritance>>
Adapter
req est()
request()
:Client
Vorlesung Softwaretechnologie, Wintersemester 2007/8
specificRequest()
anAdaptedAdaptee:Adapter
06-58
ROOTS
Zweiweg-Adapter ("Two-way adapters")
z Adapter soll auch das Adaptee-Interface erfüllen
‹ Beispiel: QOCA (constraint solving toolkit) und Unidraw (Graphischer
editor)
‹ Explizite Variablen-Repräsentation in beiden Systemen
‹ Integration erfordert Zwei
Zwei-Weg-Adapter
Weg Adapter
z Implementierung
‹ multiple Vererbung
‹ multiple
lti l D
Delegation
l
ti
‹ Einfach-Vererbung und einfach-Delegation
(QOCA class hierarchy)
(Unidraw class hierarchy)
ConstraintVariable
StateVariable
ConstraintStateVariable
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-59
ROOTS
Adapter Pattern: Konsequenzen (2)
z Aufwand des Adapters
‹ einfache Namens-Anpassung
Ö show() --> print()
‹ beliebiges anderes Interface
Ö ganz andere Semantik
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-60
ROOTS
Adapter Pattern: Anwendbarkeit
z Nachträgliche Anpassung
‹ Schnittstelle einer existierenden Klasse anpassen
‹ Å Bisherige Adpater-Varianten
z Vorausschauend Anpassungs-Möglichkeit einbauen
‹ Klasse
Kl
so entwerfen,
t
f
dass
d
sie
i von unbekannten
b k
t Clients
Cli t b
benutzt
t t werden
d
kann, die andere Interfaces erwarten
‹ Æ „Pluggable Adapters“
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-61
ROOTS
Adapter Pattern: Pluggable Adapters
z Motivation
‹ TreeDisplay soll beliebige Baumstrukturen darstellen
‹ Beispiel: Datei-Hierarchie, Vererbungs-Hierarchie
z Idee
‹ Schnittstellen-Anpassbarkeit in TreeDisplay "einbauen"
‹ Minimales Interface identifizieren das TreeDisplay
p y von den angezeigten
g
g
Entities kennen muss
‹ Adaptierbarkeit dieses Interface an verschiedene Hierarchien vorsehen
z Implementierungsvarianten
‹ Vererbung
‹ Simulierte Delegation
‹ Parametrisierung mit "Blöcken"
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-62
ROOTS
a) Pluggable Adapter mit Vererbung und Abstrakten Operationen
<<Client, Target>>
TreeDisplay
g
getChildren
((Node))
createGraphicNode(Node)
display()
buildTree (Node n)
z Anpassungs-Interface ist Teil des TreeDisplay
‹ Abstrakte Methoden
z Adapter sind Unterklassen von TreeDisplay
<<Adapter>>
<<Adaptee>>
FileSystemEntity
DirectoryTreeDisplay
getChildren (Node)
createGraphicNode(Node)
getChildren(n)
for each child {
addGraphicNode(
createGraphicNode(child))
buildTree(child)
}
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Was,, wenn ich
die Art der
Anzeige zur
Laufzeit ändern
will?
ill?
06-63
ROOTS
b) Pluggable Adapter mit „Delegate Objects“
<<Client>>
delegate
TreeDisplay
<<Target>>
TreeAccessorDelegate
setDelegate(Delegate)
g (
g )
display()
buildTree (Node n)
getChildren (TreeDisplay,
(TreeDisplay Node)
createGraphicNode(TreeDisplay, Node)
<<Adapter>>
backreference
<<Adaptee>>
FileSystemEntity
DirectoryBrowser
getChildren (TreeDisplay, Node)
createGraphicNode(TreeDisplay, Node)
createFile()
deleteFile()
z
delegate.getChildren(this,n)
delegate
getChildren(this n)
for each child {
addGraphicNode(
delegate.createGraphicNode(this,child))
buildTree(child)
}
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Eigenes Anpassungs-Interface
‹ Abstrakte Methoden
z
z
Adapter implementieren Interface
Adapter muessen an TreeDisplay
rückfragen können, um dessen
Operationen zu nutzen
06-64
ROOTS
c) Pluggable Adapter Idiom in Smalltalk und Java
Smalltalk
Pseudo-Java
V l M d l
ValueModel
V l M d l
ValueModel
value:
value
setValue()
getValue()
adaptee
PluggableAdaptor
adaptee
Objekt
PluggableAdaptor
getBlock
setBlock
getBlock
setBlock
value:
value
setValue(Oject val)
getValue()
Objekt
GetBlock
getValue(Obj)
SetBlock
setValue(Obj,Val)
^
^getBlock
l k value:
l
adaptee
d
Vorlesung Softwaretechnologie, Wintersemester 2007/8
return getBlock.getValue(adaptee)
06-65
ROOTS
Blöcke in Smalltalk und Java
z Smalltalk
‹ Blöcke sind Objekte die auf die Nachricht „value“ reagieren
Ö Analog zu einem „Command“-Objekt das auf „run“ reagiert
‹ Blöcke können auf den Kontext zugreifen, in dem Sie definiert wurden!
Ö können zz.B.
B direkt auf Variablen des erzeugenden Kontexts zugreifen
z Java
‹ Instanzen einer „Inner Class“ können auf den Kontext der sie erzeugenden
„Outer Class“-Instanz zugreifen
‹ getBlock und setBlock als inner classes der anzupassenden Klasse
‹ Leider ist damit ist keine unvorhergesehene Adaptierung realisierbar
(Änderungen der anzupassenden Klasse wären erforderlich).
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-66
ROOTS
Adapter Pattern: Pluggable Adapter Implementierung
z Vererbung
‹ manchmal zu starr
z Simulierte Delegation
‹ flexibler, da Anpassungsstrategie austauschbar
z Parametrisierung
P
ti i
mit
it "Blö
"Blöcken"
k "
‹ flexibelste Variante
‹ leider
e de nur
u S
Smalltalk-Idiom
a ta d o
‹ „Innere Klassen“ in Java haben nicht die Ausdruckskraft von SmalltalkBlöcken
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-67
ROOTS
Adapter Pattern: Abgrenzung
z Bridge
‹ gleiches Interface
‹ kontrolliert Zugriff
‹ "Implementierungs-Detail"
z Decorator
‹ gleiches Interface
‹ zusätzliche / veränderte
Funktion
‹ "konzeptionelle
konzeptionelle Eigenschaft"
Eigenschaft
z Adapter
‹ verschiedenes Interface
‹ ähnlich Protection-Adapter
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-68
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Proxy Pattern
Proxy Pattern (auch: Surogate, Smart Reference)
z Absicht
‹ Stellvertreter für ein anderes Objekt
‹ bietet Kontrolle über Objekt-Erzeugung und -Zugriff
z Motivation
‹ kostspielige Objekt-Erzeugung verzögern (zB: große Bilder)
‹ verzögerte
g
Objekterzeugung
j
g g soll Programmstruktur
g
nicht g
global verändern
z Idee
‹ Bild-Stellvertreter (Proxy) verwenden
‹ Bild-Stellvertreter verhält sich aus Client-Sicht wie Bild
‹ Bild
Bild-Stellvertreter
Stellvertreter erzeugt Bild bei Bedarf
aTextDocument
image
Hauptspeicher
Vorlesung Softwaretechnologie, Wintersemester 2007/8
anImageProxy
file
anImage
Platte
06-70
ROOTS
Proxy Pattern: Beispiel
Graphic
*
DocumentEditor
draw()
getExtent()
store()
load()
Image
<<creates>>
imageData
g
extent
draw()
getExtent()
g
store()
load()
ImageProxy
fileName
extent
image
Vorlesung Softwaretechnologie, Wintersemester 2007/8
draw()
getExtent()
g
store()
load()
if (image == 0){
image = loadImage(filename);
}
image.draw()
g
()
if (image == 0){
return extent;
} else {
return image.getExtent();
}
06-71
ROOTS
Proxy Pattern: Schema
Subject
*
Client
request()
...
RealSubject
realSubject
Proxy
request()
...
request()
...
aRealSubject
aProxy
← request()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
...
realSubject request();
realSubject.request();
...
q
()
← request()
aClient
06-72
ROOTS
Proxy Pattern: Verantwortlichkeiten
z Proxy
‹ bietet gleiches Interface wie "Subject"
‹ referenziert eine "RealSubject"-Instanz
‹ kontrolliert alle Aktionen auf dem "RealSubject"
z Subject
‹ definiert das g
gemeinsame Interface
z RealSubject
‹ das Objekt das der Proxy vertritt
‹ eigentliche Funktionalität
z Zusammenspiel
‹ selektives Forwarding
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-73
ROOTS
Proxy Pattern: Anwendbarkeit
z Virtueller Proxy
‹ verzögerte Erzeugung "teurer" Objekte bei Bedarf
‹ Beispiel: Bilder in Dokument, persistente Objekte
y
z Remote Proxy
‹ Zugriff auf entferntes Objekt
‹ Objekt-Migration
‹ Beispiele:
B i i l CORBA
CORBA, RMI
RMI, mobile
bil A
Agenten
t
z Concurrency Proxy
‹ nur eine
i di
direkte
kt R
Referenz
f
auff R
RealSubject
lS bj t
‹ locking des RealSubjects vor Zugriff (threads)
z Copy-on-Write
C
W it
‹ kopieren erhöht nur internen "CopyCounter"
‹ wirkliche Kopie bei Schreibzugriff und "CopyCounter">0
CopyCounter 0
Î Verzögerung teurer Kopier-Operationen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-74
ROOTS
Proxy Pattern: Anwendbarkeit
z Protection Proxy (Zugriffskontrolle)
‹ Schmaleres Interface
Ö "Kritische" Operationen ausgeblendet
Ö andere via Forwarding implementiert
‹ ganz anderes Interface
Ö Autorisierung prüfen
Ö direkten Zugriff gewähren oder Forwarding
‹ Beispiel: "CHOICES" Betriebssystem
Betriebssystem, JDK
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-75
ROOTS
Protection-Proxy im JDK (ab 1.2): GuardedObject
z
Problem
‹ Sichere Weitergabe eines schützenwerten Objektes an unbekannten Empfänger
‹ Objektspezifische
j
p
Zugriffsrechte
g
‹ Verzögerte Überprüfung der Zugriffsrechte
z
Idee: GuardedObject
‹ Enthält "bewachtes Objekt" und "Wächter" (Guard)
‹ Guard-Interface enthält nur die Methode checkGuard(Object)
‹ Referenz auf bewachtes Objekt wird nur dann herausgegeben
herausgegeben, wenn
checkGuard(Object)erfolgreich ist (sonst SecurityException)
checkGuard(...)
Requestor
getObject()
Guard
GuardedObject
bewachtes
Obj kt
Objekt
z
Verbleibendes Problem
‹ Man muß sich darauf verlassen
verlassen, daß der "Requestor"
Requestor das "bewachte
bewachte
Objekt" selbst nur in ein GuardedObject verpackt weitergibt!
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-76
ROOTS
Proxy Pattern: Implementierung
z „Consultation“
‹ Allgemein: manuell erstellte Forwarding-Methoden
‹ C++: Operator-Overloading
Ö Proxy redefiniert Dereferenzierungs-Operator:*anImage
Ö Proxy redefiniert Member-Accesss-Operator:anImage->extent()
Member Accesss Operator:anImage >extent()
‹ Smalltalk: Reflektion
Ö Proxy redefiniert Methode "doesNotUnderstand: aMessage"
‹ Lava:
L
eigenes
i
S
Sprachkonstrukt
hk
t kt
Ö Proxy deklariert "consultee"-Variable
class Proxy {
private consultee RealImage realImage;
...
}
z Falls der Typ von "RealSubject
RealSubject„ dem Proxy bekannt sein muß:
‹ Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ
y nicht bekannt sein muß:
z ... dem Proxy
‹ Nur eine Proxy-Klasse für verschiedene RealSubject-Typen
Ö Beispiel: „Guarded Object“ (vorherige Folie)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-77
ROOTS
Proxy Pattern: Implementierung
z Refenrenzierung des RealSubject vor Instantiierung
‹ Orts- und Zeit-unabhängige "Ersatz-Referenzen"
‹ Beispiele
Ö Dateinamen
Ö CORBA IOR (Interoperable Object Reference)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-78
ROOTS
Proxy Pattern: Abgrenzung
z Proxy
‹ gleiches Interface
‹ kontrolliert Zugriff
‹ "Implementierungs-Detail"
z Decorator
‹ gleiches Interface
‹ zusätzliche / veränderte
Funktion
‹ "konzeptionelle
konzeptionelle Eigenschaft"
Eigenschaft
z Adapter
‹ verschiedenes Interface
‹ ähnlich Protection-Proxy
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-79
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Bridge Pattern
Bridge Pattern (auch: Handle / Body)
z Absicht
‹ Schnittstelle und Implementierung trennen
‹ ... unabhängig variieren
z Motivation
‹ portable "Window"-Abstraktion in GUI-Toolkit
‹ mehrere Variations-Dimensionen
Ö Fenster-Arten:
– normal / als Icon,
– schließbar / nicht schließbar,
– ...
Ö Implementierungen:
– X-Windows,
– IBM Presentation Manager
Manager,
– MacOS,
– Windows XYZ,
– ...
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-81
ROOTS
Bridge Pattern: Warum nicht einfach Vererbung einsetzen?
Neue Fenster-Art:
"iconifizierbare" Fenster
Window
XWindow
PMWindow
Window
XWindow
PMWindow
IconWindow
XIconWindow
PMIconWindow
z Probleme dieses Lösungsversuchs
‹ Eigene
Ei
Kl
Klasse fü
für jjede
d K
Kombination
bi ti F
Fenster-Art
t A t / Plattform
Pl ttf
Ö unwartbar
‹ Client wählt Kombination Fenster-Art / Plattform (bei der Objekterzeugung)
Ö plattformabhängiger Client-Code
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-82
ROOTS
Bridge Pattern: Idee
z Trennung von
‹ Konzeptueller Hierarchie
‹ Implementierungs-Hierarchie
bridge
imp
Window
WindowImp
drawText()
drawRect()
devDrawText()
devDrawLine()
imp.devDrawLine()
imp
devDrawLine()
imp.devDrawLine()
imp.devDrawLine()
imp.devDrawLine()
IconWindow
TransientWindow
XWindowImp
PMWindowImp
d
drawBorder()
B d ()
d
drawCloseBox()
Cl
B ()
devDrawText()
devDrawLine()
devDrawLine()
devDrawText()
XDrawLine()
XDrawString()
drawRect()
drawText()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
drawRect()
06-83
ROOTS
Bridge Pattern: Schema
Client
Abstraction
imp
Implementor
operation()
basicOperation()
imp.basicOperation()
RefinedAbstraction
Vorlesung Softwaretechnologie, Wintersemester 2007/8
ConcreteImplementorA
ConcreteImplementorB
basicOperation()
basicOperation()
06-84
ROOTS
Bridge Pattern: Verantwortlichkeiten
z Abstraction
‹ definiert Interface
‹ referenziert Implementierung
z RefinedAbstraction
‹ erweitert das Interface
z Implementor
‹ Interface der Implementierungs-Hierarchie
‹ kann von Abstraction abweichen
z ConcreteImplementor
‹ wirkliche Implementierung
z Zusammenspiel
‹ Forwarding
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-85
ROOTS
Bridge Pattern: Anwendbarkeit
z Dynamische
D
i h Ä
Änderbarkeit
d b k it
‹ Implementierung erst zur Laufzeit auswählen
z Unabhängige Variabilität
‹ neue Unterklassen in beiden Hierarchien beliebig kombinierbar
z Implementierungs-Transparenz für Clients
‹ Änderungen
g der Implementierung
p
g erfordern keine Änderung
g/
Neuübersetzung der Clients
z Vermeidung von "Nested
Nested Generalisations"
Generalisations
‹ keine Hierarchien der Art wie in der Motivations-Folie gezeigt
‹ keine kombinatorische Explosion der Klassenanzahl
z Sharing
‹ mehrere Clients nutzen gleiche Implementierung
‹ z.B. Strings
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-86
ROOTS
Bridge Pattern: Implementierung
Instantiierung des richtigen ConcreteImplementor
z Falls Abstraction alle ConcreteImplementor-Klassen kennt:
‹ Fallunterscheidung im Konstruktor
‹ Auswahl des ConcreteImplementor anhand von Parametern des
Konstruktors
Ö Beispiel: Collection
Ö wenig
i El
Elemente:
t IImplementierung
l
ti
als
l verkettete
k tt t Liste
Li t
Ö viele Elemente: Implementierung als Hashtable
‹ Alternativ: Default-Initialisierung und spätere situationsbedingte Änderung
z Falls Abstraction völlig unabhängig von ConcreteImplementor-Klassen
sein soll:
‹ Entscheidung anderem Objekt überlassen
Î Abstract Factory Pattern
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-87
ROOTS
Bridge Pattern: Abgrenzung
z Bridge
‹ antizipierte Entkopplung von
Schnittstelle und
Implementierung
z Adapter
‹ nachträgliche Anpassung der
Schnittstelle einer
Implementierung
z Abstract Factory
‹ nutzbar zur Erzeugung und
Konfiguration einer Bridge
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-88
ROOTS
Patterns für Subsysteme (Æ siehe „Systementwurf“)
z Facade
‹ Subsystem abschirmen
z Singleton
‹ Nur eine einzige Facade-Instanz erzeugen
z Proxy
P
‹ Stellvertreter für entferntes Subsystem
z Adapter
‹ Anpassung der realen an die erwartete Schnittstelle
z Bridge
‹ Entkopplung der Schnittstelle von der Implementierung
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-89
ROOTS
Vorlesung Softwaretechnologie 2007/8
Dr. Günter Kniesel
ROOTS
Teil 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
z Kontext
‹ GUI-Toolkits mit
Buttons, Menüs, etc.
z Forces
‹ Vielfalt trotz Einheitlichkeit
Ö Einheitlicher Code in allen GUI-Elementen
Ö .. trotzdem verschiedene Effekte
‹ Wiederverwendung
Wi d
d
Ö Über verschiedene GUI-Elemente ansprechbare Operationen nur ein mal
programmieren
‹ Dynamik
Ö dynamische Änderung der Aktionen von Menu-Einträgen
Ö kontext-sensitive Aktionen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-91
ROOTS
Das Command Pattern: Idee
z O
Operationen
i
als
l Obj
Objekte
k mit
i M
Methode
h d execute() d
darstellen
ll
z in den GUI-Elementen speichern
Einheitlicher Aufruf
Verschiedene
Implementierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-92
ROOTS
Das Command Pattern: Anwendbarkeit
z Operationen als Parameter
z Variable Aktionen
‹ referenziertes Command-Objekt austauschen
z Zeitliche Trennung
‹ Befehl zur Ausführung,
g, Protokollierung,
g, Ausführung
g
z Speicherung und Protokollierung von Operationen
‹ History-Liste
‹ Serialisierung
z "Undo" von Operationen
‹ Command-Objekte enthalten neben execute() auch unexecute()
‹ werden in einer History-Liste gespeichert
z Recover-Funktion nach Systemabstürzen
‹ History-Liste
y
wird g
gespeichert
p
‹ Zustand eines Systems ab letzter Speicherung wiederstellbar
z Unterstützung von Transaktionen
‹ Transaktionen können sowohl einfache ("primitive")
( primitive ), als auch komplexe Command
CommandObjekte sein.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-93
ROOTS
Implementierung des Command Patterns
z Unterschiedliche Grade von Intelligenz
‹ Command-Objekte können "nur" Verbindung zwischen Sender und Empfänger sein,
oder aber alles selbstständig erledigen
erledigen.
z 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 werden
sollen.
‹ History-Liste
Ö
Für mehrere Levels von undo/redo
‹ Clonen vor Speicherung in der History-Liste
Ö
Es reicht nicht eine Referenz auf die Objekte zu setzen!
Ö
Man muss das Objekt
j
"tief" Clonen,, um sicherzustellen dass sein Zustand nicht verändert
wird.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-94
ROOTS
Das Command Pattern: Konsequenzen
z Entkopplung
‹ von Aufruf einer Operation und Spezifikation einer Operation.
z Kommandos als Objekte
‹ Command-Objekte können wie andere Objekte auch manipuliert und
erweitert werden
werden.
z Komposition
‹ Folgen von Command-Objekte können zu weiteren Command-Objekten
zusammengefasst werden.
z Erweiterbarkeit
‹ Neue Command
Command-Objekte
Objekte können leicht hinzugefügt werden
werden, da keine
Klassen geändert werden müssen.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-95
ROOTS
Aufgabe
z die sich mit
z Observer
z Strategy
z Command
z lösen
lö
lä
lässt.
t
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-96
ROOTS
Patterns-Überblick
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
y
g
z Command
z Template Method
z Chain
Ch i off R
Responsibility
ibilit
z Decorator
z State
z Adapter
p
z Strategy
z Proxy
z Multiple Vererbung
z Bridge
z Facade
F
d
Split Objects
z Factory
z Prototype
z Factory Method
z Singleton
z Builder
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Objekt-Erzeugung
06-97
ROOTS
Vorlesung Softwaretechnologie 2007/8
Dr. Günter Kniesel
Das Command und Observer Pattern
in Java
© 2000-2007 Dr. Günter Kniesel
ROOTS
Verbindung von Observer und Command in Java (1)
<<interface>>
ActionListener
void actionPerfomed(ActionEvent evt)
<<implements>>
MyPasteCommand
:MenuItem
void actionPerfomed(ActionEvent evt)
:Button
← addActionListener(ActionListener)
:JComponent
z
→ actionPerformed(ActionEvent)
← registerKeyboardAction(ActionListener,
(
KeyStroke,
S
...))
Observer
‹ Buttons, Menue
Menue-Einträge
Einträge und Tasten
generieren "ActionEvents"
‹ Interface "ActionListener" ist
vordefiniert
Î "ActionListener" implementieren
Î ... und Instanzen davon bei Buttons,
MenuItems, etc registrieren
Vorlesung Softwaretechnologie, Wintersemester 2007/8
: MyPasteCommand
z
Command & Observer
‹ gleiche Methode (z.B. actionPerformed)
spielt die Rolle der run() Methode eines
Commands und die Rolle der update()
Methode eines Observers
‹ implementierende Klasse (z.B.
MyPasteCommand) ist gleichzeitig ein
Command und ein Observer
06-99
ROOTS
Verbindung von Observer und Command in Java (2)
z Zusätzliche Unterstützung für "Command"
Command
‹ Interface "Action" und Klasse "AbstractAction"
<<interface>>
ActionListener
void actionPerfomed(ActionEvent evt)
Aktivierung
Akti
i
/
Deaktivierung
von
MenuItems
denen diese
"Action"
zugeordnet
ist
... Parameter
können
allerdings
auch direkt als
InstanzVariablen
realisiert
werden.
<<interface>>
Action
void putValue(String key, Object value)
Object getValue(String key)
Einheitliche Schnittstelle zur
Speicherung von Parametern
für "Action" ...
boolean isEnabled()
void setEnabled(boolean b)
void addPropertyChangeListener(PropertyChangeListener listener)
void removePropertyChangeListener(PropertyChangeListener listener)
im
m JDK en
nthalten
<<extends>>
<<implements>>
AbstractAction
// alles ausser void actionPerfomed(ActionEvent evt)
<<extends>>
MyPasteCommand
void actionPerfomed(ActionEvent evt)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-100
ROOTS
Beispiel: Änderung der Hintergrundfarbe (1)
class ColorAction extends AbstractAction
{ public ColorAction(..., Color c, Component comp)
{ ...
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);
}
}
z ColorAction
‹ Ändern der Hintergrundfarbe einer GUI-Komponente
z ActionButton
‹ Buttons die sofort bei Erzeugung mit einer Action verknüpft werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-101
ROOTS
Beispiel: Änderung der Hintergrundfarbe (2)
z Nutzung der ColorAction
‹ Erzeugung einer Instanz
‹ Registrierung
class SeparateGUIFrame extends JFrame
{ public SeparateGUIFrame()
{ ...
JPanel panel = new JPanel();
Action blueAction = new ColorAction("Blue",
(
, ...,...,
,
, p
panel);
);
panel.registerKeyboardAction(blueAction,...);
panel.add(new
l dd(
A ti B tt (bl A ti ))
ActionButton(blueAction));
JMenu menu = new JMenu("Color");
menu.add(blueAction);
(
);
...
}
}
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-102
ROOTS
Beispiel: Änderung der Hintergrundfarbe (2)
z Nutzung der ColorAction
‹ Erzeugung einer Instanz
‹ Registrierung
class SeparateGUIFrame extends JFrame
{ public SeparateGUIFrame()
{ ...
JPanel panel = new JPanel();
Action blueAction = new ColorAction("Blue",
(
, ...,...,
,
, p
panel);
);
panel.registerKeyboardAction(blueAction,...);
panel.add(new
l dd(
A ti B tt (bl A ti ))
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
Core Java 2
2", Kapitel 8
8,
Abschnitt "Separating GUI and Application Code".
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-103
ROOTS
Fazit
9 Elegante Verbindung von Observer und Command
‹ Commands sind ActionListener von Buttons, Menus, etc.
Ö Einheitlicher Aufru via actionPerformed(ActionEvent evt)
‹ Buttons und Menus sind PropertyChangeListener von Commands
Ö Aktivierung / Deaktivierung
9 Wiederverwendung
‹ gleiche Action für Menu, Button, Key
z Dynamik
‹ Wie ändert man die aktuelle Aktion?
‹ ... konsistent für alle betroffenen MenuItems, Buttons, etc.???
Î Strategy Pattern!
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-104
ROOTS
"Gang of Four"-Patterns: Überblick und Klassifikation
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
y
g
z Command
z Template Method
z Chain
Ch i off R
Responsibility
ibilit
z Decorator
z State
z Proxy
y
z Strategy
z Adapter
z Multiple Vererbung
z Bridge
z Facade
F
d
Split Objects
Jetzt
z Factory
z Prototype
z Factory Method
z Singleton
z Builder
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Objekt-Erzeugung
06-105
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
Das Factory Method Pattern
ROOTS
Factory Method
z Ziel
‹ Entscheidung über konkreter Klasse neuer Objekte verzögern
z Motivation
‹ Framework
F
k mit
it vordefinierten
d fi i t Kl
Klassen "D
"Document"
t" und
d "A
"Application"
li ti "
‹ Template-Methode, für das Öffnen eines Dokuments:
Ö 1. Check ob Dokument-Art bekannt
Ö 2. Erzeugung einer Document-Instanz !?!
‹ Erzeugung von Instanzen noch nicht bekannter Klassen!
z Idee
‹ aktuelle Klasse entscheidet wann Objekte erzeugt werden
Ö Aufruf einer abstrakten Methode
‹ Subklasse entscheidet was für Objekte erzeugt werden
Ö implementiert abstrakte Methode passend
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-107
ROOTS
Factory Method: Beispiel
Framework
D
Document
t
*
docs
A li ti
Application
newDocument()
doCreateDocument()
MyDocument
Document doc = doCreateDocument();
docs.add(doc);
doc.open();
MyApplication
doCreateDocument()
return new MyDocument()
Applikation
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-108
ROOTS
Factory Method: Schema
Product
Creator
anOperation()
factoryMethod()
ConcreteProduct
...
product = factoryMethod();
...
ConcreteCreator
factoryMethod()
return new ConcreteProduct()
z Factory Method
‹ kann abstrakt sein
‹ kann Default-Implementierung haben
z Creator (Aufrufer der Factory Method)
‹ kann Klasse sein, die die Factory Method definiert
‹ kann Client-Klasse
Client Klasse sein
Ö Beispiel: parallele Vererbungs-Hierarchien
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-109
ROOTS
Factory Method: Anwendbarkeit
z Klasse neuer Objekte unbekannt
z Verzögerte Entscheidung über Instantiierung
‹ erst in Subklasse
‹ erst beim Client
z Mehrere Hilfsklassen
‹ Wissen über konkrete Hilfsklassen an einer Stelle lokalisieren
‹ Beispiel: Parallele Hierarchien (nächste Folie)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-110
ROOTS
Factory Method: Anwendbarkeit
Figure
Client
Manipulator
createManipulator()
...
Li Fi
LineFigure
T tFi
TextFigure
createManipulator()
...
createManipulator()
...
downClick()
drag()
upClick()
Li M i l t
LineManipulator
T t
Textmanipulator
i l t
downClick()
drag()
upClick()
downClick()
drag()
upClick()
z Verbindung paralleler Klassenhierarchien
‹ Factory Method lokalisiert das Wissen über zusammengehörige Klassen
‹ Restlicher
R li h C
Code
d d
der Fi
Figure-Hierarchie
Hi
hi und
d Cli
Client-Code
C d iist völlig
ölli
unabhängig von spezifischen Manipulators (nur vom Manipulator-Interface)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-111
ROOTS
Factory Method: Implementierung
z Fester "Produkt-Typ"
‹ jede Unterklasse erzeugt
festgelegte Produkt-Art
Produkt Art
z Codierter "Produkt-Typ"
‹ Parameter oder Objekt-Variable
kodiert "Produkt-Typ"
‹ Fallunterscheidung anhand
Code
Î mehrere Produkte
Î mehr Flexibilität
z Klassen-Objekt als "Produkt-Typ"
‹ Parameter oder Objekt-Variable
ist "Produkt-Typ"
‹ direkte
di k Instantiierung
I
ii
Î mehr Flexibilität
Î bessere Wartbarkeit
Î kein statischer Typ-Check
Vorlesung Softwaretechnologie, Wintersemester 2007/8
class Creator {
Product create(){ MyProduct(); }
}
class Creator {
Product create(int id) {
if (id==1) return MyProduct1();
if (id==2) return MyProduct2();
...
}
}
Idiom reflektiver Sprachen
• Smalltalk
• Java
class Creator {
Object create(Class prodType) {
return prodType.getInstance();
}
}
Reflektiver Aufruf des parameterelosen
Default-Konstruktors
06-112
ROOTS
Factory Method: Konsequenzen
z Code wird abstrakter / wiederverwendbarer
‹ keine festen Abhängigkeiten von spezifischen Klassen
z Verbindung paralleler Klassenhierarchien
‹ Factory
F t
Method
M th d lokalisiert
l k li i t d
das Wi
Wissen üb
über Z
Zusammengehörigkeiten
hö i k it
z evtl. künstliche Subklassen
‹ nur zwecks Objekterzeugung
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-113
ROOTS
Factory Method: Anwendungen
z überall in Toolkits, Frameworks, Class Libraries
‹ Unidraw: Beispiel "Figure und Manipulator"
‹ MacApp und ET++: Beispiel "Document und Application"
z Smalltalk's Model
Model-View-Controller
View Controller Framework
‹ FactoryMethoden-Template: defaultController
‹ Hook-Methode: defaultControllerClass
z Orbix
‹ Erzeugung des richtigen Proxy
Ö leichte Ersetzung von Standard-Proxy durch Caching Proxy
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-114
ROOTS
Factory Method: Abgrenzung
z Template Method
‹ ruft oft Factory Method auf
z Abstract Factory
‹ oft
ft mit
it F
Factory
t
M
Methods
th d iimplementiert
l
ti t
‹ gleiche Motivation
z Prototype
‹ erfordert keine Unterklassenbildung
‹ ... dafür aber explizite initialize()-Methode
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-115
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
Das Abstract Factory Pattern
ROOTS
Abstract Factory
z Ziel
‹ zusammengehörige Objekte verwandter Typen erzeugen
‹ ... ohne deren Klassenzugehörigkeit fest zu codieren
z Motivation
M ti ti
‹ GUI-Toolkit für mehrere Plattformen
‹ Anwendungsklassen
e du gs asse nicht
c t von
o p
plattformspezifischen
att o spe sc e Widgets
dgets ab
abhängig
ä gg
machen
‹ Trotzdem soll die Anwendung
Ö alle Widgets konsistent zu einem "look
look and feel"
feel erzeugen können
Ö "look and feel" umschalten können
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-117
ROOTS
Abstract Factory: Motivation
WidgetFactory
Client
createWindow()
createScrollBar()
Window
MotifWidgetFactory
createWindow()
createScrollBar()
PMWidgetFactory
PMWindow
MotifWindow
createWindow()
createScrollBar()
Scrollbar
PMScrollbar
Vorlesung Softwaretechnologie, Wintersemester 2007/8
MotifScrollBar
06-118
ROOTS
Abstract Factory: Schema
AbstractFactory
Client
createProductA()
createProductB()
AbstractProductA
ConreteFactory1
createProductA()
createProductB()
ConreteFactory2
ProductA2
ProductA1
createProductA()
createProductB()
AbstractProductB
ProductB2
Vorlesung Softwaretechnologie, Wintersemester 2007/8
ProductB1
06-119
ROOTS
Abstract Factory: Implementierung
z ConcreteFactories sind Singletons
z Produkt-Erzeugung via Factory-Methods
z ffester
t Produkt-Typ
P d kt T (eine
( i M
Methode
th d fü
für jjedes
d P
Produkt)
d kt)
‹ Nachteil
Ö neues Produkt erfordert Änderung der gesamten Factory-Hierarchie
z Codierter "Produkt-Typ" (eine parametrisierte Methode für alle
Produkte)
‹ Vorteil
Ö leichte Erweiterbarkeit um neues Produkt
‹ Nachteile:
Ö alle Produkte müssen gemeinsamen Obertyp haben
Ö Clients können nur die Operationen des gemeinsamen Obertyps nutzen
Ö Verzicht auf statische Typsicherheit
z Klassen-Objekt
Klassen Objekt als "Produkt-Typ"
Produkt Typ (eine parametrisierte Methode)
‹ Vorteil
Ö neues Produkt erfordert keinerlei Änderungen der Factory
‹ Nachteil
Ö Verzicht auf jegliche statische Typinformation / Typsicherheit
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-120
ROOTS
Abstract Factory: Implementierung
z Produktfamilie = Subklasse
‹ Vorteil
Ö Konsistenz der Produkte
‹ Nachteil
Ö neue Produktfamilie erfordert neue Subklasse,
Subklasse auch bei geringen
Unterschieden
z Produktfamilie = von Clients konfigurierte assoziative Datenstruktur
‹ Varianten
Ö Prototypen und Cloning
Ö Klassen und Instantiierung
‹ Vorteil
Ö keine Subklassenbildung
g erforderlich
‹ Nachteil
Ö Verantwortlichkeit an Clients abgegeben
Ö konsistente Produktfamilien können nicht mehr garantiert werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-121
ROOTS
Abstract Factory: Konsequenzen
z Abschirmung von Implementierungs-Klassen
‹ Namen von Implementierungsklassen erscheinen nicht im Code von
Clients
‹ Clients benutzen nur abstraktes Interface
z leichte Austauschbarkeit von Produktfamilien
‹ Name
N
einer
i
C
ConcreteFactory
t F t
erscheint
h i t nur ein
i mall iim C
Code
d
Ö bei ihrer Instantiierung
‹ leicht austauschbar gegen andere ConcreteFactory
‹ Beispiel: Dynamisches Ändern des look-and-feel
Ö andere ConcreteFactory instantiieren
Ö alle GUI-Objekte neu erzeugen
z konsistente Benutzung von Produktfamilien
‹ keine Motif-Scrollbar in Macintosh-Fenster
z schwierige Erweiterung um neue Produktarten
‹ Schnittstelle der AbstractFactory legt Produktarten fest
‹ Neue Produktart = Änderung der gesamten Factory-Hierarchie
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-122
ROOTS
Abstract Factory: Anwendbarkeit
z System soll unabhängig sein von
‹ Objekt-Erzeugung
‹ Objekt-Komposition
‹ Objekt-Darstellung
z System soll konfigurierbar sein
‹ Auswahl aus verschiedenen Produkt-Familien
z konsistente Produktfamilien
‹ nur Objekte der gleichen Familie "passen zusammen"
z Library mit Produktfamilie anbieten
‹ Clients sollen nur Schnittstelle kennen
‹ ... nicht die genauen Teilprodukt-Arten / -Implementierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-123
ROOTS
"Gang of Four"-Patterns: Überblick und Klassifikation
Jetzt
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
y
g
z Command
z Template Method
z Chain
Ch i off R
Responsibility
ibilit
z Decorator
z State
z Proxy
y
z Strategy
z Adapter
z Multiple Vererbung
z Bridge
z Facade
F
d
Split Objects
z Factory
z Prototype
z Factory Method
z Singleton
z Builder
Vorlesung Softwaretechnologie, Wintersemester 2007/8
Objekt-Erzeugung
06-124
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Composite Pattern
Composite Pattern
z Ziel
‹ rekursive Aggregations-Strukturen darstellen ("ist Teil von")
‹ Aggregat und Teile einheitlich behandeln
z Motivation
M ti ti
‹ Gruppierung von Graphiken
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-126
ROOTS
Composite Pattern: Beispiel
Graphic
draw()
add(Graphic)
remove(Graphic)
getChildren()
children
Line
Text
Picture
draw()
draw()
draw()
add(Graphic)
remove(Graphic)
getChildren()
aLine
aText
aText
aPicture
Vorlesung Softwaretechnologie, Wintersemester 2007/8
draw() {
for all c in children
c.operation()
}
aPicture
06-127
ROOTS
Composite Pattern: Struktur
*
Client
Component
operation()
add(Component)
remove(Component)
getChildren()
children
Leaf
Composite
operation()
operation()
add(Component)
remove(Component)
getChildren()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
operation() {
for all c in children
c.operation()
}
06-128
ROOTS
Composite Pattern: Verantwortlichkeiten
z Component (Graphic)
‹ gemeinsames Interface aller Teilobjekte
‹ default-Verhalten
‹ Interface für Zugriff auf Teilobjekte (!)
‹ evtl.
evtl Interface für Zugriff auf Elternobjekte
z Leaf ((Rectangle,
g Line, Text))
*
Component
operation()
add(Component)
remove(Component)
(C
t)
getChildren()
children
Leaf
Composite
operation()
operation()
add(Component)
remove(Component)
getChildren()
‹ "primitive" Teil-Objekte
‹ implementieren gemeinsames Interface
‹ leere
l
IImplementierungen
l
ti
fü
für T
Teilzugriffs-Interface
il
iff I t f
p
((Picture))
z Composite
‹ speichert Teilobjekte
‹ implementiert gemeinsames Interface durch forwarding
‹ implementiert Teilzugriffs-Interface
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-129
ROOTS
Composite Pattern: Anwendbarkeit
*
Component
operation()
add(Component)
remove(Component)
(C
t)
getChildren()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
children
Leaf
Composite
operation()
operation()
add(Component)
remove(Component)
getChildren()
06-130
ROOTS
Composite Pattern: Implementierung
Component
Leaf
Composite
operation()
operation()
add(Component)
remove(Component)
(C
)
getChildren()
parent
gemeinsam nutzen
operation()
add(Component)
remove(Component)
getChildren()
1
z Composites sollen wissen wovon sie Teil sind
‹ Explizite Referenzen auf Composite in
Component Klasse
z Mehrere Composites sollen Components
*
children
‹ schließt explizite Referenz der Components
auf Composite aus oder
‹ erfordert, dass Components wissen, dass sie Teile mehrerer Composites
sind
i d
z Component Interface
‹ "Sauberes Design":
g Verwaltungs-Operationen
g
p
((add, remove, g
getChildren))
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 nichts
die
i ht ttutt
Æ Leaf-Klassen sind damit zufrieden, Composites müssen die
Operationen passend implementieren.
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-131
ROOTS
Composite Pattern: Konsequenzen
z einheitliche Behandlung
‹ Teile
‹ Ganzes
z einfache Clients
‹ dynamic
d
i bi
binding
di statt
t tt Fallunterscheidungen
F ll t
h id
z leichte Erweiterbarkeit
‹ neue
eue Leaf-Klassen
ea
asse
‹ neue Composite-Klassen
‹ ohne Client-Änderung
z evtl. zu allgemein
‹ Einschränkung der Komponenten-Typen schwer
‹ run
run-time
time type checks (instanceof)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-132
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Das Visitor Pattern
Das Visitor Pattern
z Absicht
‹ Reprä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
ROOTS
Das Visitor Pattern: Motivation
z Beispiel: Compiler
‹ enthält Klassenhierarchie für Ausdrücke einer Programmiersprache
z Problem
‹ Code einer Operation ist über mehrere Klassen verteilt
‹ Neue
N
O
Operation
ti erfordert
f d t Änderung
Ä d
d
der gesamten
t Hi
Hierarchie
hi
Node
TypeCheck()
GenerateCode()
PrettyPrint()
VariableRefNode
TypeCheck()
GenerateCode()
PrettyPrint()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
AssignmentNode
g
TypeCheck()
GenerateCode()
PrettyPrint()
06-135
ROOTS
Das Visitor Pattern: Idee (1)
z Operation = Objekt
‹ Zusammenfassung aller Methoden einer Operation in einer Klasse
z visit...-Methoden
visit -Methoden
‹ Ausprägung der Operation auf bestimmtem Objekttyp
NodeVisitor
visitAssignment(AssignmentNode)
visitVariableRef(VariableRefNode)
TypeCheckingVisitor
CodeGeneratingVisitor
visitAssignment(AssignmentNode)
visitVariableRef(VariableRefNode)
visitAssignment(AssignmentNode)
visitVariableRef(VariableRefNode)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-136
ROOTS
Das Visitor Pattern: Idee (2)
z "akzeptierende" Methoden in der betroffenen Klassenhierarchie
‹ rufen die jeweils passende visit...-Methode auf
*
Program
Node
accept(NodeVisitor)
AssignmentNode
VariableRefNode
accept(NodeVisitor v)
accept(NodeVisitor v)
v visitAssignment(this)
v.visitAssignment(this)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
v visitVariableRef(this)
v.visitVariableRef(this)
06-137
ROOTS
Das Visitor Pattern: Schema
Client
Visitor
visitConcreteElementA(ConcreteElementA)
visitConcreteElementB(ConcreteElementB)
ConcreteVisitor1
ConcreteVisitor2
visitConcreteElementA(ConcreteElementA)
visitConcreteElementB(ConcreteElementB)
visitConcreteElementA(ConcreteElementA)
visitConcreteElementB(ConcreteElementB)
ObjectStructure
*
Element
accept(Visitor)
ConcreteElementA
accept(Visitor v)
operationA()
v visitConcreteElementA(this)
v.visitConcreteElementA(this)
Vorlesung Softwaretechnologie, Wintersemester 2007/8
ConcreteElementB
accept(Visitor v)
operationB()
v visitConcreteElementB(this)
v.visitConcreteElementB(this)
06-138
ROOTS
Visitor Pattern: Verantwortlichkeiten / Implementation
z Objektstruktur-Hierarchie
‹ einheitliche accept-Methode
z Visitor-Hierarchie
‹ jje eine visit-Methode für jjede Klasse der Objektstruktur
j
z Accept-Methoden
‹ haben Visitor als Parameter
‹ "Welche Operation soll auf mir ausgeführt werden?"
z Visit
Visit-Methoden
Methoden
‹ haben Parameter vom Typ der jeweilige Klasse der Objektstruktur
‹ "Wie soll Operation X auf Objekten des Typs Y ausgeführt werden?"
z Traversierung der Objektstruktur kann definiert sein
‹ in der Objektstruktur
j
((Methode accept(...))
p ( )) oder
‹ im Visitor-Objekt (Method visit...(...))
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-139
ROOTS
Das Visitor Pattern: Zusammenarbeit
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-140
ROOTS
Das Visitor Pattern: Konsequenzen
z Funktionale Dekomposition
‹ Ein Visitor fasst Methoden der gleichen Operation zusammen
‹ ... und trennt Methoden verschiedener Operationen
z Heterogenität
‹ Objekt-Klassen
j
können aus verschiedenen Hierarchien stammen
z Hinzufügen neuer Operationen ist einfach
‹ neue Visitor-Klasse
z Hinzufügen
Hi
fü
neuer Obj
Objekt-Klassen
kt Kl
iistt sehr
h aufwendig
f
di
‹ neue Objekt-Klasse
‹ neue visit... - Methode in allen Visitors
z Sammeln von Zuständen
‹ während der Abwanderung eines Objektbaums
‹ dafür keine zusätzlichen Parametern nötig
z Verletzung von Kapselung
‹ Klassen der Objekstruktur müssen den Visitors ausreichend Funktionalität
bieten
‹ Oft müssen ihre Schnittstellen mehr preisgeben als sonst nötig
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-141
ROOTS
Das Visitor Pattern: Anwendbarkeit
z Funktionale Dekomposition
‹ Zusammengehörige Operationen sollen zusammengefasst werden
‹ ... statt in einer Klassenhierarchie verteilt zu sein
z Stabile Objekt-Hierarchie
‹ selten
lt neue Kl
Klassen
‹ aber oft neue Operationen
g
Hierarchie
z Heterogene
‹ viele Klassen mit unterschiedlichen Schnittstellen
‹ Operationen die von den Klassen abhängen
z Anwendungsbeispiel
‹ Java
Java-Compiler
Compiler des JDK 1
1.3
3
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-142
ROOTS
Überblick
z Einführung
‹ Grundidee, Literatur, MVC-Framework als Beispiel
z Beispiele wichtiger Patterns
‹ Observer, Strategy, Command
‹ Bridge, Factory Method, Abstract Factory
z Patterns Create Architectures
‹ Bridge, Abstract Factory, Singleton
z Nutzen
N t
von Patterns
P tt
z Zusammenfassung und Ausblick
‹ Bestandteile eines Patterns, Definition
‹ Arten von Patterns, Abgrenzung
‹ Weiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-143
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
„Patterns Create Architectures“
Ein Beispiel zum Zusammenspiel von
Patterns
Bridge & Abstract Factory & Singleton
„Patterns Create Architectures“
z Idee
‹ Wenn man Patterns wohlüberlegt zusammen verwendet, entsteht ein
Grossteil einer Software-Architektur aus dem Zusammenspiel der Patterns.
z Beispiel
‹ Zusammenspiel von Bridge, Factory und Singleton
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-145
ROOTS
Erinnerung ans Abstract Factory Pattern
WidgetFactory
Client
createWindow()
createScrollBar()
in der Praxis müsste
WidgetFactory ein
Singleton sein
MotifWidgetFactory
createWindow()
createScrollBar()
PMWidgetFactory
Window
PMWindow
MotifWindow
createWindow()
createScrollBar()
Scrollbar
in der Praxis müsste
hier das BridgePattern angewendet
werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8
PMScrollbar
MotifScrollBar
06-146
ROOTS
Erinnerung ans Bridge Pattern
z Trennung von
‹ Konzeptueller Hierarchie
Client
imp
Window
drawText()
drawRect()
‹ ImplementierungsHierarchie
WindowImp
devDrawText()
devDrawLine()
IconWindow
TransientWindow
PMWindowImp
XWindowImp
drawBorder()
()
drawCloseBox()
C
()
devDrawText()
devDrawLine()
devDrawLine()
devDrawText()
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-147
ROOTS
Zusammenspiel: Bridge, Factory, Singleton
<< konfiguriert >>
Client
WidgetFactory
Singleton
WidgetFactory setFactory(WidgetFactory MOTIF)
WidgetFactory.setFactory(WidgetFactory.MOTIF)
WidgetFactory.getFactory()
PMWidgetFactory
createWindow()
createScrollBar()
<< benutzt >>
Wi d
Window
IconWIndow
TransientWindow
Scrollbar
FixedSB
imp
imp
ProportionalSB
Vorlesung Softwaretechnologie, Wintersemester 2007/8
MotifWidgetFactory
Wi d I
WindowImp
PMWindow
MotifWindow
ScrollbarImp
PMScrollbar
MotifScrollBar
06-148
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
Rückblick: Was nützen Patterns?
ROOTS
Nutzen von Design Patterns (1)
z Objekte / Klassen identifizieren
‹ Abstraktionen, die kein Gegenstück in der realen Welt / dem AnalyseModell haben
‹ Beispiel:
Ö Composite Pattern
Ö Abstraktionen von Prozessen
Ö Strategy
Ö State
‹ "Strict modelling of the real world leads to a system that reflects
today's
y realities but not necesarilly
y tomorrow's. The abstractions that
emerge during design are key to making a design flexible."
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-150
ROOTS
Nutzen von Design Patterns (2)
z Granularität der Objekte festlegen
‹ Facade
Ö ein "Riesen-Objekt"
‹ Flyweight
Ö viele kleine
kleine, gemeinsam verwendbare Teilobjekte
‹ Builder
Ö Komposition von Gesamt-Objekt aus Teilobjekten
‹ Visitor
Ö Gruppe von konsistenten Aktionen
‹ Command
Ö einzelne Aktion
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-151
ROOTS
Nutzen von Design Patterns (3)
z Schnittstellen identifizieren
‹ was gehört dazu
‹ was gehört nicht dazu (Bsp. Memento)
z Beziehungen zwischen Schnittstellen festlegen
‹ Subtyping
Ö Decorator
Ö Proxy
‹ Je eine Methode pro Klasse aus einer anderen Objekthierarchie
Ö Abstract Factory
Ö Builder
Ö Visitor
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-152
ROOTS
Nutzen von Design Patterns (4)
z Wahl der Implementierung
‹ Interface, Abstrakte Klasse oder konkrete Klasse
Ö Grundthema fast aller Patterns
‹ Abstrakte Methode oder Hook Methode
Ö von template method aufgerufene Methoden
‹ Overriding oder fixe Implementierung
Ö Factory method
Ö Template
T
l t method
th d
‹ Vererbung oder Subtyp-Beziehung
Ö Adapter, Decorator, State, Strategy, Command, Chain of Responsibility:
Gemeinsamer Obertyp, nicht gemeinsame Implementierung
‹ Vererbung oder Aggregation
Ö Vererbung ist statisch
Ö Es wird oft mehr vererbt als gewünscht
Ö Beispiel: alle "split object patterns"
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-153
ROOTS
Nutzen von Design Patterns (5):
Patterns verkörpern
erkörpern Gr
Grundprinzipien
ndprin ipien g
guten
ten Designs
z Implementierungen austauschbar machen
‹ Typdeklarationen mit Interfaces statt mit Klassen
‹ Design an Interfaces orientieren, nicht an Klassen
‹ Client-Code wiederverwendbar für neue Implementierungen des gleichen
Interface
z Objekt-Erzeugung änderbar gestalten
‹ "Creational Patterns" statt "new MyClass()"
‹ Client-Code
Cli
C d wiederverwendbar
i d
db fü
für neue IImplementierungen
l
i
d
des gleichen
l i h
Interface
z Funktionalität änderbar gestalten
‹ Aggregation und Forwarding statt Vererbung
‹ späte
ät Konfigurierbarkeit,
K fi i b k it D
Dynamik
ik
‹ weniger implizite Abhängigkeiten (kein "fragile base class problem")
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-154
ROOTS
Überblick
z Einführung
‹ Grundidee, Literatur, MVC-Framework als Beispiel
z Beispiele wichtiger Patterns
‹ Observer, Strategy, Command
‹ Facade, Singleton, Proxy, Adapter, Bridge
‹ Factory Method, Abstract Factory
‹ Composite, Visitor
z Patterns Create Architectures
‹ Bridge, Abstract Factory, Singleton
z Nutzen von Patterns
z Zusammenfassung und Ausblick
‹ Arten von Patterns, Abgrenzung
‹ Weiterführende Themen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-155
ROOTS
Arten von Design Patterns
z Analysis Pattern
‹ wiederkehrende Problemen in der Analysephase eines Softwareprojekts
‹ Martin Fowler: "Analysis Patterns", Addison-Wesley, 1997
z Architektur Pattern
‹ ... beschreibt
b
h ibt mögliche
ö li h ffundamentale
d
t l St
Strukturen
kt
von S
Softwaresystemen.
ft
t
‹ ... enthält vordefinierte Subsysteme und ihre Verantwortlichkeiten.
g
und Richtlinien für die Organisation
g
ihrer Beziehungen.
g
‹ ... enthält Regeln
‹ Beispiel: Das Model-View-Controller Framework
z Design Pattern
‹ Schema für die Realisation von Subsystemen oder Komponenten eines
Softwaresystems
g Pattern))
z Idiom ((auch: Coding
‹ 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
ROOTS
Weitere Arten von Pattern
z Organizational Patterns
‹ Struktur und Praxis von Organisationen; also Gruppen, die ein
gemeinsames Ziel verfolgen
‹ http://www.bell-labs.com/cgiuser/
OrgPatterns/OrgPatterns?OrganizationalPatterns
g
g
g
z Anti-Patterns
‹ beschreiben typische Fehler
‹ ... und bestenfalls auch wie man sie wieder beseitigt
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-157
ROOTS
Abgrenzung: Pattern sind keine Algorithmen
z Patterns versus Algorithmen
‹ Algorithmen lösen feinkörnigere Probleme als Patterns (z.B. Suchen,
Sortieren)
‹ Algorithmen sind deterministischer (weniger ImplementierungsFreiheitsgrade)
g
)
‹ Komplexität von Algorithmen lässt sich leichter fassen
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-158
ROOTS
Abgrenzung: Pattern sind keine Frameworks
z Pattern versus Frameworks
‹ Framework
Ö Menge von kooperierenden Klassen für einen spezifischen
Anwendungsbereich
Ö erweiterbar durch Unterklassenbildung und Komposition von Instanzen
Ö Hollywood-Prinzip ("Don't call us, we'll call you." --> Template Method Pattern)
‹ Patterns sind abstrakter
Ö Frameworks existieren als konkreter
konkreter, wiederverwendbarer Code – Patterns
enthalten nur Beispiele von Code
‹ Patterns sind weniger spezifisch
Ö Frameworks werden für konkrete Anwendungsbereiche eingesetzt – Patterns
können fast überall eingesetzt werden
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-159
ROOTS
Weiterführende Themen
z Pattern Catalogs
‹ Sammlungen von lose zusammenhängenden Patterns
z Pattern Systems
‹ Sammlungen
S
l
von stark
t k zusammenhängenden
hä
d P
Patterns
tt
mit
it engen
Verzahnungen
z Pattern Languages
‹ verfolgen ein gemeinsames Ziel, dass durch die Zusammenarbeit der
enthaltenen Patterns erreicht werden kann
‹ inkl. einer Art "Grammatik", die alle mögliche Kombinationen aufzeigt
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-160
ROOTS
Pattern: Zusammenfassung
z Betonung von Praktikabilität
‹ Patterns sind bekannte Lösungen für erwiesenermaßen wiederkehrende
Probleme
‹ Sie sollen Softwareentwickler bei ihrer Arbeit unterstützen, nicht mehr und
nicht weniger
g
z "Aggressive Hintanstellung von Originalität"
‹ Lösungen, die sich noch nicht in der Praxis bewährt haben, sind keine
Pattern.
Pattern
z Patterns sind kein Allheilmittel
‹ Originalität
g
bei der Anwendung
g von Patterns ist nach wie vor g
gefragt.
g
‹ Es muss immer noch abgewägt werden, welche Patterns, Pattern
Languages, etc. eingesetzt werden.
z Gesamteffekt
‹ Aufgabe 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
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Rückblick, Selbsttest
Im Kapitel „Systementwurf“ kommen die 2 folgenden Folien vor.
Sie sollten nun in der Lage sein
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
g von Design
g Patterns ((Entwurfsmustern))
z Idee
‹ Identifikation von Design Patterns anhand von Schlüsselwörtern in der
Beschreibung nichtfunktionaler Anforderungen
‹ Analog zu Abbots Objektidentifikation durch Textanalyse
z Hinweise auf Abstract Factory Pattern
‹ “Herstellerunabhängig”, “Geräteunabhängig”, “muss eine Produktfamilie
unterstützen”
z Hinweise auf Adapter Pattern
‹ “muss
muss mit einem existierenden Objekt zusammenarbeiten”
zusammenarbeiten
z 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
ROOTS
Nichtfunktionale Anforderungen geben Hinweise zur
Nutzung
g von Design
g Patterns (Fortsetzung)
(
g)
z Hinweise auf Composite Pattern
‹ “komplexe Struktur”, “muss variable Tiefe und Breite haben”
z Hinweise auf Façade Pattern
‹ “muss mit einer Menge existierender Objekte zusammenarbeiten”, "stellt
...-Dienst
-Dienst bereit"
bereit
z Hinweise auf Proxy Pattern
‹ “muss ortstransparent sein”
z Hinweise auf Observer Pattern
‹ “muss erweiterbar sein”, “muss skalierbar sein”
z Hinweise
Hi
i auff Strategy
St t
Pattern
P tt
‹ “muss Funktionalität X in unterschiedlichen Ausprägungen bereitstellen
können”
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-164
ROOTS
Vorlesung Softwaretechnologie 2007/8
Kapitel
ap te 4: Design
es g Patterns
atte s
ROOTS
Ausgeblendete Folien
Auf "Split Objects"-Idee basierende Patterns
1. Das Strategy Pattern
Verbreitung von Patterns
z Prozesse
‹ Unified Process
z Notationen
‹ UML
z Programmiersprachen
P
i
h
‹ Patterns als Sprachkonstrukte
z Libraries
‹ Java APIs
z automatische Erkennung von Patterns
‹ re-engineering
z Tools
‹ Generierung von Quelltexten (z
(z.B.
B Together/J)
z Formalisierung von Patterns
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-167
ROOTS
Advanced Topics
z Pattern Languages
‹Descriptions of systems of patterns with matching initial and resulting
contexts, together with a "grammar" that describes how to compose them.
z Pattern Sequences
‹Concrete sequences of patterns from a pattern language
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
ROOTS
Das Command Pattern
z Bekannte Anwendungen
‹ javax.swing.undo.UndoableEdit
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-169
ROOTS
Das Visitor Pattern: Bekannte Anwendungen
z Java-Compiler des JDK 1.3
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-170
ROOTS
Observer Aufgabe
z Terminkalender-Einträge werden geändert
‹ Visuelle Anzeige aktualisieren
‹ Mail-Benachrichtigungen verschicken
‹ Benachrichtigungsstrategie soll sehr weitgehend konfigurierbar sein
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-171
ROOTS
Änderungen gegenüber Vorlage (Patterns-Vorlesung aus
SS2002))
z Vieles gelöscht
z Design-Vorlage
g
g eine Stufe g
größer ((20 statt 18 Punkt auf 1 Ebene))
‹ Folgeänderung: Verschiebung fixer Objekte auf vielen Folien
‹ Folgeänderung: Löschung von Leerzeilen auf Folien mit viel Text
z Komplett überarbeitete Visitor-Pattern-Folien neu eingefügt (auf Basis
von Pascal‘s Satz aus 2001))
z Folie zu cloning im Prototype Pattern umfangreich überarbeitet (incl.
aufwendiger
f
di
A
Animation)
i ti )
Vorlesung Softwaretechnologie, Wintersemester 2007/8
06-172
ROOTS
Vorlesung Softwaretechnologie 2007/8
Dr. Günter Kniesel
ROOTS
Vorlesung Design Patterns
Sommersemester 2002
Dr. Günter Kniesel
Institut für Informatik III
Universität Bonn
Römerstr. 164, 53117 Bonn
[email protected]
© 2000-2007 Dr. Günter Kniesel
Dieses Material is nur für die Hörer der Vorlesung „Design
Design Patterns
Patterns“
(Sommersemester 2002) bestimmt. Es darf ausschliesslich zur Vorund Nachbereitung der Vorlesung bzw. zur Vorbereitung auf die
entsprechende Prüfung verwendet werden.
werden
Die Weitergabe an Personen außerhalb des oben erwähnten
Personenkreises ist ohne ausdrückliche Genehmigung des Autors
nicht zulässig.
Das komplette
p
Material umfaßt 299 Folien. Die Einleitung
g und die
Beschreibung 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
ROOTS