Kapitel 6 Entwurfsmuster (Design Patterns)

Transcription

Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2008
008
ROOTS
Kapitel 6
Entwurfsmuster (Design Patterns)
Stand: 19.12.2008
Einführung: Die Grundidee von Pattern
z Grundlegende Idee
Alle Ingenieurdisziplinen benötigen eine Terminologie ihrer wesentlichen
Konzepte sowie eine Sprache, die diese Konzepte in Beziehung setzt.
Pattern (Muster) wurden zuerst im Bereich der Architektur beschrieben.
z Ziele von Pattern in der Welt der Software:
Dokumentation von Lösungen wiederkehrender Probleme, um
Programmierer bei der Softwareentwicklung zu unterstützen.
Schaffung einer gemeinsamen Sprache, um über Probleme und ihre
Lösungen zu sprechen.
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
Softwarearchitektur.
© 2000-2008 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Seite 6-2
ROOTS
Einführung: Literatur zu Pattern und
Software
z
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four):
g Patterns - Elements of Reusable Object-Oriented
j
Software"
"Design
Addison-Wesley, 1995
z
Frank Buschmann, Regine
g
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
Portland Pattern Repository: http://c2.com/ppr/
Hillside Group Patterns Library: http://www.hillside.net/patterns/
Brad Appleton: „Patterns and Software: Essential Concepts and Terminology“
http://www.bradapp.net/docs/patterns-intro.html
Doug Lea, Patterns-Discussion FAQ, http://gee.oswego.edu/dl/pd-FAQ/pd-FAQ.html
Buchliste: http://c2.com/cgi/wiki?PatternRelatedBookList
http://c2 com/cgi/wiki?PatternRelatedBookList
© 2000-2008 Dr. G. Kniesel
Seite 6-3
ROOTS
Einführung: Das MVC-Framework in
Smalltalk als Beispiel
a = 50%
b = 30%
c = 20%
2. Änderungen
am Modell
werden
propagiert
-
Model
-
X
1. Views melden sich an
View + Controller
© 2000-2008 Dr. G. Kniesel
X
a = 50%
b = 30%
c = 20%
View + Controller
Seite 6-4
ROOTS
Model
a = 50%
b = 30%
c = 20%
-
X
-
X
-
X
a = 50%
b = 30%
c = 20%
View + Controller
View + Controller
Neue Views können ohne Änderung des Modells oder der anderen Views hinzugefügt werden
© 2000-2008 Dr. G. Kniesel
Seite 6-5
ROOTS
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
X
-
z Geschachtelte Views: Composite Pattern
X
-
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).
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).
© 2000-2008 Dr. G. Kniesel
Seite 6-6
-
X
ROOTS
Überblick
1.
Einführung
2.
Einstiegsbeispiel: "Observer" im Detail
3.
Was also sind Patterns?
4.
Wichtige Patterns
5
5.
Z
Zusammenspiel
i l verschiedener
hi d
P
Patterns
tt
6.
Fazit: Nutzen von Patterns
7.
Zusammenfassung und Ausblick
© 2000-2008 Dr. G. Kniesel
Seite 6-7
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 66: Entwurfsmuster
t u s uste
ROOTS
Das Observer Pattern
Das Observer Pattern: Einführung
z Absicht
Stellt
St llt eine
i 1
1-zu-n Beziehung
B i h
zwischen
i h Obj
Objekten
kt h
her
Wenn das eine Objekt seinen Zustand ändert, werden die davon
abhängigen Objekte benachrichtigt und entsprechend aktualisiert
z Andere Namen
"Dependents"
Dependents , "Publish
Publish-Subscribe
Subscribe", "Listener"
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
„conflicting
fli ti fforces“,
“ also
l gegenläufig
lä fi wirkenden
ik d K
Kräften.
äft
© 2000-2008 Dr. G. Kniesel
Seite 6-10
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%
© 2000-2008 Dr. G. Kniesel
Seite 6-11
ROOTS
Das Observer Pattern: Anwendbarkeit
a = 50%
b = 30%
c = 20%
Das Pattern ist im folgenden Kontext anwendbar:
-
z Abhängigkeiten
-
-
a = 50%
b = 30%
c = 20%
Ein Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt
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 ist nicht bekannt, wie viele Objekte geändert werden müssen.
z Lose Kopplung
Objekte sollen andere Objekte benachrichtigen können, ohne Annahmen
j
machen zu müssen.
über die Beschaffenheit dieser Objekte
© 2000-2008 Dr. G. Kniesel
Seite 6-12
ROOTS
Das Observer Pattern: Struktur
(N:1 Pull-Modell)
(N:1,
Pull Modell)
1
*
<<interface>>
Observer
{abstract}
Subject
subject
observers
observers.add(o)
update() :void
attach(o:Observer):void
detach(o:Observer):void
notify() : void
observers.remove(o)
( )
for all o in observers {
o.update();
}
ConcreteObserver
ConcreteSubject
{redefines subject}
subjectState:State
1
return subjectState;
update() :void
…
subject.getState();
…
© 2000-2008 Dr. G. Kniesel
getState() : State
setState(State s): void
subjectState = s;
notify()
Seite 6-13
ROOTS
Rollenaufteilung / Verantwortlichkeiten
(Pull Modell)
z Observer („Beobachter“) -- auch: Subscriber, Listener
update() -- auch: handleEvent
Ö Reaktion auf Zustandsänderung des Subjects
z Subject („Subjekt“) -- auch: Publisher
attach(Observer o) -- auch: register, addListener
Ö Observer registrieren
detach(Observer o) -- auch: unregister, removeListener
Ö registrierte Observer entfernen
notify()
Ö update-Methoden aller registrierten Observer aufrufen
setState(…)
Ö zustandsändernde Operation(en)
Ö für internen Gebrauch und beliebige Clients
getState()
Ö abfrage des aktuellen Zustands
geändert hat
Ö damit Observer feststellen können was sich wie g
© 2000-2008 Dr. G. Kniesel
Seite 6-14
ROOTS
Das Observer Patterns: Implementierung
Wie werden die Informationen über eine Änderung weitergegeben:
„push
push“ versus „pull
pull“
z Pull: Subjekt übergibt in „update()“
„update() keinerlei Informationen, aber die
Beobachter müssen sich die Informationen vom Subjekt holen
+ Geringere Kopplung zwischen Subjekt und Beobachter.
– Berechnungen
B
h
werden
d hä
häufiger
fi
d
durchgeführt.
h füh t
z Push: Subjekt
j
übergibt
g in Parametern von „„update()“
p
() detaillierte
Informationen über Änderungen.
+ Rückaufrufe werden seltener durchgeführt.
– Beobachter
B b ht sind
i d weniger
i
wiederverwendbar
i d
db (Abhä
(Abhängig
i von d
den
Parametertypen)
z Zwischenformen sind möglich
© 2000-2008 Dr. G. Kniesel
Seite 6-15
ROOTS
Das Observer Pattern: Struktur
(N:1 Push-Modell)
(N:1,
Push Modell)
<<interface>>
Observer
1
*
{abstract}
Subject
subject
observers
observers.add(o)
update(StateA) :void
observers.remove(o)
( )
ConcreteObserver
attach(o:Observer):void
detach(o:Observer):void
notify() : void
ConcreteSubject
subjectStateA:StateA
subjectStateB:StateB
bj tSt t B St t B
update(StateA) :void
© 2000-2008 Dr. G. Kniesel
o.update(subjectStateA);
}
notify() : void
setState(State s): void
Seite 6-16
ROOTS
Das Observer Pattern: Implementierung
z Speicherung der Beziehung zwischen Subjekt und Beobachter
Instanzvariable
I t
i bl im
i S
Subjekt
bj kt oder
d ...
globale (Hash-)Tabelle
z Beobachtung
B b ht
mehrerer
h
Subjekte
S bj kt
Beispiel Tabellenkalkulation: Jede Zelle muss evtl. viele Andere
beobachten um sich bei deren Änderun gneu zu berechnen.
Realisierung: Die „update()“-Methode muss einen Parameter haben, der
das Subjekt angibt, das sich gerade geändert hat.
Querbezug zu Pull
Pull-Modell:
Modell: Der Parameter kann für pull
pull-Rückfragen
Rückfragen an das
Modell genutzt werden (keine fefste Speicherung / Assoziation nötig)
Problem: Welchen Typ hat der Parameter?
Ö „Object
Object“:: Zu unspezifisch,
unspezifisch damit kann man nicht viel anfangen
Ö Konkreter Subject Typ: Zu spezifisch für andere Subjects
© 2000-2008 Dr. G. Kniesel
Seite 6-17
ROOTS
z Vermeidung irrelevanter Notifikationen durch Differenzierung von
Ereignissen
Bisher: Notifikation bei jeder Änderung
Alternative: Beobachter-Registrierung und Notifikation nur für spezielle
Ereignisse
Realisierung: Differenzierung von attach(), detach(), update() und notify() in
jjeweils ereignisspezifische
g
p
Varianten
Vorteile:
Ö Notifikation nur für relevante Ereignisse Æ höhere Effizienz
Ö Weniger „Rückfragen
Rückfragen“ pro Ereignis Æ höhere Effizienz
Nachteil: Mehr Programmieraufwand, wenn man sich für viele
Ereignistypen interessiert
Ö Aber:
Ab W
Werkzeugunterstützung
k
t tüt
möglich
ö li h
© 2000-2008 Dr. G. Kniesel
Seite 6-18
ROOTS
Das Observer Patterns: Implementierung
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 evtl. überflüssigen
Aktualisierungen.
b) Klienten:
Ö + Mehrere Änderungen können akkumuliert werden.
Ö – Klienten vergessen möglicherweise Aufruf von "notify()".
z ChangeManager
Verwaltet Beziehungen zwischen Subjekt und Beobachter.
(Speicherung in Subjekt und Beobachter kann entfallen.)
Definiert die Aktualisierungsstrategie
Benachrichtigt alle Beobachter. Verzögerte Benachrichtigung möglich
Ö Insbesondere wenn mehrere Subjekte
j
verändert werden müssen,, bevor die
Aktualisierungen der Beobachter Sinn macht
© 2000-2008 Dr. G. Kniesel
Seite 6-19
ROOTS
z Konsistenz-Problem
Zustand
Z t d eines
i
S
Subjekts
bj kt muss vor A
Aufruf
f f von "notify()"
" tif ()" konsistent
k
i t t sein.
i
Vorsicht bei Vererbung bei Aufruf jeglicher geerbter Methoden die
möglicherweise „notify()“ -aufrufen :
public class MySubject extends SubjectSuperclass {
public void doSomething(State
p
g(
newState)
) {
super.doSomething(newState); // ruft "notify()" auf
this.modifyMyState(newState); // zu spät!
}
}
z Lösung
Dokumentation von „notify()“-Aufrufen erforderlich (Schnittstelle!)
Besser: In Oberklasse „Template-Method Pattern“ anwenden um
sicherzustellen,, dass „notify()“-Aufrufe
„
y()
immer am Schluss einer Methode
stattfinden Æ s. nächste Folie.
© 2000-2008 Dr. G. Kniesel
Seite 6-20
ROOTS
Verwendung von „Template Method Pattern“
Template Method
public
bli class
l
S bj tS
SubjectSuperclass
l
{
...
final public void doSomething(State newState) {
this.doItReally(newState);
this.notify();
// notify immer am Schluß
}
public void doItReally(State newState) {
}
}
Hook Method
public class MySubject extends SubjectSuperclass {
public void doItReally(State newState) {
this.modifyMyState(newState);
}
}
© 2000-2008 Dr. G. Kniesel
Seite 6-21
ROOTS
Kapitel
t u s uste
ROOTS
Konsequenzen von Observer für
Abhängigkeiten
Für Abhängigkeitsreduzierung allgemein
Für Presentation-Application-Data (PAD)
Für Boundary-Controller-Entity (BCE)
Für Model-View-Kontroller (MVC)
PAD versus BCE versus MVC
Nächste Doppelstunde
Abhängigkeiten mit und ohne Observer
Ohne Observer: Abhängigkeit View Å Model
z Ein
Ei kkonkretes
k t Model
M d l kkenntt d
das IInterface
t f
eines
i
jeden
j d kkonkreten
k t Vi
View
und steuert was genau jeder der Views nach einem update tun soll:
myGraphView1.setGraph(this.toPieChart());
y
p
p (
()); myGraphView1.draw();
y
p
();
myGraphView2.setGraph(this.toBarChart()); myGraphView2.draw();
…
myTextViewN.print(myState.toString());
T tVi N i t( St t t St i ())
:TextViewN
GraphView1
p
GraphView…
…
:GraphView1
:Model
setState(…)
Model
update()
GraphViewJ
setGraph(BarChart
tG h(B Ch t p))
draw()
TextView1
TextView…
print() TextViewN
print()
print()
setState(…)
update()
p
()
toPieChart()
toBarChart()
toString()
pie=toPieChart()
setGraph(pie)
draw()
s = toString()
print(s)
Abhängigkeiten mit und ohne Observer
Mit Observer: Abhängigkeit View Æ Model
z Ein
Ei kkonkretes
k t Model
M d l kkenntt nur d
das abstrakte
b t kt Observer-Interface
Ob
I t f
z Ein konkreter View kennt die zustandsabfragenden Methoden des
konkreten Models
model.getState1();
model.getState2();
<<interface>>
Observer
1
*
observers
Subject
:Model
:View
subject
attach(this)
attach(o:Observer)
detach(o:Observer)
notify()
update()
p
() :void
setState()
o.update();
}
notify()
update()
View
Model
{redefines subject}
getState()
subjectState:State
1
update() :void
getState() : State
setState(State s)
subject.getState();
…
© 2000-2008 Dr. G. Kniesel
Seite 6-24
ROOTS
Nettoeffekt: Abhängigkeits- und
Kontrollumkehrung
Abhängigkeitsumkehrung
(„Dependency Inversion
Inversion“))
Kontrollumkehrung
(„Inversion of Control
Control“))
z Ohne Observer
z Ohne Observer
Abhängigkeit Model Æ Views
z Mit Observer
Model steuert alle updates
z Mit Observer
Abhängigkeit Model Å Views
Vergleich Ablauf ohne / mit Observer
:TextViewN
…
:GraphView1
:Model
Jeder View steuert sein
update
:Model
:View
setState(…)
attach(this)
setState()
update()
pie=toPieChart()
setGraph(pie)
notify()
update()
draw()
getState()
s = toString()
print(s)
Auswirkungen von Observer auf
„Presentation
Presentation-Application-Data“-Ebenen
Application Data Ebenen
z n-tier-Architekturen basieren auf der rein hierarchische Anordnung von
Presentation Anwendungslogik und Datenhaltung
Presentation,
Präsentation
ConcreteObserver
Anwendungslogik
Datenhaltung
ConcreteSubject
AbstractSubject
AbstractObserver
z Die Aktualisierung der Präsentation bei Änderung
Ä
der Daten ist durch
das Observer-Pattern möglich, ohne dass die Daten von der
Präsentation wissen müssen.
Sie sind nur von dem AbstractObserver abhängig.
Wenn dessen Definition in der Datenschicht angesiedelt ist, wird die
Ebenenanordnung nicht verletzt
© 2000-2008 Dr. G. Kniesel
Seite 6-26
ROOTS
Auswirkungen von Observer für
„Boundary
Boundary-Controller-Entity“
Controller Entity Stereotypen
z Die Abhängigkeitsreduzierung ist die gleiche wie bei den Presentation-
Application Data Ebenen der N
Application-Data
N-Ebenen-Architekturen
Ebenen Architekturen
Boundaries
ConcreteObserver
Controllers
Entities
ConcreteSubject
AbstractSubject
AbstractObserver
z Der einzige Unterschied zwischen BCE und PAD ist die Gruppierung:
BCE beschreibt lediglich die Funktionen einzelner Objekttypen (Es sagt
pp
g in Ebenen aus))
nichts über ihre Gruppierung
PAD sagt etwas über die Gruppierung von Objekttypen gleicher Funktion:
Ö Alle Boundaries mit GUI-Funktionalität in der Präsentationsschicht
Ö Alle Controller in der Anwendungslogik
Anwendungslogik-Schicht
Schicht
Ö Alle Entities in der Datenhaltungs-Schicht
© 2000-2008 Dr. G. Kniesel
Seite 6-27
ROOTS
Model View Controller
Model-View-Controller
z Views sind immer Boundaries und Observer
Sonst
S
t könnten
kö t Sie
Si ihre
ih F
Funktion
kti nicht
i ht erfüllen
füll
Das schließt nicht aus, dass sie eventuell noch andere Rollen spielen
z Boundaries sind nicht immer Views
Beispiel: Tastatur
Boundaries / Views
ConcreteObserver
Controllers / Controllers
Entities / Model
© 2000-2008 Dr. G. Kniesel
ConcreteSubject
AbstractSubject
AbstractObserver
Seite 6-28
ROOTS
Model View Controller
Model-View-Controller
z Observer sind nicht immer Views!
Auch
A hK
Kontroller
t ll kö
können Observer
Ob
sein!
i !
Sie können sich bei einer Menge von Modellelementen als Observer
registrieren und deren Veränderungen sammeln, bewerten und gefiltert
oder kummuliert weitergeben.
Ö Aktive Weitergabe: Aufruf / Steuerung von Aktionen anderer Objekte
(„Kontroller“-Rolle)
Ö Passive Weitergabe: Beachrichtigung von eigenen Observern („Modell“-Rolle)
Ö Siehe auch „Mediator-Pattern“ („Vermittler“)
Das g
gleiche g
gilt auch für andere Modellelemente / Entities: auch sie
können Observer von anderen Objekten sein.
© 2000-2008 Dr. G. Kniesel
Seite 6-29
ROOTS
Das Observer Pattern: Konsequenzen
z Unabhängigkeit
Konkrete
K k t Beobachter
B b ht können
kö
hi
hinzugefügt
fü t werden,
d
ohne
h kkonkrete
k t S
Subjekte
bj kt
oder andere konkrete Beobachter zu ändern.
Konkrete Subjekte können unabhängig voneinander und von konkreten
Beobachtern variiert werden.
Konkrete Subjekte können unabhängig voneinander und von konkreten
Beobachtern wiederverwendet werden.
z Abstrakte Kopplung
Subjekte
S bj kt aus tieferen
ti f
S
Schichten
hi ht eines
i
S
Systems
t
kö
können mit
it B
Beobachtern
b ht
aus höheren Schichten kommunizieren, ohne die Schichten zu verletzen.
Präsentation
ConcreteObserver
Anwendungslogik
D
Datenhaltung
h l
© 2000-2008 Dr. G. Kniesel
C
ConcreteSubject
t S bj t
Ab t
AbstractSubject
tS bj t
Ab t
AbstractObserver
tOb
Seite 6-30
ROOTS
Das Observer Pattern: Konsequenzen
z „Broadcast“-Nachrichten
Subjekt
S bj kt benachrichtigt
b
h i hti t alle
ll angemeldeten
ld t B
Beobachter
b ht
Beobachter entscheiden, ob sie Nachrichten behandeln oder ignorieren
z Unerwartete Aktualisierungen
Kleine Zustandsänderungen des Subjekts können komplexe Folgen haben.
Auch uninteressante Zwischenzustände können unnötige Aktualisierungen
auslösen.
© 2000-2008 Dr. G. Kniesel
Seite 6-31
ROOTS
Das Observer Pattern: Bekannte
Anwendungen
z Bekannte Anwendungen
Model-View-Controller-Framework
M d l Vi
C t ll F
k in
i Smalltalk
S llt lk
Java Foundation Classes / Swing
Oberon System
y
Diverse Client/Server-Modelle, z.B. Java RMI
© 2000-2008 Dr. G. Kniesel
Seite 6-32
ROOTS
Kapitel
t u s uste
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 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 a relation between a certain context,
a certain system of forces which occurs repeatedly in that context,
context and
a certain software configuration which allows these forces to resolve
themselves."
Richard Gabriel, on the Patterns Home Page
© 2000-2008 Dr. G. Kniesel
Seite 6-37
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: Ein großes OO-System in einem Rechner mit virtuellem
Speicher.
z Lösung: Führe einige typische Anwendungen durch und stelle fest,
welche Objekte häufig miteinander kommunizieren. Plaziere diese
Objekte
j
auf derselben Seite im virtuellen Speicher.
p
Begründung
z Das
D iistt kkein
i P
Pattern
tt
- es ist
i t "nur"
" " eine
i Lö
Lösung fü
für ein
i P
Problem
bl
iin einem
i
Kontext.
z Damit es zu einem Pattern werden kann,, muss ein Lösungsprinzip
g p
p
abstrahiert werden, das auch für andere wiederkehrende Probleme in
ähnlichen Kontexten eingesetzt werden kann.
Bestandteile eines Patterns: Kontext,
Problem Randbedingungen
Problem,
z Kontext
Die Vorbedingungen unter denen das Pattern benötigt wird
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
b ti
bestimmten
t Randbedingungen/Kräften
R db di
/K äft erreicht
i ht werden
d sollen.
ll
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 diese miteinander interagieren und im Konflikt stehen.
Die daraus entstehenden Kosten.
Typischerweise durch ein motivierendes Szenario illustriert
illustriert.
© 2000-2008 Dr. G. Kniesel
Seite 6-39
ROOTS
Bestandteile eines Patterns: Lösung
z Die Lösung
wird
idb
beschrieben
hi b d
durch
h di
die T
Teilnehmer,
il h
ih
ihre R
Rollen,
ll
ih
ihre statischen
t ti h
Beziehungen und dynamische Zusammenarbeit
z Teilnehmer
Die Typen (Interfaces und Klassen) die in der Lösung eine Rolle spielen.
z Rollen
Alle
All N
Namen iin d
der B
Beschreibung
h ib
eines
i
P
Patterns
tt
b
bezeichnen
i h
nur di
die R
Rollen
ll
der entsprechenden 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)!
© 2000-2008 Dr. G. Kniesel
Seite 6-40
ROOTS
Bestandteile einer Pattern-Beschreibung
z Name des Patterns
z Problem,
P bl
d vom P
das
Pattern
tt
gelöst
lö t wird
id
z Kontext, in dem das Pattern angewendet werden kann
z Randbedingungen/Kräfte (forces),
(forces) die das Pattern beeinflussen
z Lösung. Beschreibung, wie das gewünschte Ergebnis erzielt wird
z Beispiele
p
der Anwendung
g der Lösung
g
z Resultierender Kontext aus der Anwendung des Patterns
z Erläuterung (rationale), warum das Pattern funktioniert
z Bezug zu anderen Patterns
z Bekannte Verwendungen des Patterns
© 2000-2008 Dr. G. Kniesel
Seite 6-41
ROOTS
Kapitel
t u s uste
ROOTS
Klassifikation
Danach, was sie modellieren
Danach, wie sie es modellieren
Danach, wo sie meist eingesetzt werden
"Gang of Four"-Patterns: Überblick und
Klassifikation
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
z Command
z Template Method
Bisher
z Chain of Responsibility
z Decorator
z State
z Proxy
z Strategy
z Adapter
z Multiple
M lti l V
Vererbung
b
z Bridge
z Facade
Split Objects
z Factory Method
z Prototype
z Abstract Factory
z Singleton
z Builder
Objekt-Erzeugung
Jetzt
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
S lit Object
Obj t Patterns
P tt
Ziel: Dynamisch änderbares Verhalten, gemeinsame Verwendung oder
Entkopplung von Teilobjekten
Weg: Aufteilung eines konzeptionellen Gesamtobjektes in modellierte
Teilobjekte die kooperieren um das Verhalten des konzeptionellen
Gesamtobjektes
j
zu realisieren
z Erzeugungs-Patterns
Flexibilität indem die Festlegung von konkret zu erzeugenden Objekte
(new XYZ()) so weit wie möglich verzögert wird und evtl
evtl. sogar zur Laufzeit
immer noch verändert werden kann.
© 2000-2008 Dr. G. Kniesel
Seite 6-44
ROOTS
Klassifikation von Entwurfsmustern
(Fortsetzung)
z Klassifikation danach was modelliert wird (vorherige Folien)
Struktur,
St kt Verhalten,
V h lt
Obj
Objekterzeugung
kt
z Klassifikation danach, wie etwas modelliert wird (vorherige Folien)
Whole Objects: 1:1-Entsprechung
1:1 Entsprechung von konzeptuellen Objekten und
Implementierungs-Objekten
Split Objects: Aufteilung eines konzeptuellen Objektes in verschiedene
Implementierungs-Objekte
Implementierungs
Objekte, dynamisch veränderbare Anteile oder
Gemeinsamkeiten verschiedener konzeptueller Objekte darstellen
z Klassifikation danach, wo sie meist eingesetzt werden
Systementwurf, zur Verbindung / Abgrenzung von Subsystemen
Ö Facade, Adapter, Bridge, Proxy, Singleton (zusammen mit Facade) , Observer
Objektentwurf
j
Ö Observer, Command, Factory Method, Abstract Factory, Composite, Visitor
Entsprechende Aufteilung der Foliensätze / Kapitel
Ö Dieser Foliensatz: Entwurfsmuster-Einführung (Kapitel 4
4.))
Ö Systementwurf und Systementwurfs-Muster (Kapitel 5.)
Ö Objektentwurf und Objektenwurfs-Muster (Kapitel 6.)
Kapitel
t u s uste
ROOTS
Wichtige Design Patterns
Patterns, Teil 1
- System Design Patterns -
Facade
Singleton
Adapter
Proxy
Bridge
Patterns für Subsysteme (Æ siehe
„Systementwurf
Systementwurf“)
)
z Facade
Subsystem
S b
t
abschirmen
b hi
z Singleton
Nur eine einzige Facade-Instanz
Facade Instanz erzeugen
z Adapter
Anpassung der realen an die erwartete Schnittstelle
z Proxy
Stellvertreter für entferntes Subsystem
z Bridge
Entkopplung der Schnittstelle von der Implementierung
© 2000-2008 Dr. G. Kniesel
Seite 6-48
ROOTS
Kapitel
t u s uste
ROOTS
Das Facade Pattern
Facade Pattern
z Absicht
Menge
g von Interfaces eines Subsystems
y
zusammenfassen
Abhängigkeiten der Clients von der Struktur des Subsystems reduzieren
client classes
client classes
Facade
subsystem
classes
subsystem
classes
z Motivation / Beispiel
p
Compiler mit Subsystemen
Ö Scanner
Ö ...
Ö CodeGenerator
© 2000-2008 Dr. G. Kniesel
Seite 6-50
ROOTS
Facade Pattern: Beispiel
Compiler
compiler
subsystem
classes
compile()
St
Stream
BytecodeStream
CodeGenerator
StackMachineCodeGen
StackMachineCodeGen.
© 2000-2008 Dr. G. Kniesel
S
Scanner
T k
Token
Parser
Symbol
ProgramNodeBuilder
StatementNode
ProgramNode
ExpressionNode
VariableNode
RISCCodeGenerator
Seite 6-51
ROOTS
Facade Pattern: Anwendbarkeit
z Einfaches Interface zu einem komplexen Subsystem
Einfache
Ei f h Dinge
Di
einfach
i f h realisierbar
li i b ((aus Cli
Client-Sicht)
t Si ht)
Anspruchsvolle Clients dürfen auch "hinter die Facade schauen"
Ö zB für seltene, komplexe Anpassungen des Standardverhaltens
z Viele Abhängigkeiten zwischen Klassen
Reduzieren
R d i
d
durch
hF
Facade-Objekte
d Obj kt
z Hierarchische Strukturierung
g eines System
y
Eine Facade als Einstiegspunkt in jede Ebene
© 2000-2008 Dr. G. Kniesel
Seite 6-52
ROOTS
Facade Pattern
z Implementierung: Konfigurierbarkeit einer Facade
Eigene
Ei
F
Facade-Subklasse
d S bkl
pro K
Konfiguration
fi
ti
oder
andere Subsystem-Objekte
y
j
instantiieren
z Abgrenzung: Singleton
Facaden sind meist Singletons
S
(man
(
braucht nur eine einzige))
z Abgrenzung: Abstract Factory
Zur Erzeugung konsistenter Sätze von Subsystem-Objekten
Als Alternative zu Facade Æ "Verstecken" plattform-spezifischer Klassen
© 2000-2008 Dr. G. Kniesel
Seite 6-53
ROOTS
Kapitel
t u s uste
ROOTS
Anwendung von „Facade
Facade“ zur
Subsystemrealisierung
Ein Rückblick auf die Folien 5-22 bis 5-25
Naive System-Dekomposition: nur
Gruppierung (mit Packages)
Subsystem 1
Subsystem 5
Subsystem 2
Subsystem 3
Subsystem 4
Subsystem
y
6
© 2000-2008 Dr. G. Kniesel
Seite 6-55
ROOTS
System-Dekomposition: Dienste und
Komponenten
Subsystem 1
Subsystem 5
Subsystem 2
Subsystem 3
Subsystem 4
Subsystem
y
6
© 2000-2008 Dr. G. Kniesel
Seite 6-56
ROOTS
System-Dekomposition: DiensteRealisierung mit Facades
Subsystem 1
<<Facade>>
Subsystem 5
Subsystem 2
Subsystem 3
<<Facade>>
<<Facade>>
Subsystem 4
Subsystem
y
6
<<Facade>>
© 2000-2008 Dr. G. Kniesel
Seite 6-57
ROOTS
Kapitel
t u s uste
ROOTS
Das Singleton Pattern
Singleton: Motivation
z Beschränkung der Anzahl von Exemplaren zu einer Klasse
z Meist: nur ein einzelnes Exemplar
Z.B.
Z B Facade,
Facade Repository
Repository, System
System, Factory (vgl
(vgl. Abstract Factory)
z Aber auch: feste Menge von Exemplaren
Motivation 1: begrenzte Ressourcen.
Motivation 2: Teure Objekterzeugung durch „Object Pool“ vermeiden
Æ z.B.
z B 1000 Enterprise Java Beans vorhalten
vorhalten, nach Nutzung zurück in
den Pool
© 2000-2008 Dr. G. Kniesel
Seite 6-59
ROOTS
Singleton: Struktur + Implementierung
Besitzt nur private Konstruktoren:
Singleton
getInstance()
instanceOperation()
-instancePool
-instanceData
private Singleton() {
this.Singleton(arg1, ..., argN);
}
Liefert eine Instanz (typischerweise immer die
private Singleton(...) {
Selbe):
...
}
public static Singleton getInstance() {
if (instancePool == null)
Speichert die einzige
instancePool = new Singleton();
return instancePool;
Instanz oder begrenzte
g
}
Menge an Instanzen
z Nur private Konstruktoren
dadurch
d d h wird
i d verhindert,
hi d
d
dass Cli
Clients b
beliebig
li bi viele
i l IInstanzen erzeugen
können
in Java muss explizit ein privater Konstruktor mit leerer Argumentliste
implementiert werden, damit kein impliziter öffentlicher Konstruktor vom
Compiler erzeugt wird
g y für alle Singleton-Instanzen
g
z instancePool als Registry
lookup-Mechanismus erforderlich um gezielt eine Instanz auszuwählen
© 2000-2008 Dr. G. Kniesel
Seite 6-60
ROOTS
Kapitel
t u s uste
ROOTS
Das Proxy Pattern
Proxy Pattern (auch: Surogate, Smart
Reference)
z Absicht
Stellvertreter
St ll t t fü
für ein
i anderes
d
Obj
Objekt
kt
bietet Kontrolle über Objekt-Erzeugung und -Zugriff
z Motivation
kostspielige Objekt-Erzeugung verzögern (zB: große Bilder)
verzögerte Objekterzeugung
O
soll Programmstruktur nicht global verändern
z Idee
Bild-Stellvertreter (Proxy) verwenden
Bild-Stellvertreter verhält sich aus Client-Sicht wie Bild
Bild-Stellvertreter erzeugt Bild bei Bedarf
aTextDocument
image
anImageProxy
file
anImage
Hauptspeicher
© 2000-2008 Dr. G. Kniesel
Platte
Seite 6-62
ROOTS
Proxy Pattern: Beispiel
<<interface>> *
Graphic
DocumentEditor
draw()
getExtent()
store()
load()
Image
<<creates>>
imageData
extent
draw()
getExtent()
store()
load()
© 2000-2008 Dr. G. Kniesel
ImageProxy
fileName
extent
image
draw()
getExtent()
store()
load()
if (image == 0){
image = loadImage(filename);
}
image.draw()
if (image == 0){
return extent;
} else {
return image.getExtent();
}
Seite 6-63
ROOTS
Proxy Pattern: Schema
<<interface>> *
Client
Subject
j
request()
...
RealSubject
realSubject
Proxy
request()
...
request()
...
aRealSubject
aProxy
← request()
© 2000-2008 Dr. G. Kniesel
...
realSubject request();
realSubject.request();
...
q
()
← request()
aClient
Seite 6-64
ROOTS
Proxy Pattern: Verantwortlichkeiten
z Proxy
bietet
bi t t gleiches
l i h IInterface
t f
wie
i "S
"Subject"
bj t"
referenziert eine "RealSubject"-Instanz
kontrolliert alle Aktionen auf dem "RealSubject"
j
z Subject
definiert
f
das gemeinsame Interface
f
z RealSubject
das Objekt das der Proxy vertritt
eigentliche Funktionalität
z Zusammenspiel
selektives Forwarding
© 2000-2008 Dr. G. Kniesel
Seite 6-65
ROOTS
Proxy Pattern: Anwendbarkeit
z Virtueller Proxy
verzögerte
g
Erzeugung
g g "teurer" Objekte
j
bei Bedarf
Beispiel: Bilder in Dokument, persistente Objekte
z Remote Proxy
Zugriff auf entferntes Objekt
Objekt-Migration
Beispiele:
e sp e e CO
CORBA,, RMI,, mobile
ob e Agenten
ge te
z Concurrency Proxy
nur eine direkte Referenz auf RealSubject
locking des RealSubjects vor Zugriff (threads)
z Copy-on-Write
kopieren
k i
erhöht
höht nur iinternen
t
"C
"CopyCounter"
C
t "
wirkliche Kopie bei Schreibzugriff und "CopyCounter">0
Î Verzögerung teurer Kopier-Operationen
© 2000-2008 Dr. G. Kniesel
Seite 6-66
ROOTS
Proxy Pattern: Anwendbarkeit
z Protection Proxy (Zugriffskontrolle)
Schmaleres
S h l
IInterface
t f
Ö "Kritische" Operationen ausgeblendet
Ö andere via Forwarding implementiert
ganz anderes Interface
Ö Autorisierung prüfen
Ö direkten Zugriff gewähren oder Forwarding
Beispiel: "CHOICES" Betriebssystem, JDK
© 2000-2008 Dr. G. Kniesel
Seite 6-67
ROOTS
Protection-Proxy im JDK (ab 1.2):
GuardedObject
z
Problem
Sichere Weitergabe eines schützenwerten Objektes an unbekannten Empfänger
Objektspezifische Zugriffsrechte
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, 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!
© 2000-2008 Dr. G. Kniesel
Seite 6-68
ROOTS
Proxy Pattern: Implementierung
z „Consultation“
Allgemein: manuell erstellte Forwarding-Methoden
Forwarding Methoden
C++: Operator-Overloading
Ö Proxy redefiniert Dereferenzierungs-Operator:*anImage
Ö Proxy redefiniert Member-Accesss-Operator:anImage->extent()
Smalltalk: Reflektion
Ö Proxy redefiniert Methode "doesNotUnderstand: aMessage"
Lava: eigenes Sprachkonstrukt
Ö Proxy deklariert "consultee"-Variable
class Proxy {
private consultee RealImage realImage;
...
}
z Falls der Typ von "RealSubject„ dem Proxy bekannt sein muß:
Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ
z ... dem Proxy nicht bekannt sein muß:
Nur eine Proxy-Klasse für verschiedene RealSubject-Typen
Ö Beispiel:
B i i l „Guarded
G d d Object“
Obj t“ (vorherige
( h i F
Folie)
li )
© 2000-2008 Dr. G. Kniesel
Seite 6-69
ROOTS
Proxy Pattern: Implementierung
z Refenrenzierung des RealSubject vor Instantiierung
OrtsO t und
dZ
Zeit-unabhängige
it
bhä i "E
"Ersatz-Referenzen"
t R f
"
Beispiele
Ö Dateinamen
Ö CORBA IOR (Interoperable Object Reference)
© 2000-2008 Dr. G. Kniesel
Seite 6-70
ROOTS
Proxy Pattern: Abgrenzung
z Proxy
z Decorator
gleiches
l i h IInterface
t f
kontrolliert Zugriff
p
g
"Implementierungs-Detail"
gleiches
l i h IInterface
t f
zusätzliche / veränderte
Funktion
"konzeptionelle Eigenschaft"
z Adapter
verschiedenes Interface
ähnlich Protection-Proxy
© 2000-2008 Dr. G. Kniesel
Seite 6-71
ROOTS
Kapitel
t u s uste
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, Rechtecke, ...
Ö durch "BoundingBox" beschrieben
Textelemente sollen auch möglich sein
Ö Klasse TextView vorhanden
Ö bietet keine "BoundingBox"-Operation
Integration 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
© 2000-2008 Dr. G. Kniesel
Seite 6-73
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()
© 2000-2008 Dr. G. Kniesel
Seite 6-74
ROOTS
Adapter Pattern (Objekt-Adapter):
Schema
adaptee
Client
Target
Adaptee
request()
other()
f()
f()
Adaptee_N
…
Adapter
…
request()
f()
adaptee.other()
:Client
:Adapter
:Adaptee_N
request()
other()
f()
© 2000-2008 Dr. G. Kniesel
Seite 6-75
ROOTS
Adapter Pattern (Objekt-Adapter):
Konsequenzen
adaptee
Client
Target
Adaptee
request()
other()
f()
f()
Adaptee_N
…
Adapter
…
request()
f()
adaptee.other()
d t
th ()
z Adaptiert eine ganze Klassenhierarchie
Beliebige Adapter
Adapter-Subtypen
Subtypen können mit beliebigen Adaptee-Subtypen
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
p
für den f()-Aufruf
()
aus der Methode other()
() verwendet
(Æ siehe Objektdiagram auf vorheriger Folie)
© 2000-2008 Dr. G. Kniesel
Seite 6-76
ROOTS
Adapter Pattern (Object Adapter):
Variante
Client
Target
request()
q
()
Adapter
Adaptee
adaptee
other()
f()
f()
…
Adaptee_N
…
…‘‘
Ad t
Adaptee_N‘
N‘
…‘‘
f()
f()
f()
request()
f()
z Object Adapter mit Overriding
zu Adaptee und jede Unterklasse des Adaptees eine weitere Unterklasse
einfügen, in die das redefinierte Verhalten eingefügt wird (also z.B. f())
Ö Warum neue Unterklassen? Weil die Adaptee-Hierarchie
Adaptee Hierarchie nicht veränderbar ist!
Problem: Redundanz!
Ö Was konzeptionell nur ein mal in Adapter stehen sollte wird in jeder neuen
U t kl
Unterklasse
von Adaptee
Ad t redundant
d d t eingefügt
i
fü t Æ Wartungsprobleme!
W t
bl
!
© 2000-2008 Dr. G. Kniesel
Seite 6-77
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()
f()
f()
Adaptee_N
…
<<implementation
p
inheritance>>
Adapter
request()
f()
:Client
…
anAdaptedAdaptee:Adapter
request()
other()
f()
Class Adapter Idiom: Konsequenzen
Client
Target
Adaptee
request()
other()
()
f()
f()
Adaptee_N
…
<<implementation inheritance>>
Adapter
request()
f()
:Client
…
anAdaptedAdaptee:Adapter
z O
Overriding des 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
© 2000-2008 Dr. G. Kniesel
Seite 6-79
ROOTS
Adapter Pattern: Konsequenzen
z Class Adapter
Client
adaptiert nur eine Klasse
... nicht ihre Unterklassen
Overriding des Adaptee-Verhaltens leicht möglich
keine zusätzliche
ä
Indirektion (nur
(
ein Objekt)
O
)
z Object
j
Adapter
adaptiert eine ganze Klassenhierarchie
Overriding schwieriger
:Client
Target
g
request()
Adapter
request()
q
()
Adaptee
f()
m()
Adapt_N
f()
m()
:Adapter
:Adaptee
Ö redefiniertes Verhalten in spezifische Unterklasse des Adaptees einfügen
Ö 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
O erriding des Adaptee-Verhaltens
Adaptee Verhaltens leicht möglich
© 2000-2008 Dr. G. Kniesel
Seite 6-80
ROOTS
Adapter Pattern: Pluggable Adapters
z Motivation
TreeDisplay
T Di l sollll beliebige
b li bi Baumstrukturen
B
t kt
darstellen
d t ll
Beispiel: Datei-Hierarchie, Vererbungs-Hierarchie
z Idee
Schnittstellen-Anpassbarkeit in TreeDisplay "einbauen"
Minimales Interface
f
identifizieren
f
das TreeDisplay von den angezeigten
Entities kennen muss
Adaptierbarkeit dieses Interface an verschiedene Hierarchien vorsehen
z Implementierungsvarianten
Vererbung
Vererb ng
Simulierte Delegation
Parametrisierung mit "Blöcken"
© 2000-2008 Dr. G. Kniesel
Seite 6-85
ROOTS
a) Pluggable Adapter mit Vererbung und Abstrakten
Operationen
<<Client, Target>>
TreeDisplay
getChildren (Node)
createGraphicNode(Node)
display()
buildTree ((Node n))
z Anpassungs-Interface ist Teil des TreeDisplay
Abstrakte
Ab t kt M
Methoden
th d
z Adapter sind Unterklassen von TreeDisplay
<<Adapter>>
DirectoryTreeDisplay
<<Adaptee>>
FileSystemEntity
getChildren (Node)
createGraphicNode(Node)
getChildren(n)
for each child {
addGraphicNode(
createGraphicNode(child))
buildTree(child)
}
Was, wenn ich
die Art der
Anzeige zur
La f eit ändern
Laufzeit
will?
b) Pluggable Adapter mit „Delegate
Objects
Objects“
<<Client>>
delegate
TreeDisplay
<<Target>>
TreeAccessorDelegate
setDelegate(Delegate)
display()
buildTree (Node n)
getChildren (TreeDisplay, Node)
createGraphicNode(TreeDisplay, Node)
<<Adapter>>
backreference
DirectoryBrowser
<<Adaptee>>
FileSystemEntity
getChildren (TreeDisplay, Node)
createGraphicNode(TreeDisplay, Node)
createFile()
()
deleteFile()
z
delegate.getChildren(this,n)
for each child {
addGraphicNode(
d l
delegate.createGraphicNode(this,child))
t
t G
hi N d (thi
hild))
buildTree(child)
}
Eigenes Anpassungs
Anpassungs-Interface
Interface
Abstrakte Methoden
z
z
Adapter implementieren Interface
Adapter muessen an TreeDisplay
rückfragen können, um dessen
Operationen zu nutzen
c) Pluggable Adapter Idiom in Smalltalk
und Java
Smalltalk
Pseudo-Java
ValueModel
ValueModel
value:
value
setValue()
getValue()
adaptee
adaptee
PluggableAdaptor
Objekt
PluggableAdaptor
getBlock
setBlock
getBlock
setBlock
value:
value
setValue(Oject val)
getValue()
Objekt
GetBlock
getValue(Obj)
SetBlock
setValue(Obj,Val)
^getBlock value: adaptee
return getBlock.getValue(adaptee)
Blöcke in Smalltalk und Java
z Smalltalk
Blöcke
Blö k sind
i d Obj
Objekte
kt di
die auff di
die N
Nachricht
h i ht „value“
l “ reagieren
i
Ö Analog zu einem „Command“-Objekt das auf „run“ reagiert
Blöcke können auf den Kontext zugreifen, in dem Sie definiert wurden!
Ö können z.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).
© 2000-2008 Dr. G. Kniesel
Seite 6-89
ROOTS
Adapter Pattern: Pluggable Adapter
Implementierung
z Vererbung
manchmal
h l zu starr
t
z Simulierte Delegation
flexibler, da Anpassungsstrategie austauschbar
z Parametrisierung mit "Blöcken"
flexibelste Variante
leider nur Smalltalk-Idiom
„Innere Klassen“ in Java haben nicht die Ausdruckskraft von Smalltalk-
Blöcken
© 2000-2008 Dr. G. Kniesel
Seite 6-90
ROOTS
Adapter Pattern: Abgrenzung
z Bridge
z Decorator
gleiches
l i h IInterface
t f
kontrolliert Zugriff
p
g
"Implementierungs-Detail"
gleiches
l i h IInterface
t f
zusätzliche / veränderte
Funktion
"konzeptionelle Eigenschaft"
z Adapter
verschiedenes Interface
ähnlich Protection-Adapter
© 2000-2008 Dr. G. Kniesel
Seite 6-91
ROOTS
Kapitel
t u s uste
ROOTS
Das Bridge Pattern
Bridge Pattern (auch: Handle / Body)
z Absicht
Schnittstelle
S h itt t ll und
d Implementierung
I l
ti
trennen
t
... 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:
–
–
–
–
–
© 2000-2008 Dr. G. Kniesel
X-Windows,
X
Wi d
IBM Presentation Manager,
MacOS,
Windows XYZ,,
...
Seite 6-93
ROOTS
Bridge Pattern: Warum nicht einfach Vererbung
einsetzen?
Neue Fenster-Art:
"iconifizierbare" Fenster
Window
XWindow
PMWindow
Window
XWindow
z Probleme dieses Lösungsversuchs
PMWindow
IconWindow
XIconWindow
PMIconWindow
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
© 2000-2008 Dr. G. Kniesel
Seite 6-94
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()
IconWindow
TransientWindow
XWindowImp
PMWindowImp
drawBorder()
drawCloseBox()
devDrawText()
devDrawLine()
devDrawLine()
devDrawText()
XDrawLine()
XDrawString()
drawRect()
drawText()
© 2000-2008 Dr. G. Kniesel
drawRect()
Seite 6-95
ROOTS
Bridge Pattern: Schema
Client
Abstraction
imp
Implementor
operation()
basicOperation()
imp.basicOperation()
RefinedAbstraction
© 2000-2008 Dr. G. Kniesel
ConcreteImplementorA
ConcreteImplementorB
basicOperation()
basicOperation()
Seite 6-96
ROOTS
Bridge Pattern: Anwendbarkeit
z Dynamische Änderbarkeit
Implementierung
I l
ti
erstt zur Laufzeit
L f it auswählen
ähl
z Unabhängige Variabilität
neue Unterklassen in beiden Hierarchien beliebig kombinierbar
z Implementierungs-Transparenz für Clients
Änderungen der Implementierung erfordern keine Änderung /
N üb
Neuübersetzung
t
d
der Cli
Clients
t
z Vermeidung von "Nested Generalisations"
keine Hierarchien der Art wie in der Motivations-Folie
Motivations Folie gezeigt
keine kombinatorische Explosion der Klassenanzahl
z Sharing
mehrere Clients nutzen gleiche Implementierung
z.B. Strings
© 2000-2008 Dr. G. Kniesel
Seite 6-98
ROOTS
Bridge Pattern: Implementierung
Client
Abstraction
Implementor
imp
...
Instantiierung des richtigen ConcreteImplementors
z Falls Abstraction alle ConcreteImplementor-Klassen kennt:
Fallunterscheidung
a u te sc e du g im Konstruktor
o st u to de
der Co
ConcreteAbstraction
c ete bst act o
Auswahl des ConcreteImplementor anhand von Parametern des
Konstruktors
Alternativ: Default-Initialisierung
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
© 2000-2008 Dr. G. Kniesel
Seite 6-99
ROOTS
Bridge Pattern: Abgrenzung
z Bridge
z Adapter
antizipierte
ti i i t E
Entkopplung
tk
l
von
Schnittstelle und
Implementierung
nachträgliche
ht ä li h A
Anpassung d
der
Schnittstelle einer
Implementierung
z Abstract Factory
nutzbar zur Erzeugung und
Konfiguration einer Bridge
© 2000-2008 Dr. G. Kniesel
Seite 6-100
ROOTS
Kapitel
t u s uste
ROOTS
Wichtige Design Patterns
Patterns, Teil 2
- Object Design Patterns -
Command, Factory Method, Abstract Factory, Composite, Visitor
„„Patterns Create Architectures“
Rückblick: „Was nutzen Patterns?“
Das Command Pattern: Motivation
z Kontext
GUI-Toolkits
GUI T lkit mit
it
Buttons, Menüs, etc.
z Forces
Vielfalt trotz Einheitlichkeit
Ö Einheitlicher Code in allen GUI-Elementen
Ö .. trotzdem verschiedene Effekte
Wiederverwendung
Ö Über verschiedene GUI-Elemente ansprechbare Operationen nur ein mal
programmieren
Dynamik
Ö dynamische Änderung der Aktionen von Menu-Einträgen
Ö kontext-sensitive Aktionen
© 2000-2008 Dr. G. Kniesel
Seite 6-102
ROOTS
Das Command Pattern: Idee
z Operationen als Objekte mit Methode execute() darstellen
z in
i d
den GUI
GUI-Elementen
El
t speichern
i h
Application
Menu
MenuItem
add(Document)
add(Menuitem)
clicked()
Command
execute()
Document
open()
close()
cut()
copy()
paste()
Einheitlicher Aufruf
Command -> execute
document
Verschiedene
Implementierungen
p
g
PasteCommand
execute()
t ()
Document -> Paste
© 2000-2008 Dr. G. Kniesel
Seite 6-104
ROOTS
Das Command Pattern: Rollen und ihre
Verantwortlichkeiten
z Command Interface
Schnittstelle,
S h itt t ll die
di festlegt,
f tl t was Commands
C
d tun
t können
kö
Mindestens Execute (s.u.), optional auch Undo, Redo (s.u.)
z Execute-Method
Methode, die das Ausführen von Kommandos ermöglicht
z Undo-Method
Methode, die das Rückgängig machen von Kommandos ermöglicht
z Redo
Redo-Method
Method
Methode, die ein rückgängig gemachtes Kommando wieder ausführt
z Concrete Command
Implementiert Command Interface
„Controllers
Controllers“ sind oft als „Commands
Commands“ implementiert
© 2000-2008 Dr. G. Kniesel
Seite 6-106
ROOTS
Das Command Pattern: Anwendbarkeit
z Operationen als Parameter
z Variable Aktionen
referenziertes Command-Objekt austauschen
z Zeitliche Trennung
Befehl zur Ausführung, Protokollierung, Ausführung
z Speicherung und Protokollierung von Operationen
History
History-Liste
Liste
Serialisierung
z "Undo" von Operationen
Command-Objekte
C
O
enthalten neben execute()
() auch unexecute()
()
werden in einer History-Liste gespeichert
z Recover-Funktion nach Systemabstürzen
History-Liste wird gespeichert
Zustand eines Systems ab letzter Speicherung wiederstellbar
z Unterstützung von Transaktionen
Transaktionen können sowohl einfache ("primitive"), als auch komplexe CommandObjekte sein.
Implementierung des Command Patterns
z Unterschiedliche Grade von Intelligenz
Command
Command-Objekte
Objekte können "nur"
nur Verbindung zwischen Sender und Empfänger sein
sein,
oder aber alles selbstständig erledigen.
z Unterstützung von "undo"
Semantik
S
tik
Ö
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
werden.
Ö
Typischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werden
sollen.
History
History-Liste
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 "tief" Clonen, um sicherzustellen dass sein Zustand nicht verändert
wird.
Das Command Pattern: Konsequenzen
z Entkopplung
von Aufruf
A f f einer
i
Operation
O
ti und
d Spezifikation
S
ifik ti einer
i
O
Operation.
ti
z Kommandos als Objekte
Command
Command-Objekte
Objekte können wie andere Objekte auch manipuliert und
erweitert werden.
z Komposition
Folgen
F l
von Command-Objekte
C
d Obj kt kö
können zu weiteren
it
C
Command-Objekten
d Obj kt
zusammengefasst werden.
z Erweiterbarkeit
Neue Command-Objekte können leicht hinzugefügt werden, da keine
Klassen geändert werden müssen.
© 2000-2008 Dr. G. Kniesel
Seite 6-109
ROOTS
Patterns-Überblick
Verhalten
Struktur
z Visitor
z Composite
z Observer
z Flyweight
z Command
z Template Method
z Decorator
z State
z Adapter
z Strategy
z Proxy
z Multiple Vererbung
z Bridge
z Facade
Split Objects
z Factory Method
z Prototype
yp
z Abstract Factory
z Singleton
z Builder
Objekt-Erzeugung
Kapitel
t u s uste
Das Command und Observer Pattern
in Java
ROOTS
Verbindung von Observer und Command
in Java (1)
<<interface>>
ActionListener
void actionPerfomed(ActionEvent evt)
<<implements>>
MyPasteCommand
:MenuItem
:Button
← addActionListener(ActionListener)
:JComponent
z
→ actionPerformed(ActionEvent)
: MyPasteCommand
← registerKeyboardAction(ActionListener, KeyStroke, ...)
Observer
Buttons, Menue-Einträge und Tasten
generieren "ActionEvents"
Interface "ActionListener" ist vordefiniert
Î "ActionListener"
ActionListener implementieren
Î ... und Instanzen davon bei Buttons,
MenuItems, etc registrieren
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
Verbindung von Observer und Command
in Java (2)
z Zusätzliche Unterstützung für
<<interface>>
ActionListener
"Command"
Command
Aktivierung
Akti
i
/
Deaktivierung
von
MenuItems
d
denen
di
diese
"Action"
zugeordnet
ist
... Parameter
können
allerdings
ll di
auch direkt als
InstanzVariablen
realisiert
werden.
<<extends>>
<<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)
<<implements>>
AbstractAction
// alles ausser void actionPerfomed(ActionEvent evt)
<<extends>>
MyPasteCommand
im
m JDK enthalten
Interface "Action" und Klasse
"AbstractAction"
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();
i ()
}
p
private
ate Co
Component
po e t ta
target;
get;
private Color color;
}
z ColorAction
class ActionButton extends JButton
{ public ActionButton(Action a)
{ ...
addActionListener(a);
}
}
Ändern der Hintergrundfarbe einer GUI-Komponente
z ActionButton
Buttons die sofort bei Erzeugung mit einer Action verknüpft werden
Beispiel: Änderung der Hintergrundfarbe
(2)
z Nutzung der ColorAction
Erzeugung
E
einer
i
IInstanz
t
Registrierung
class SeparateGUIFrame extends JFrame
{ public SeparateGUIFrame()
{ ...
JPanel panel = new JPanel();
Action blueAction = new ColorAction("Blue", ...,..., panel);
panel registerKeyboardAction(blueAction
panel.registerKeyboardAction(blueAction,...);
);
panel.add(new ActionButton(blueAction));
JMenu menu = new JMenu("Color");
menu.add(blueAction);
...
}
}
Beispiel und Erläuterung siehe: "Core Java 2", Kapitel 8,
Abschnitt "Separating GUI and Application Code".
Fazit
9 Elegante Verbindung von Observer und Command
Commands
C
d sind
i d ActionListener
A ti Li t
von Buttons,
B tt
Menus,
M
etc.
t
Ö 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
k
i t t für
fü alle
ll b
betroffenen
t ff
M
MenuItems,
It
B tt
Buttons,
etc.???
t ???
Î Strategy
gy Pattern!
© 2000-2008 Dr. G. Kniesel
Seite 6-117
ROOTS
Klassifikation
Verhalten
z Visitor
Struktur
z Composite
z Observer
z Flyweight
z Command
z Template Method
z Decorator
z State
z Proxy
z Strategy
z Adapter
z Bridge
z Facade
Jetzt
Split Objects
z Factory Method
z Prototype
yp
z Abstract Factory
z Singleton
z Builder
Objekt-Erzeugung
Kapitel
t u s uste
Das Factory Method Pattern
ROOTS
Factory Method
z Ziel
Entscheidung
E t h id
über
üb konkreter
k k t Klasse
Kl
neuer Objekte
Obj kt verzögern
ö
z Motivation
Framework mit vordefinierten Klassen "Document" und "Application"
Template-Methode, für das Öffnen eines Dokuments:
Ö 1.
1 Ch
Check
k ob
bD
Dokument-Art
k
t A t bekannt
b k
t
Ö 2. Erzeugung einer Document-Instanz !?!
Erzeugung von Instanzen noch nicht bekannter Klassen!
z Idee
aktuelle
kt ll Kl
Klasse entscheidet
t h id t wann Obj
Objekte
kt erzeugtt werden
d
Ö Aufruf einer abstrakten Methode
Subklasse entscheidet was für Objekte erzeugt werden
Ö implementiert abstrakte Methode passend
© 2000-2008 Dr. G. Kniesel
Seite 6-120
ROOTS
Factory Method: Beispiel
Framework
Document
*
docs
Application
newDocument()
D
t()
doCreateDocument()
MyDocument
Document doc = doCreateDocument();
docs.add(doc);
doc.open();
MyApplication
doCreateDocument()
Applikation
return new MyDocument()
Factory Method: Schema
Creator
Product
anOperation()
factoryMethod()
ConcreteProduct
...
product = factoryMethod();
...
ConcreteCreator
factoryMethod()
return new ConcreteProduct()
z Factory Method
kann abstrakt sein
kann Default-Implementierung haben
z Creator
C t (Aufrufer
(A f f der
d Factory
F t
M th d)
Method)
kann Klasse sein, die die Factory Method definiert
kann Client-Klasse sein
Ö Beispiel: parallele Vererbungs-Hierarchien
© 2000-2008 Dr. G. Kniesel
Seite 6-122
ROOTS
Factory Method: Anwendbarkeit
z Klasse neuer Objekte unbekannt
z Verzögerte Entscheidung über Instantiierung
erst in Subklasse
erst beim Client
z Mehrere
M h
Hilf
Hilfsklassen
kl
Wissen über konkrete Hilfsklassen an einer Stelle lokalisieren
Beispiel:
p
Parallele Hierarchien ((nächste Folie))
© 2000-2008 Dr. G. Kniesel
Seite 6-123
ROOTS
Factory Method: Anwendbarkeit
Figure
Client
Manipulator
createManipulator()
...
downClick()
drag()
upClick()
Li Fi
LineFigure
T tFi
TextFigure
createManipulator()
...
createManipulator()
...
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 Code der Figure
Figure-Hierarchie
Hierarchie und Client-Code
Client Code ist völlig
unabhängig von spezifischen Manipulators (nur vom Manipulator-Interface)
© 2000-2008 Dr. G. Kniesel
Seite 6-124
ROOTS
Factory Method: Implementierung
z Fester "Produkt-Typ"
jede
j d U
Unterklasse
t kl
erzeugtt
festgelegte Produkt-Art
z Codierter "Produkt-Typ"
Produkt Typ
Parameter oder Objekt-Variable
kodiert "Produkt-Typ"
Fallunterscheidung
g anhand
Code
Î mehrere Produkte
Î mehr Flexibilität
z Klassen-Objekt als "Produkt-Typ"
Parameter oder Objekt-Variable
ist "Produkt
Produkt-Typ
Typ"
direkte Instantiierung
Î mehr Flexibilität
Î bessere Wartbarkeit
Î kein statischer Typ-Check
© 2000-2008 Dr. G. Kniesel
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
S ll lk
• Java
class Creator {
Object create(Class prodType) {
return prodType.getInstance();
}
}
Reflektiver Aufruf des parameterelosen
Default Konstruktors
Default-Konstruktors
Seite 6-125
ROOTS
Factory Method: Konsequenzen
z Code wird abstrakter / wiederverwendbarer
keine
k i ffesten
t Abhängigkeiten
Abhä i k it von spezifischen
ifi h Kl
Klassen
z Verbindung
gp
paralleler Klassenhierarchien
Factory Method lokalisiert das Wissen über Zusammengehörigkeiten
z evtl. künstliche Subklassen
nur zwecks Objekterzeugung
© 2000-2008 Dr. G. Kniesel
Seite 6-126
ROOTS
Factory Method: Anwendungen
z überall in Toolkits, Frameworks, Class Libraries
Unidraw:
U id
B
Beispiel
i i l "Fi
"Figure und
dM
Manipulator"
i l t "
MacApp und ET++: Beispiel "Document und Application"
z Smalltalk's Model-View-Controller Framework
FactoryMethoden-Template: defaultController
Hook-Methode:
H k M th d defaultControllerClass
z Orbix
Erzeugung des richtigen Proxy
Ö leichte Ersetzung von Standard-Proxy durch Caching Proxy
© 2000-2008 Dr. G. Kniesel
Seite 6-127
ROOTS
Factory Method: Abgrenzung
z Template Method
ruft
ft oft
ft Factory
F t
Method
M th d auff
z Abstract Factory
y
oft mit Factory Methods implementiert
gleiche Motivation
z Prototype
erfordert keine Unterklassenbildung
... dafür aber explizite initialize()-Methode
© 2000-2008 Dr. G. Kniesel
Seite 6-128
ROOTS
Kapitel
t u s uste
Das Abstract Factory Pattern
ROOTS
Abstract Factory
z Ziel
zusammengehörige
hö i Obj
Objekte
kt verwandter
dt T
Typen erzeugen
... ohne deren Klassenzugehörigkeit fest zu codieren
z Motivation
GUI-Toolkit für mehrere Plattformen
Anwendungsklassen nicht von plattformspezifischen Widgets abhängig
machen
Trotzdem soll die Anwendung
g
Ö alle Widgets konsistent zu einem "look and feel" erzeugen können
Ö "look and feel" umschalten können
© 2000-2008 Dr. G. Kniesel
Seite 6-130
ROOTS
Abstract Factory: Beispiel
WidgetFactory
Client
createWindow()
createScrollBar()
Wi d
Window
MotifWidgetFactory
createWindow()
createScrollBar()
PMWidgetFactory
PMWindow
MotifWindow
createWindow()
createScrollBar()
Scrollbar
PMScrollbar
© 2000-2008 Dr. G. Kniesel
MotifScrollBar
Seite 6-131
ROOTS
Abstract Factory: Schema
AbstractFactory
Client
createProductA()
createProductB()
AbstractProductA
ConreteFactory1
createProductA()
()
createProductB()
ConreteFactory2
ProductA2
ProductA1
createProductA()
()
createProductB()
AbstractProductB
ProductB2
© 2000-2008 Dr. G. Kniesel
ProductB1
Seite 6-132
ROOTS
Abstract Factory: Implementierung
z ConcreteFactories sind Singletons
z Produkt-Erzeugung
Produkt Erzeugung via Factory
Factory-Methods
Methods
z fester Produkt-Typ (eine Methode für jedes Produkt)
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 als "Produkt-Typ" (eine parametrisierte Methode)
Vorteil
Ö neues Produkt
P d kt erfordert
f d t keinerlei
k i l i Änderungen
Ä d
der
d Factory
F t
Nachteil
Ö Verzicht auf jegliche statische Typinformation / Typsicherheit
Abstract Factory: Implementierung
z Produktfamilie = Subklasse
Vorteil
V t il
Ö Konsistenz der Produkte
Nachteil
Ö neue Produktfamilie erfordert neue Subklasse, auch bei geringen
Unterschieden
z Produktfamilie = von Clients konfigurierte assoziative Datenstruktur
Varianten
Ö Prototypen
P t t
und
d Cloning
Cl i
Ö Klassen und Instantiierung
Vorteil
Ö keine Subklassenbildung erforderlich
Nachteil
Ö Verantwortlichkeit an Clients abgegeben
g g
Ö konsistente Produktfamilien können nicht mehr garantiert werden
© 2000-2008 Dr. G. Kniesel
Seite 6-134
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 einer ConcreteFactory erscheint nur ein mal im Code
Ö bei ihrer Instantiierung
Leicht austauschbar gegen andere ConcreteFactory
Beispiel: Dynamisches Ändern des look-and-feel
Ö andere
d
C
ConcreteFactory
t F t
i t tii
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
Abstract Factory: Anwendbarkeit
z System soll unabhängig sein von
Objekt-Erzeugung
Obj kt E
Objekt-Komposition
Objekt-Darstellung
j
g
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
Teilprodukt Arten / -Implementierungen
Implementierungen
© 2000-2008 Dr. G. Kniesel
Seite 6-136
ROOTS
Klassifikation
Jetzt
Verhalten
z Visitor
Struktur
z Composite
z Observer
z Flyweight
z Command
z Template Method
z Decorator
z State
z Proxy
z Strategy
z Adapter
z Bridge
z Facade
Split Objects
z Factory Method
z Prototype
yp
z Abstract Factory
z Singleton
z Builder
Objekt-Erzeugung
Kapitel
t u s uste
ROOTS
Das Composite Pattern
Composite Pattern
z Ziel
rekursive
k i A
Aggregations-Strukturen
ti
St kt
darstellen
d t ll ("i
("istt Teil
T il von")
")
Aggregat und Teile einheitlich behandeln
z Motivation
Gruppierung von Graphiken
© 2000-2008 Dr. G. Kniesel
Seite 6-139
ROOTS
Composite Pattern: Beispiel
Graphic
draw()
add(Graphic)
remove(Graphic)
getChildren()
children
Line
Text
Picture
draw()
draw()
draw()
add(Graphic)
remove(Graphic)
getChildren()
:Line
:Text
:Text
:Picture
© 2000-2008 Dr. G. Kniesel
draw() {
for all c in children
c.draw()
}
:Picture
Seite 6-140
ROOTS
Composite Pattern: Struktur
*
Client
Component
operation()
add(Component)
remove(Component)
getChildren()
children
Leaf
Composite
operation()
add(Component)
remove(Component)
getChildren()
operation()
add(Component)
remove(Component)
getChildren()
operation() {
c.operation()
}
add() {}
oder
add() {throw new MessageNotSupportedException()}
© 2000-2008 Dr. G. Kniesel
Seite 6-141
ROOTS
Composite Pattern: Verantwortlichkeiten
*
Component
z Component (Graphic)
operation()
add(Component)
remove(Component)
getChildren()
gemeinsames
i
IInterface
t f
aller
ll Teilobjekte
T il bj kt
default-Verhalten
children
Interface für Zugriff
g auf Teilobjekte
j
((!))
evtl. Interface für Zugriff auf Elternobjekte
z Leaf
L f (Rectangle,
(R t
l Line,
Li
T
Text)
t)
Leaf
Composite
"primitive" Teil-Objekte
operation()
operation()
add(Component)
remove(Component)
getChildren()
implementieren
p
g
gemeinsames Interface
leere Implementierungen für Teilzugriffs-Interface
z Composite
C
it (Pi
(Picture)
t )
speichert Teilobjekte
implementiert gemeinsames Interface durch forwarding
implementiert Teilzugriffs-Interface
© 2000-2008 Dr. G. Kniesel
Seite 6-142
ROOTS
Composite Pattern: Implementierung
z Wenn Composites wissen sollen wovon sie Teil sind
*
Component
operation()
add(Component)
remove(Component)
getChildren()
Explizite Referenzen auf Composite in
Component Klasse
children
1
gemeinsam nutzen sollen
Schließt explizite Referenz der Components
pare
ent
z Wenn mehrere Composites Components
Leaf
Composite
operation()
operation()
add(Component)
remove(Component)
getChildren()
auf Composite aus oder erfordert,
erfordert dass Components
wissen, dass sie Teile mehrerer Composites sind
z Component
p
Interface
"Sauberes Design": Verwaltungs-Operationen (add, remove) in Composite,
da sie für Leafs nicht anwendbar sind.
Wunsch nach einheitlicher Behandlung aller Graphic-Objekte
Graphic Objekte durch Clients
Æ Verwaltungs-Operationen in Component mit default-Implementierung
die nichts tut
Æ Leaf
Leaf-Klassen
Klassen sind damit zufrieden
zufrieden, Composites müssen die
Operationen passend implementieren.
© 2000-2008 Dr. G. Kniesel
Seite 6-143
ROOTS
Composite Pattern: Alternative Struktur
(add / remove nicht in „Component
Component“)
)
*
Client
Component
children
operation()
getChildren()
Leaf
Composite
operation()
getChildren()
operation()
add(Component)
remove(Component)
(C
t)
getChildren()
operation() {
c.operation()
}
Component getChildren() {
return null
}
© 2000-2008 Dr. G. Kniesel
Seite 6-144
ROOTS
Composite Pattern: Konsequenzen
z Einheitliche Behandlung
Teile
T il
Ganzes
z Einfache
Ei f h Cli
Clients
t
Dynamisches Binden statt Fallunterscheidungen
z Leichte
L i ht Erweiterbarkeit
E
it b k it
neue Leaf-Klassen
neue Composite-Klassen
p
ohne Client-Änderung
z Evtl. zu allgemein
g
Einschränkung der Komponenten-Typen schwer
„run-time type checks“ (instanceof)
© 2000-2008 Dr. G. Kniesel
Seite 6-145
ROOTS
Kapitel
t u s uste
ROOTS
Das Visitor Pattern
Das Visitor Pattern
z Absicht
Repräsentation
R ä
t ti von O
Operationen
ti
auff Elementen
El
t einer
i
Objektstruktur
Obj kt t kt
Neue Operationen definieren, ohne dass die Klassen dieser Objekte zu
ändern
© 2000-2008 Dr. G. Kniesel
Seite 6-147
ROOTS
Das Visitor-Pattern: Motivation
z Beispiel
Compiler für eine gegebene Programmiersprache enthalten Klassen für
verschiedene Ausdrücke in dieser Sprache.
z Problem
Zusammengehöriger Code ist über alle Klassen verteilt
Es ist schwer, ein neue Facette der Sprache zu implementieren
Ö jjede
d Kl
Klasse d
der Obj
Objektstruktur
kt t kt müsste
ü t geändert
ä d t werden
d ((zB,
B um die
di
Typüberprüfung anzupassen)
© 2000-2008 Dr. G. Kniesel
Seite 6-148
ROOTS
Das Visitor-Pattern: Idee
z Ziel
Neue Operationen auf Objekten
sollen definiert werden, ...
... ohne dass die Klassen dieser
Objekte geändert werden
müssen!
z Idee
Zusammenfassung dieses
Codes in Visitor-Objekte...
... und Bereitstellung von
"akzeptierenden"
akzeptierenden Methoden in
der betroffenen
Klassenhierarchie.
© 2000-2008 Dr. G. Kniesel
Seite 6-149
ROOTS
Das Visitor Pattern: Schema
Client
Visitor
visitConcreteElementA(ConcreteElementA)
visitConcreteElementB(ConcreteElementB)
ConcreteVisitor1
ConcreteVisitor2
ObjectStructure
*
Element
accept(Visitor)
ConcreteElementA
accept(Visitor v)
operationA()
v visitConcreteElementA(this)
v.visitConcreteElementA(this)
© 2000-2008 Dr. G. Kniesel
ConcreteElementB
accept(Visitor v)
operationB()
v visitConcreteElementB(this)
v.visitConcreteElementB(this)
Seite 6-153
ROOTS
Visitor Pattern: Verantwortlichkeiten /
Implementation
z Objektstruktur-Hierarchie
Einheitliche accept
accept-Methode
Methode
z Visitor-Hierarchie
Je eine visit
visit-Methode
Methode für jede Klasse der Objektstruktur
z Accept-Methoden
Haben Visitor als Parameter
"Welche Operation soll auf mir ausgeführt werden?"
z Visit-Methoden
Visit 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 (Methode accept(...)) oder
Im Visitor
Visitor-Objekt
Objekt (Method visit...(...))
visit ( ))
© 2000-2008 Dr. G. Kniesel
Seite 6-154
ROOTS
Das Visitor-Pattern: Zusammenarbeit
welche
Operation
p
auf
welchem
j
Objekt
... ist wie
implementiert
p
accept(aVisitor)
t( Vi it )
© 2000-2008 Dr. G. Kniesel
Seite 6-155
ROOTS
welche
Operation
p
auf
welchem
j
Objekt
... ist wie
implementiert
p
accept(aVisitor)
t( Vi it )
Æ
© 2000-2008 Dr. G. Kniesel
Æ
Double dispatch
p
Seite 6-156
ROOTS
welche Operation
:anObjectStructure
accept(aVisitor)
auf welchem Objekt
... ist wie implementiert
:aConcreteElementA :aConcreteElementB
:aConcreteVisitor
accept(aVisitor)
visitConcreteElementA(aConcreteElementA)
operationA()
accept(aVisitor)
visitConcreteElementB(aConcreteElementB)
operationB
ti B()
Æ Double dispatch Æ
© 2000-2008 Dr. G. Kniesel
Seite 6-157
ROOTS
Das Visitor-Pattern: Konsequenzen
z Hinzufügen neuer Operationen ist einfach.
Neue Visitor-Klasse
Visitor Klasse
z Hinzufügen neuer Objektklassen ist sehr aufwendig.
Neue Objekt-Klasse
Neue visit... - Methode in allen Visitors
z Sammeln von Zuständen
Visitor-Objekte können Zustände der besuchten Objekte aufsammeln und (evtl.
p
) auswerten.
später)
Eine Übergabe von zusätzlichen Parametern ist dafür nicht nötig.
z Verletzung von Kapselung
Die Schnittstellen der Klassen der Objektstruktur müssen ausreichend
Funktionalität bieten, damit Visitor-Objekte ihre Aufgaben erledigen können.
Oft muss mehr preisgegeben werden als (ohne Visitor) nötig wäre
wäre.
© 2000-2008 Dr. G. Kniesel
Seite 6-158
ROOTS
Das Visitor Pattern: Anwendbarkeit
z Funktionale Dekomposition
Zusammengehörige
Z
hö i O
Operationen
ti
sollen
ll zusammengefasst
f
t werden
d
... statt in einer Klassenhierarchie verteilt zu sein
j
z Stabile Objekt-Hierarchie
selten neue Klassen
aber oft neue Operationen
z Heterogene Hierarchie
viele Klassen mit unterschiedlichen Schnittstellen
Operationen die von den Klassen abhängen
z Anwendungsbeispiel
Java-Compiler des JDK 1.3
© 2000-2008 Dr. G. Kniesel
Seite 6-159
ROOTS
Das Visitor-Pattern: Implementierung
z Abstrakter Visitor
Jede Objektstruktur besitzt eine (abstrakte) Visitor-Klasse.
Für jeden Typ T in der Objektstruktur, enthält die Visitor-Klasse je eine
Methode mit einem Parameter vom Typ
yp T Æ visitT(T)
( )
z Konkrete Visitors
Jede Unterklasse der Visitor-Klasse redefinieren die visit-Methoden, um
ihre jeweilige Funktionalität zu realisieren.
Jede konkrete visitT(T) Methode benutzt dabei die spezifischen
Operationen des besuchten Objekttyps T
z Traversierung der Objektstruktur
kann in der Objektstruktur (accept(...) Methoden) definiert sein
... oder im Visitor-Objekt (visit...(...) Methoden).
© 2000-2008 Dr. G. Kniesel
Seite 6-160
ROOTS
Überblick
z Einführung
Grundidee,
G did
Lit
Literatur,
t MVC-Framework
MVC F
k als
l B
Beispiel
i i l
z Beispiele wichtiger Patterns
Observer, Strategy, Command
Bridge, Factory Method, Abstract Factory
z Patterns Create Architectures
Bridge, Abstract Factory, Singleton
z Nutzen von Patterns
z Zusammenfassung und Ausblick
Bestandteile eines Patterns, Definition
Arten von Patterns, Abgrenzung
Weiterführende Themen
© 2000-2008 Dr. G. Kniesel
Seite 6-161
ROOTS
Kapitel
t u s uste
ROOTS
„Patterns Create Architectures“
Ein Beispiel zum Zusammenspiel von
Patterns
Bridge & Abstract Factory & Singleton
„Patterns Create Architectures“
z Idee
Wenn
W
man Patterns
P tt
wohlüberlegt
hlüb l t zusammen verwendet,
d t entsteht
t t ht ein
i
Grossteil einer Software-Architektur aus dem Zusammenspiel der Patterns.
z Beispiel
Zusammenspiel von Bridge, Factory und Singleton
© 2000-2008 Dr. G. Kniesel
Seite 6-163
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 Bridgeg
Pattern angewendet
werden
PMScrollbar
MotifScrollBar
Erinnerung ans Bridge Pattern
z Trennung von
Konzeptueller
K
t ll Hi
Hierarchie
hi
ImplementierungsHierarchie
Client
Window
imp
WindowImp
drawText()
drawRect()
devDrawText()
devDrawLine()
IconWindow
TransientWindow
PMWindowImp
XWindowImp
drawBorder()
drawCloseBox()
devDrawText()
devDrawLine()
devDrawLine()
devDrawText()
© 2000-2008 Dr. G. Kniesel
Seite 6-165
ROOTS
Zusammenspiel: Bridge, Factory,
Singleton
<< konfiguriert >>
Client
WidgetFactory
Singleton
WidgetFactory.setFactory(WidgetFactory.MOTIF)
WidgetFactory.getFactory()
PMWidgetFactory
createWindow()
createScrollBar()
<< benutzt >>
Window
IconWIndow
TransientWindow
Scrollbar
FixedSB
imp
imp
ProportionalSB
MotifWidgetFactory
WindowImp
PMWindow
MotifWindow
ScrollbarImp
PMScrollbar
MotifScrollBar
Kapitel
t u s uste
Rückblick: Was nützen Patterns?
ROOTS
Nutzen von Design Patterns (1)
z Objekte / Klassen identifizieren
Abstraktionen,
Ab t kti
die
di kein
k i Gegenstück
G
tü k in
i der
d realen
l Welt
W lt / d
dem A
Analysel
Modell haben
Beispiel:
Ö Composite Pattern
Ö Abstraktionen von Prozessen
Ö Strategy
Ö State
"Strict modelling of the real world leads to a system that reflects
t d ' realities
today's
liti but
b t nott necesarilly
ill tomorrow's.
t
' The
Th abstractions
b t
ti
th t
that
emerge during design are key to making a design flexible."
© 2000-2008 Dr. G. Kniesel
Seite 6-168
ROOTS
z Granularität der Objekte festlegen
Facade
F
d

Ö ein "Riesen-Objekt"
Flyweight
y
g
Ö viele kleine, gemeinsam verwendbare Teilobjekte
Builder
Ö Komposition
K
iti von G
Gesamt-Objekt
t Obj kt aus Teilobjekten
T il bj kt
Visitor
Ö Gruppe von konsistenten Aktionen
Command
Ö einzelne Aktion
© 2000-2008 Dr. G. Kniesel
Seite 6-169
ROOTS
z Schnittstellen identifizieren
was gehört
hö t d
dazu
was gehört nicht dazu (Bsp. Memento)
z Beziehungen zwischen Schnittstellen festlegen
Subtyping
Ö Decorator
D
t
Ö Proxy
Je eine Methode pro Klasse aus einer anderen Objekthierarchie
Ö Abstract Factory
Ö Builder
Ö Visitor
© 2000-2008 Dr. G. Kniesel
Seite 6-170
ROOTS
z Wahl der Implementierung
Interface,
I t f
Abstrakte
Ab t kt Klasse
Kl
oder
d konkrete
k k t Klasse
Kl
Ö Grundthema fast aller Patterns
Abstrakte Methode oder Hook Methode
Ö von template method aufgerufene Methoden
Overriding oder fixe Implementierung
Ö Factory method
Ö Template method
Vererbung oder Subtyp-Beziehung
Ö Ad
Adapter,
t Decorator,
D
t State,
St t Strategy,
St t
C
Command,
d Ch
Chain
i off Responsibility:
R
ibilit
Gemeinsamer Obertyp, nicht gemeinsame Implementierung
Vererbung oder Aggregation
Ö Vererbung ist statisch
Ö Es wird oft mehr vererbt als gewünscht
Ö Beispiel: alle "split object patterns"
© 2000-2008 Dr. G. Kniesel
Seite 6-171
ROOTS
Nutzen von Design Patterns (5):
z Patterns verkörpern Grundprinzipien guten Designs
z Implementierungen austauschbar machen
Typdeklarationen mit Interfaces statt mit Klassen
Design an Interfaces orientieren,
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 wiederverwendbar für neue Implementierungen des gleichen
I t f
Interface
z Funktionalität änderbar gestalten
Aggregation
A
ti und
d Forwarding
F
di statt
t tt Vererbung
V
b
späte Konfigurierbarkeit, Dynamik
weniger implizite Abhängigkeiten (kein "fragile base class problem")
© 2000-2008 Dr. G. Kniesel
Seite 6-172
ROOTS
Überblick
z Einführung
Grundidee,
G did
Lit
Literatur,
t MVC-Framework
MVC F
k als
l B
Beispiel
i i l
z Beispiele wichtiger Patterns
Observer, Strategy, Command
Facade, Singleton, Proxy, Adapter, Bridge
Factory Method, Abstract Factory
Composite,
C
Visitor
z Patterns Create Architectures
Bridge,
Bridge Abstract Factory
Factory, Singleton
z Nutzen von Patterns
z Zusammenfassung und Ausblick
Arten von Patterns, Abgrenzung
© 2000-2008 Dr. G. Kniesel
Seite 6-173
ROOTS
Arten von Design Patterns
z Analysis Pattern
wiederkehrende
i d k h d P
Problemen
bl
iin d
der A
Analysephase
l
h
eines
i
S
Softwareprojekts
ft
j kt
Martin Fowler: "Analysis Patterns", Addison-Wesley, 1997
z Architektur Pattern
... beschreibt mögliche fundamentale Strukturen von Softwaresystemen.
... enthält vordefinierte Subsysteme und ihre Verantwortlichkeiten.
... enthält Regeln und Richtlinien für
f die Organisation
O
ihrer Beziehungen.
Beispiel: Das Model-View-Controller Framework
z Design Pattern
Schema für die Realisation von Subsystemen oder Komponenten eines
Softwaresystems
z Idiom
Idi
(
(auch:
h C
Coding
di P
Pattern)
tt )
low-level design patterns für eine gegebene Programmiersprache.
Beispiel:
p
Wie stelle ich sicher,, dass eine Instanz einer Java-Klasse nur
innerhalb dieser Klasse erzeugt werden kann?
© 2000-2008 Dr. G. Kniesel
Seite 6-174
ROOTS
Weitere Arten von Pattern
z Organizational Patterns
Struktur
St kt und
d Praxis
P i von O
Organisationen;
i ti
also
l G
Gruppen, di
die ein
i
gemeinsames Ziel verfolgen
http://www.bell-labs.com/cgiuser/
OrgPatterns/OrgPatterns?OrganizationalPatterns
z Anti-Patterns
beschreiben typische Fehler
... und bestenfalls auch wie man sie wieder beseitigt
© 2000-2008 Dr. G. Kniesel
Seite 6-175
ROOTS
Abgrenzung: Pattern sind keine
Algorithmen
z Patterns versus Algorithmen
Algorithmen
Al ith
lö
lösen ffeinkörnigere
i kö i
P
Probleme
bl
als
l P
Patterns
tt
((z.B.
B S
Suchen,
h
Sortieren)
Algorithmen sind deterministischer (weniger ImplementierungsFreiheitsgrade)
Komplexität von Algorithmen lässt sich leichter fassen
© 2000-2008 Dr. G. Kniesel
Seite 6-176
ROOTS
Abgrenzung: Pattern sind keine
Frameworks
z Pattern versus Frameworks
Framework
F
k
Ö 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, wiederverwendbarer Code – Patterns
enthalten nur Beispiele von Code
Patterns sind weniger
g spezifisch
p
Ö Frameworks werden für konkrete Anwendungsbereiche eingesetzt – Patterns
können fast überall eingesetzt werden
© 2000-2008 Dr. G. Kniesel
Seite 6-177
ROOTS
z Pattern Catalogs
Sammlungen
S
l
von lose
l
zusammenhängenden
hä
d P
Patterns
tt
z Pattern Systems
y
Sammlungen von stark zusammenhängenden Patterns mit engen
Verzahnungen
z Pattern Languages
verfolgen
g ein g
gemeinsames Ziel, dass durch die Zusammenarbeit der
enthaltenen Patterns erreicht werden kann
inkl. einer Art "Grammatik", die alle mögliche Kombinationen aufzeigt
© 2000-2008 Dr. G. Kniesel
Seite 6-178
ROOTS
Pattern: Zusammenfassung
z Betonung von Praktikabilität
Patterns
P tt
sind
i d bekannte
b k
t Lösungen
Lö
fü
für erwiesenermaßen
i
ß wiederkehrende
i d k h d
Probleme
Sie sollen Softwareentwickler bei ihrer Arbeit unterstützen, nicht mehr und
nicht weniger
z "Aggressive Hintanstellung von Originalität"
Lösungen,
Lösungen die sich noch nicht in der Praxis bewährt haben
haben, sind keine
Pattern.
z Patterns sind kein Allheilmittel
Originalität bei der Anwendung von Patterns ist nach wie vor gefragt.
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
© 2000-2008 Dr. G. Kniesel
Seite 6-179
ROOTS
Kapitel
t u s uste
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 nachzuvollziehen.
Wenn nicht, schauen Sie sich die Pattern-Beschreibungen noch mal genau an!
Nichtfunktionale Anforderungen geben
Hinweise
e se zur
u Nutzung
ut u g von
o Design
es g Patterns
atte s
z Idee
Identifikation
Id tifik ti von Design
D i P
Patterns
tt
anhand
h d von Schlüsselwörtern
S hlü
l öt
iin d
der
Beschreibung nichtfunktionaler Anforderungen
Analog zu Abbots Objektidentifikation durch Textanalyse
z Hinweise auf Abstract Factory Pattern
“Herstellerunabhängig”,
“H t ll
bhä i ” “G
“Geräteunabhängig”,
ät
bhä i ” ““muss eine
i P
Produktfamilie
d ktf ili
unterstützen”
z Hinweise auf Adapter Pattern
“muss mit einem existierenden Objekt zusammenarbeiten”
z Hinweise auf Bridge Pattern
„muss sich
i h um di
die S
Schnittstelle
h itt t ll zu unterschiedlichen
t
hi dli h S
Systemen
t
kü
kümmern
von denen einige erst noch entwickelt werden.“
„ein erster Prototyp muss vorgeführt werden“
© 2000-2008 Dr. G. Kniesel
Seite 6-181
ROOTS
Nichtfunktionale Anforderungen geben Hinweise
zur Nutzung
g von Design
g Patterns (
(Fortsetzung)
g)
z Hinweise auf Composite Pattern
“komplexe
“k
l
St
Struktur”,
kt ” “muss
“
variable
i bl Tiefe
Ti f und
d Breite
B it h
haben”
b ”
z Hinweise auf Façade Pattern
“muss
muss mit einer Menge existierender Objekte zusammenarbeiten”,
zusammenarbeiten , "stellt
stellt
...-Dienst bereit"
z Hinweise auf Proxy Pattern
“muss
“
ortstransparent
t t
t sein”
i ”
z Hinweise auf Observer Pattern
“muss
muss erweiterbar sein”,
sein , “muss
muss skalierbar sein”
sein
z Hinweise auf Strategy Pattern
“muss Funktionalität X in unterschiedlichen Ausprägungen bereitstellen
kö
können”
”
© 2000-2008 Dr. G. Kniesel
Seite 6-182
ROOTS

Kapitel 6 Entwurfsmuster (Design Patterns)

Transcription

Similar documents

Inhalt: Entwurfsmuster 7.1 Entwurfsmuster, Frameworks

5. Wiederverwendung im Softwareentwurf 5.1 Entwurfsmuster