Java Schulung - Muster

24. – 28. September 2007 (Freitag)

Entwurfsmuster
 Motivation
 Kenntniss der Syntax reicht nicht aus gute Programme zu
schreiben - Gutes Design erfordert viel Erfahrung
 Mann muss sich nicht alles erarbeiten, sondern kann auch
abkucken (vom Muster)!
 Kommunikation: Designlösungen sollen anschaulich und
vermittelbar sein. Sprachverwirrung: (Observer/Listener..)

 Definitionen: Entwurfsmuster =
 bewährte Schablone für ein Entwurfsproblem
 wiederverwendbare Vorlage zur Problemlösung
 Keine „Technologie“ eher „Dokumentationskultur“

 Geschichte
 Ursprünglich Begriff aus der Architektur
 ca. 1988-1991 Arbeiten von Erich Gamma
 1995 „Gang Of Four“- Buch „Design Patterns“
Aufbau einer Musterbeschreibung (im Buch)
 Mustername
 Stichwort zur Benennung von Mustern
 Wichtig für den Austausch mit Kollegen
 wichtig zum klareren Denken in Entwurfsmuster
 Problemabschnitt
 Wann ist das Muster anzuwenden?
 Welches Problem wird adressiert?
 Was ist der Kontext?
 Lösungsabschnitt
 Aus welchen Elementen besteht die Lösung?
 Welche Beziehungen bestehen zwischen den Elementen?
 Wofür sind die Elemente Zuständig?
 Wie arbeiten die Elemente zusammen?
 Konsequenzabschnitt
 Welche Vorteile hat die Anwendung dieses Musters?
 Welche Nachteile hat die Anwendung dieses Musters?
Arten von Entwurfsmustern
 Erzeugungs-Patterns
 helfen, ein System unabhängig davon zu machen, wie seine
Objekte erzeugt, zusammengesetzt und repräsentiert werden
 Struktur-Patterns
 Befassen sich mit der Zusammensetzung von Klassen und
Objekten zu größeren Strukturen.
 Verhaltens-Patterns
 Befassen sich mit der Interaktion zwischen Objekten und Klassen.
 Beschreiben komplexe Kontrollflüsse, die zur Laufzeit schwer
nachvollziehbar sind.
 Split Object Patterns
 Aufteilung eines konzeptionellen Gesamtobjektes in modellierte
Teilobjekte, die kooperieren um das Verhalten des intendierten
Gesamtobjektes zu realisieren
 Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
SelectionAdapter()
 Visitor  Composite
 Observer  Flyweight
 Command  Deforator
 Template Method  Proxy
textStatement()  Chain Of Respons.  Adapter
HTMLStatement()  State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Observer (nicht nur in GUI)
 Absicht
 Wenn das eine Objekt seinen Zustand ändert, werden die
davon abhängigen Objekte benachrichtigt und
entsprechend aktualisiert
 Stellt eine 1-zu-n Beziehung (schwache Kopplung)
zwischen Objekten her. Objekte sollen andere Objekte
benachrichtigen können, ohne Annahmen über die
Beschaffenheit dieser Objekte machen zu müssen
 Andere Namen
 "Dependents", "Publish-Subscribe", "Listener"
 Motivation
 Verschiedene Objekte sollen zueinander konsistent
gehalten werden
 Andererseits sollen sie dennoch nicht eng miteinander
gekoppelt sein (bessere Wiederverwendbarkeit)
 Eines der beiden soll aber als ‚elementar‘ oder ‚bekannt‘
definiert werden können.
Beispiel – Ein Model und zwei Views
Observer-Muster als UML
Interaktionesreihenfolge beim Observer
Implementierungsdetails / Varianten
 Speicherort der Beziehung
 Listenattribut im beobachteten Subjekt
 In einer globalen (Hash-)Tabelle
 1-N Beziehung (mehrere Objekte pro Listener)
 „update()“-Methode benötigt zusätzlichen Parameter
 Event-Klassen
 Notify-Aufrufer
 "setter"-Methoden des Subjekts:
 Vorteil: Klienten können Aufruf von "notify()" nicht vergessen.
 Nachteil: Aufeinanderfolgende Aufrufe von „setter„-Aufrufe
führen zu überflüssigen Aktualisierungen.
 Beobachter selbst:
 Vorteil: Mehrere Änderungen können akkumuliert werden.
 Nachteil: Neue Beobachter vergessen möglicherweise
"notify()„-Aufruf.
 Gefahren bei Observern:
 Undurchsichtige Eventketten
 Schlimmer: Zyklische Eventketten (GUI verändert Modell ->
Event..)
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Strategy-Pattern

 Absicht
 Es gibt verschiedene Algorithmen für ein Problem,
die beliebig ausgetauscht werden können
 „Switch“-Statement soll vermieden werden
 Vorbereitung des Patterns „Template-Method“
 Beispiel (Motivation)
 Für die Berechnung von Zeilenumbrüchen gibt es
verschiedene Algorithmen.
 Später sollen leicht neue ergänzt werden können.
 Ähnliche Muster:
 „State-Pattern“, wie Strategy nur mit innerem
Zustand (Context)
Strategy-Muster in UML

 Ähnliche Muster:
 „State-Pattern“, wie Strategy nur mit innerem
Zustand (aus dem Context)
Implementierungsvarianten
 Übergabe der Strategie
 Feste Zuweisung in der Klasse
 Setter-Methode
 Plugin-Mechanismus

 Schnittstellen zwischen Kontext und Strategien

 Kontext übergibt alle relevanten Daten an die Strategie-
Methode
 Kontext übergibt this an Strategie-Methode, flexibelste
Lösung
 Strategie-Objekt speichert bei Initialisierung feste Referenz
auf Kontext

 Ggf. Default-Verhalten wenn keine Strategieobjekt

vorhanden ist
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Command-Pattern
 Absicht
 Bestimmte Aktionen sollen an verschiedenen Stellen ausgeführt
werden können.
 An diesen Stellen gibt es möglicherweise jeweils mehrere Aktionen
die im Kontext ausgeführt werden können (einheitliche
Anwendung)
 Andere Namen
 Command (Kommando), Action
 Motivation
 Verschiedene Aktionen werden aus Menüs oder alternativ aus
Toolbars oder per Hotkey angestoßen. Code soll nicht dupliziert
werden.
 Undo/Redo von Aktionen (History of Commands)
 Recover nach Systemabsturz
 Kommando als UML

Interface mit Methoden:

 do() oder execute()
 undo()
Kann als Parameter Widgets
übergeben werden!
Vorteile des Kommand-Patterns
 Entkopplung
 von Aufruf einer Operation und Spezifikation einer
Operation.
 Kommandos als Objekte
 Command-Objekte können wie andere Objekte auch
manipuliert und erweitert werden.
 Komposition
 Sequenzen von Command-Objekte können zu
weiteren Command-Objekten zusammengefasst
werden.
 Erweiterbarkeit
 Neue Command-Objekte können leicht hinzugefügt
werden, da keine Klassen geändert werden müssen.
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Facade Pattern (Fassade)
 Absicht
 Abhängigkeiten zwischen Client und Subsystem sollen verringert
werden.
 Einfachere Benutzung, Änderungsfreundlichkeit
 Einfache Schnittstelle genügt vielen Anwendern
 Andere Namen
 Fassade, Interface
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Proxy Pattern
 Absicht
 Stellvertreter für ein anderes Objekt (z.B. entfernt)
 Kontrolle über Objekt-Erzeugung und –Zugriff
(zeitlich, oder räumlich verzögert)
 Andere Bezeichnungen:
 Smart Interface
 Motivation:
 kostspielige Objekt-Erzeugung verzögern (zB: große
Bilder) verzögerte Objekterzeugung soll
Programmstruktur nicht global verändern
 Entfernte Objekte sollen genauso angesprochen
werden können, als wären sie vorhanden
Allgemeine Grundstuktur

Beispiel auf der nächsten Folie!

Beispiel: Ein Image-Proxy
Proxy: Zusammenfassung der Funktion

 Proxy
 bietet gleiches Interface wie „Subject“
 referenziert eine "RealSubject"-Instanz
 kontrolliert alle Aktionen auf dem "RealSubject"
 Subject
 definiert das gemeinsame Interface
 RealSubject
 das Objekt das der Proxy vertritt
 eigentliche Funktionalität
 Zusammenspiel
 selektives Forwarding
Verschiedene Arten von Proxys (Beispiele)
 Schutzproxy.
 Erlaubt Zugriff nur, wenn Berechtigung
nachgewiesen wurde.
 Remote Proxy
 Zugriff auf entferntes Objekt stellt sie wie lokaler
Zugriff dar.
 Virtueller Proxy
 Verzögerung kostspieliger Aktionen.
 … weitere Anwendungen denkbar.
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Composite
 Absicht
 Flexible Erstellung von Komplexen Objekten durch
Komposition
 Aus Sicht eines des Clienten sollen komplexe und einfache
Elemente gleich behandelt werden.
 Repräsentation von Baumstrukturen / Hierarchien /
rekursive Aggregationsstrukturen („ist Teil von“)
 Motivation
 Oft inspiriert aus der realen Welt
(Organisationsverbunde, Email-Listen mit
Gruppen…)
 Zusammensetzen von Grafiken/Widgets zu
komplexen Grafiken
Composite Beispiel als UML
Composite Allgemeine Struktur

C
lient 1opera C o
to
iommnpp onent
()onent) p
a dd(C arts
*
rgeemoavre
tP t((iC
nto)mponent)

Leaf C om posite 0.1

operation() o
a p
de
dr(a
Cto
iom np
()onent) fog ra
.
olpe
gria
ntip
a
o
nr(t)s
rgeem
tPoa
vre
t((iC
nto)mponent)
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Adapter
 Absicht
 Schnittstelle existierender Klasse an den Bedarf einer
existierende Client-Klasse anpassen
 Kompatibilität zwischen wechselnden Schnittstellen
 Beispiel
 Graphik-Editor bearbeitet Shapes
 Linien, Rechtecke, …
 durch "BoundingBox" beschrieben
 Nun sollen auch Textelemente möglich sein
 Klasse TextView vorhanden
 bietet aber keine "BoundingBox"-Operation
 Integration ohne
 Änderung der gesamten Shape-Hierarchie und
ihrer Clients
 Änderung der TextView-Klasse
 Zwei Arten von Adaptern
Objektadapter Klassenadapter

Komposition: Vererbung:
Ein Objekt wird in ein Neue Klasse wird erstellt,
anders gesteckt, das die die beide Schnittstellen
Schnittstelle impementiert, bzw eine auf
implementiert die andere abbildet.
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Singleton

 Absicht
 Von einem Objekt soll es nur eine Instanz geben
 Dennoch nicht static, aus Erweiterbarkeitsgründen
 Jeder soll leicht eine Referenz bekommen können
 Motivation
 DB Connection Pool, Repository, Schnittstellen zu
Systemdiensten
 Andere Muster: Facade, Factory

Singleton
u
sinin
nig
qluee
t In
o nsD
ta
an
t
ace
stgale
sgie
n ntcoen(O
)peration() ruentiu
qru
neInstance
tSingletonD ata()
Singleton Umsetzung in Java!

Lazy Evaluation!
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Factory Method

 Ein allgemeines Framework will Objekte

erzeugen. Die konkreten Objekte sind im
Framework noch nicht bekannt.
 Der Framework-Nutzer erzeugt diese in
einer ererbten Faktory-Methode
Factory Method –Statische Struktur

do*cs A
Beispiel

o pDeo nc(u
)m e
nt creap
tepl
Di
oca
c
uti
o
mn
en t
()
cslaovsee(()) ne wD oo
ccuu
mee
nn
tt() D o c u
m
corcesa
tee
n
D
ot*
codo
c
ucm =
ent();
revert() op enD m d .
add
(d
doc–>open(); )
;
M yD ocum ent «creates»cM yA p
reateDp li
ca
ocumti
o n
ent() returnnewM
yD
ocum
ent
C rea tor
Allgemeine Struktur

Product faancO
topre
yM e t
h od
(
ration()) .p.roduct=factoryM
ethod()
..
oncreteProduct «creates»C
C o n c
factoryMreteC rea
to
ethod()r returC
no
nn
ecw
reteProduct
 Factory Method –Statische Struktur

Creator
Product faancOtopreyMraetitohno(d)() .product=factoryMethod()
.
ConcreteProduct «creates»CfaocntocrryeMteeCthroeda(t)or returCnonnecwreteProduct
Konkrete Muster klassifiziert

Verhaltensmuster Strukturmuster
 Visitor  Composite
 Observer  Flyweight
 Command  Decorator
 Template Method  Proxy
 Chain Of Respons.  Adapter
 State  Bridge
 Strategy  Facade

 Factory  Prototype
 Factory Method  Singleton
 Builder
Erzeuger-Muster

Einige kennen wir schon!

Abstract Factory
 Absicht
 zusammengehörige Objekte verwandter Typen erzeugen
 ... ohne deren Klassenzugehörigkeit fest zu codieren
 Realisierung
 Eine/Mehrere Factory-Methoden in einer Klasse
 Setzen der Factory im Framework
 Beispiel
 GUI-Toolkit - konsistentes "look and feel" aber austauschbar
 Plugins die mehrere zueinandergehörige Erweiterungen
bereitstellen (Fenster, Commands,..)
Beispiel WidgetFactory
Allgemeine Struktur
Andere Arten von Mustern (Patternwelle)
 Analysemuster charakterisieren typische Fälle der
Anforderungsanalyse (Stücklisten…) Martin Fowler:
"Analysis Patterns", Addison-Wesley, 1997
 Architekturmuster beschreiben typische Software-
Architekturen. Subsysteme und Verantwortlichkeiten,
(Client-Server / Web oder Desktop / 3 Schichten)
 Kommunikationsmuster beziehen sich auf die
Kommunikationswege zwischen Personen einer
Organisation. (Broker, Forwared-Receiver, Client-
Dispatcher-Server)
 Codiermuster (Idioms): Low-Level Patterns für eine
bestimmte Programmiersprache (Singleton in Java)
 Antipattern beschreiben, "wie man es nicht machen sollte.„
(Used Car Fiasko, High Noon,…)
Zusammenfassung
 Patterns verkörpern Grundprinzipien guten,
flexiblen SW-Designs
 Patterns vereinfachen die Kommunikation
zwischen Entwicklern
 Patterns inspirieren auf der Suche nach
Lösungen!
Danke für Ihr Interesse …