Kapitel 6 Entwurfsmuster (“Design Patterns”) · Beobachter müssen sich die Informationen vom Subjekt holen + Geringere Kopplung zwischen Subjekt und Beobachter. –Bh dhäfidhfühtBerechnungen

Vorlesung „Softwaretechnologie“Wintersemester 2009 R O O T Ste se este 009

Kapitel 6

Entwurfsmuster (“Design Patterns”)

Stand: 1.12.2009

Einführung: Die Grundidee von Pattern

Grundlegende Idee Alle Ingenieurdisziplinen benötigen eine Terminologie ihrer wesentlichen 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.

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.

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-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 6-2 R O O T S

Einführung: Literatur zu Pattern und SoftwareSoftware Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four):

"Design Patterns - Elements of Reusable Object-Oriented Software"g jAddison-Wesley, 1995

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stalg(Gang of Five): "Pattern-Oriented Software Architecture - A System of Patterns"John Wiley & Sons, 1996

Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: "Object Oriented Reengineering Patterns", Morgan Kaufman, 2002

Patterns im 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


Buchliste: http://c2.com/cgi/wiki?PatternRelatedBookList

Einführung: Das MVC-Framework in Smalltalk als BeispielSmalltalk als Beispiel

a = 50% Modela 50%b = 30%c = 20%2. Änderungen

am Modell werden propagiert

- X - X

a = 50%b = 30%c = 20%1. Views melden sich an c 20%

View + Controller View + Controller



a = 50% Modela 50%b = 30%c = 20%

- X - X- X

a = 50%b = 30%c = 20%c 20%

View + Controller View + Controller


Neue Views können ohne Änderung des Modells oder der anderen Views hinzugefügt werden


Propagierung von Änderungen: Observer Patterna = 50%b = 30%c = 20%

Kommt z.B. auch bei Client/Server-Programmierung zur Benachrichtigung der Clients zum Einsatz - X

- X Geschachtelte Views: Composite Pattern View enthält weitere Views, wird aber wie ein

einziger View behandelteinziger View behandelt. Kommt z.B. auch bei Parsebäumen im Compilerbau

zum Einsatz (Ausdrücke).

- X

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


Kommt z.B. auch bei der Codeerzeugung im Compilerbauzum Einsatz (Code für verschiedene CPUs).

Überblick

1. Einführung

2. Einstiegsbeispiel: "Observer" im Detail

3. Was also sind Patterns?

4. Wichtige Patterns

5 Z i l hi d P tt5. Zusammenspiel verschiedener Patterns

6. Fazit: Nutzen von Patterns6. Fazit: Nutzen von Patterns

7. Zusammenfassung und Ausblick


Vorlesung „ Softwaretechnologie“Kapitel 6: Entwurfsmuster R O O T Sap te 6 t u s uste

Das Observer Pattern

Das Observer Pattern: Einführung

Absicht St llt i 1 B i h i h Obj kt h Stellt eine 1-zu-n Beziehung zwischen Objekten her Wenn das eine Objekt seinen Zustand ändert, werden die davon

abhängigen Objekte benachrichtigt und entsprechend aktualisiert

Andere Namen "Dependents" "Publish Subscribe" "Listener" Dependents , Publish-Subscribe , Listener

Motivation Verschiedene Objekte sollen zueinander konsistent gehalten werden Andererseits sollen sie dennoch nicht eng miteinander gekoppelt sein.

(bessere Wiederverwendbarkeit)(bessere Wiederverwendbarkeit)

Diese Ziele stehen in einem gewissen Konflikt zueinander. Man spricht von fli ti f “ l lä fi i k d K äft


„conflicting forces“, also gegenläufig wirkenden Kräften.

Das Observer Pattern: Beispiel

Trennung von Daten und Darstellung Wenn in einer Sicht Änderungen vorgenommen werden, werden alle Wenn in einer Sicht Änderungen vorgenommen werden, werden alle

anderen Sichten aktualisiert – Sichten sind aber unabhängig voneinander.

a = 50%a 50%b = 30%c = 20%

- X - X- X

a = 50%b = 30%c = 20%


c = 20%

Das Observer Pattern: Anwendbarkeit

Das Pattern ist im folgenden Kontext anwendbar: a = 50%b = 30%c = 20%

Abhängigkeiten Ein Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt

- - a = 50%b = 30%c = 20%

-

Ein Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt. Aufteilung dieser Aspekte in verschiedene Objekte erhöht

Variationsmöglichkeit und Wiederverwendbarkeit.

Folgeänderungen Änderungen an einem Objekt erfordert Änderungen an anderen Objekten. Änderungen an einem Objekt erfordert Änderungen an anderen Objekten. Es ist nicht bekannt, wie viele Objekte geändert werden müssen.

Lose Kopplung Objekte sollen andere Objekte benachrichtigen können, ohne Annahmen

über die Beschaffenheit dieser Objekte machen zu müssen.


j

Das Observer Pattern: Struktur (N:1 Pull-Modell) (N:1, Pull Modell)

<<interface>>Observer

{abstract}Subject

*

observers

1

subjectObserver

update() :void

Subject

attach(o:Observer):void

observers subject

observers.add(o)

( ) detach(o:Observer):voidnotify() : void

for all o in observers {o.update();

observers.remove(o)

}

ConcreteObserver ConcreteSubject

subjectState:State{redefines subject}

update() :void getState() : State setState(State s): void

return subjectState;1

subjectState = s;… subject.getState();


subjectState s;notify()

subject.getState();…

Rollenaufteilung / Verantwortlichkeiten (Pull Modell)(Pull Modell) Observer („Beobachter“) -- auch: Subscriber, Listener

update() auch: handleEvent update() -- auch: handleEvent Reaktion auf Zustandsänderung des Subjects

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 damit Observer feststellen können was sich wie geändert hat


g

Das Observer Patterns: Implementierung

Wie werden die Informationen über eine Änderung weitergegeben: push“ versus pull“„push versus „pull

Pull: Subjekt übergibt in „update()“ keinerlei Informationen, aber diePull: Subjekt übergibt in „update() keinerlei Informationen, aber die Beobachter müssen sich die Informationen vom Subjekt holen + Geringere Kopplung zwischen Subjekt und Beobachter. B h d hä fi d h füh t – Berechnungen werden häufiger durchgeführt.

Push: Subjekt übergibt in Parametern von „update()“ detaillierte j g „ p ()Informationen über Änderungen. + Rückaufrufe werden seltener durchgeführt. B b ht i d i i d db (Abhä i d – Beobachter sind weniger wiederverwendbar (Abhängig von den

Parametertypen)


Zwischenformen sind möglich

Das Observer Pattern: Struktur (N:1 Push-Modell) (N:1, Push Modell)


{abstract}Subject

*

observers

1

subjectObserver

update(StateA) :void

Subject

attach(o:Observer):void

observers subject

observers.add(o)

( ) detach(o:Observer):voidnotify() : void

observers.remove(o)

ConcreteObserver ConcreteSubject

subjectStateA:StateAbj tSt t B St t B

update(StateA) :voidsubjectStateB:StateBnotify() : voidsetState(State s): voidfor all o in observers {

o.update(subjectStateA);}


}

Das Observer Pattern: Implementierung

Vermeidung irrelevanter Notifikationen durch Differenzierung von EreignissenEreignissen Bisher: Notifikation bei jeder Änderung Alternative: Beobachter-Registrierung und Notifikation nur für spezielle

Ereignisse Realisierung: Differenzierung von attach(), detach(), update() und notify() in

jeweils ereignisspezifische Variantenj g p Vorteile:

Notifikation nur für relevante Ereignisse höhere Effizienz Weniger Rückfragen“ pro Ereignis höhere Effizienz Weniger „Rückfragen pro Ereignis höhere Effizienz

Nachteil: Mehr Programmieraufwand, wenn man sich für viele Ereignistypen interessiert Ab W k t tüt ö li h Aber: Werkzeugunterstützung möglich


Das Observer Patterns: Implementierung

ChangeManager V lt t B i h i h S bj kt d B b ht 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 verändert werden müssen, bevor die Aktualisierungen der Beobachter Sinn macht

Wer ruft notify() auf? a) "setState()" Methode des Subjekts: a) setState() -Methode des Subjekts:

+ Klienten können Aufruf von "notify()" nicht vergessen. – Aufeinanderfolgende Aufrufe von "setState()" führen zu evtl. überflüssigen

Akt li iAktualisierungen. b) Klienten:

+ Mehrere Änderungen können akkumuliert werden.


– Klienten vergessen möglicherweise Aufruf von "notify()".


Konsistenz-Problem Z t d i S bj kt A f f " tif ()" k i t t i Zustand eines Subjekts muss vor Aufruf von "notify()" konsistent sein. Vorsicht bei Vererbung bei Aufruf jeglicher geerbter Methoden die

möglicherweise „notify()“ -aufrufen :

public class MySubject extends SubjectSuperclass {public void doSomething(State newState) {p g( ) {super.doSomething(newState); // ruft "notify()" aufthis.modifyMyState(newState); // zu spät!

}}}

Lösung Dokumentation von „notify()“-Aufrufen erforderlich (Schnittstelle!) Besser: In Oberklasse „Template-Method Pattern“ anwenden um

sicherzustellen, dass „notify()“-Aufrufe immer am Schluss einer Methode


, „ y()stattfinden s. nächste Folie.


Verwendung des „Template Method Pattern“ bli l S bj tS l {

Template Methodpublic class SubjectSuperclass {

...final public void doSomething(State newState) {this.doItReally(newState); this.notify(); // notify immer am Schluß

}}public void doItReally(State newState) {}

}}

public class MySubject extends SubjectSuperclass {

Hook Method

public void doItReally(State newState) {this.modifyMyState(newState);

}


}}


Konsequenzen von Observer für Konsequenzen von Observer für Abhängigkeiten

Für Abhängigkeitsreduzierung allgemeinFür Presentation-Application-Data (PAD)

Für Boundary-Controller-Entity (BCE)Für Model-View-Kontroller (MVC)

PAD versus BCE versus MVC

Abhängigkeiten mit und ohne Observer

Ohne Observer: Abhängigkeit View ModelEi k k t M d l k t d I t f i j d k k t Vi Ein konkretes Model kennt das Interface eines jeden konkreten View und steuert was genau jeder der Views nach einem update tun soll: myGraphView1.setGraph(this.toPieChart()); myGraphView1.draw();y p p ( ()); y p (); myGraphView2.setGraph(this.toBarChart()); myGraphView2.draw(); … T tVi N i t( St t t St i ()) myTextViewN.print(myState.toString());

GraphView1:Model:TextViewN :GraphView1…

pModel

setState(…)update()

GraphView…GraphViewJ

tG h(B Ch t )

setState(…)

update()

pie=toPieChart()p ()

toPieChart()toBarChart()toString()

setGraph(BarChart p)draw()

TextView1TextView…

setGraph(pie)

draw()

s = toString()print()

TextView…

print()TextViewN

print()

s = toString()

print(s)

Abhängigkeiten mit und ohne Observer

Mit Observer: Abhängigkeit View ModelEi k k t M d l k t d b t kt Ob I t f Ein konkretes Model kennt nur das abstrakte Observer-Interface

Ein konkreter View kennt die zustandsabfragenden Methoden des konkreten Modelskonkreten Models model.getState1(); model.getState2();

:Model:View

attach(this)


update() :void

Subject

attach(o:Observer)

*

observers

1

subject

setState()

notify()

update()

p ()detach(o:Observer)notify()

for all o in observers {o.update();

}

getState()View

update() :void

ModelsubjectState:State

getState() : State

{redefines subject}

1


setState(State s)subject.getState();…

Nettoeffekt: Abhängigkeits- und KontrollumkehrungKontrollumkehrungAbhängigkeitsumkehrung („Dependency Inversion“)

Kontrollumkehrung („Inversion of Control“)(„Dependency Inversion )

Ohne Observer Abhängigkeit Model Views

(„Inversion of Control ) Ohne Observer

Model steuert alle updates Abhängigkeit Model Views Mit Observer

Abhängigkeit Model Views

Model steuert alle updates Mit Observer

Jeder View steuert sein update

:Model:View:Model:TextViewN :GraphView1…

Vergleich Ablauf ohne / mit Observer

attach(this)

setState()

notify()

setState(…)

update()

pie=toPieChart() notify()

update()

getState()

pie=toPieChart()

setGraph(pie)

draw()

s = toString()

print(s)

Auswirkungen von Observer auf Presentation-Application-Data“-Ebenen „Presentation Application Data Ebenen

n-tier-Architekturen basieren auf der rein hierarchische Anordnung von Presentation Anwendungslogik und DatenhaltungPresentation, Anwendungslogik und Datenhaltung

Präsentation ConcreteObserver

Anwendungslogik

Ä

Datenhaltung AbstractObserverConcreteSubject AbstractSubject

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


Ebenenanordnung nicht verletzt

Auswirkungen von Observer für Boundary-Controller-Entity“ Stereotypen„Boundary Controller Entity Stereotypen

Die Abhängigkeitsreduzierung ist die gleiche wie bei den Presentation-Application Data Ebenen der N Ebenen ArchitekturenApplication-Data Ebenen der N-Ebenen-Architekturen

Boundaries ConcreteObserver

Controllers

Entities AbstractObserverConcreteSubject AbstractSubject

Der einzige Unterschied zwischen BCE und PAD ist die Gruppierung: BCE beschreibt lediglich die Funktionen einzelner Objekttypen (Es sagt

nichts über ihre Gruppierung in Ebenen aus)pp g ) 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 Schicht


Alle Controller in der Anwendungslogik-Schicht Alle Entities in der Datenhaltungs-Schicht

Auswirkungen von Observer für Model-View-ControllerModel View Controller

Boundaries / Views ConcreteObserver

Controllers / Controllers

Entities / Model AbstractObserverConcreteSubject AbstractSubject

Views sind immer Boundaries und Observer Sonst könnten Sie ihre Funktion nicht erfüllen Das schließt nicht aus dass sie eventuell noch andere Rollen spielen Das schließt nicht aus, dass sie eventuell noch andere Rollen spielen

Boundaries sind nicht immer Views Beispiel: Tastatur


p

Auswirkungen von Observer für Model-View-ControllerModel View Controller

Observer sind nicht immer Views! A h K t ll kö Ob i ! Auch Kontroller können Observer sein! 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 gleiche gilt auch für andere Modellelemente / Entities: auch sie g gkönnen Observer von anderen Objekten sein.


Das Observer Pattern: Konsequenzen

Abstrakte Kopplung S bj kt ti f S hi ht i S t kö it B b ht Subjekte aus tieferen Schichten eines Systems können mit Beobachtern

aus höheren Schichten kommunizieren, ohne die Schichten zu verletzen.

C t Ob

Statische Abhängigkeit: Hierarchisch Dynamische Interaktion/Referenzen:Bidirektional

Präsentation

Anwendungslogik

ConcreteObserver :ConcreteObserver

notify update

Datenhaltung AbstractObserverConcreteSubject AbstractSubject:ConcreteSubject


Das Observer Pattern: Konsequenzen

Unabhängigkeit K k t B b ht kö hi fü t d h k k t S bj kt Konkrete Beobachter können hinzugefügt werden, ohne konkrete Subjekte

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. „Broadcast“-Nachrichten

Subjekt benachrichtigt alle angemeldeten Beobachter B b ht t h id b i N h i ht b h d l d i i Beobachter entscheiden, ob sie Nachrichten behandeln oder ignorieren

Unerwartete Aktualisierungen g Kleine Zustandsänderungen des Subjekts können komplexe Folgen haben. Auch uninteressante Zwischenzustände können unnötige Aktualisierungen

auslösen


auslösen.

Das Observer Pattern: Bekannte AnwendungenAnwendungen

Bekannte Anwendungen M d l Vi C t ll F k i S llt lk Model-View-Controller-Framework in Smalltalk Java Foundation Classes / Swing Oberon Systemy Diverse Client/Server-Modelle, z.B. Java RMI



Was also sind Patterns?

Definition: Was ist jetzt also ein Pattern?

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, anda certain software configuration which allows these forces to resolve

themselves."Richard Gabriel, on the Patterns Home Page


Bestandteile eines Patterns: Kontext, Problem RandbedingungenProblem, Randbedingungen Anwendbarkeit (Context) − Applicability

Die Vorbedingungen unter denen das Pattern benötigt wird Die Vorbedingungen unter denen das Pattern benötigt wird.

Problem Beschreibung des Problems oder der Absicht des Patterns Ziel und gewünschte Eigenschaften die in einem bestimmten Kontext mit

bestimmten Anforderungen erreicht werden sollen. Die Kräfte und die Ziele scheinen sich zu widersprechen.

Anforderungen (Forces) Anforderungen (Forces) Die relevanten Anforderungen und Einschränkungen, die berücksichtigt

werden müssen. Wie diese miteinander interagieren und im Konflikt stehen Wie diese miteinander interagieren und im Konflikt stehen. Die daraus entstehenden Kosten. Typischerweise durch ein motivierendes Szenario illustriert.


Bestandteile eines Patterns: Lösung

Die Lösung (Software Configuration) wird beschrieben durch:R ll Rollen Funktionen die Programmelemente im Rahmen des Patterns erfüllen. Interfaces, Klassen, Methoden, Felder / Assoziationen Interfaces, Klassen, Methoden, Felder / Assoziationen Methodenaufrufe und Feldzugriffe Sie werden bei der Implementierung aufg konkrete Programmelemente

abgebildet ( Player‘)abgebildet (‚Player ) Statische + dynamische Beziehungen

Klassendiagramm, dynamische Diagramme, Textg y g Meistens ist das Verständnis des dynamischen Verhaltens entscheidend

Denken in Objekten (Instanzen) statt Klassen (Typen)!

Teilnehmer − Participants Rollen auf Typebene (Klassen und Interfaces)


yp ( )

Bestandteile einer Pattern-Beschreibung

Name(n) des PatternsP bl d P tt lö t i d Problem, das vom Pattern gelöst wird

Kontext, in dem das Pattern angewendet werden kann Anforderungen die das Pattern beeinflussen Anforderungen, die das Pattern beeinflussen

Lösung. Beschreibung, wie das gewünschte Ergebnis erzielt wirdg g, g g Varianten der Lösung Beispiele der Anwendung der Lösung

Konsequenzen aus der Anwendung des Patterns

Bezug zu anderen Patterns Bekannte Verwendungen des Patterns


g


Klassifikation

Danach, was sie modellierenDanach, wie sie es modellieren

Danach, wo sie meist eingesetzt werden

"Gang of Four"-Patterns: Überblick und Klassifikation

StrukturVerhaltenKlassifikation

Visitor Composite Observer Command Template Method

Flyweight

Template Method Chain of Responsibility

Decorator

Bisher

State Strategy

M lti l V b

Proxy Adapter Bridge

Jetzt

Multiple Vererbung Bridge Facade

Split Objects

Factory Method Prototype

Split Objects

Objekt-Erzeugung

Factory Method Abstract Factory Builder

Prototype Singleton

Klassifikation: „Was“ und „Wie“

Verhaltens-Patterns Verhalten leicht erweiterbar, komponierbar, dynamisch änderbar oder

explizit manipulierbar machen Struktur-Patterns

Objekte mit fehlendem Zustand rekursive Strukturens? Objekte mit fehlendem Zustand, rekursive Strukturen Verschiedenste Formen der Entkopplung (Schnittstelle / Implementierung,

Identität / physikalische Speicherung, ...)E P tt

Was

Erzeugungs-Patterns Flexibilität indem die Festlegung von konkret zu erzeugenden Objekte

(new XYZ()) so weit wie möglich verzögert wird und evtl. sogar zur Laufzeit immer noch verändert werden kann.

Split Object Patterns Ziel: Dynamisch änderbares Verhalten gemeinsame Verwendung oder 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

Wie

?


Teilobjekte die kooperieren um das Verhalten des konzeptionellen Gesamtobjektes zu realisieren

Klassifikation: „Was“ und „Wie“ (Fortsetzung)(Fortsetzung)

Klassifikation danach was modelliert wird (vorherige Folien) St kt V h lt Obj kt Struktur, Verhalten, Objekterzeugung

Klassifikation danach wie etwas modelliert wird (vorherige Folien) Klassifikation danach, wie etwas modelliert wird (vorherige Folien) Whole Objects: 1:1-Entsprechung von konzeptuellen Objekten und

Implementierungs-Objekten S lit Obj t A ft il i k t ll Obj kt i hi d Split Objects: Aufteilung eines konzeptuellen Objektes in verschiedene

Implementierungs-Objekte, dynamisch veränderbare Anteile oder Gemeinsamkeiten verschiedener konzeptueller Objekte darstellen


Klassifikation: „Wo“

Klassifikation danach, wo sie meist eingesetzt werden S t t f V bi d / Ab S b t Systementwurf, zur Verbindung / Abgrenzung von Subsystemen

Facade, Adapter, Bridge, Proxy, Singleton (zusammen mit Facade) , Observer Objektentwurf

Observer, Command, Factory Method, Abstract Factory, Composite, Visitor



Wichtige Design Patterns Teil 1Wichtige Design Patterns, Teil 1- System Design Patterns -

Facade Singleton

AdapterProxyBridge

Patterns für Subsysteme ( siehe Systementwurf“)„Systementwurf )

Facade (siehe Kapitel 5 "Systementwurf„) S b t b hi

Subsystem abschirmen Singleton

Nur eine einzige Facade-Instanz erzeugen Nur eine einzige Facade Instanz erzeugen Adapter

Anpassung der realen an die erwartete Schnittstelle Proxy

Stellvertreter für entferntes Subsystem Bridge Bridge

Entkopplung der Schnittstelle von der Implementierung



Das Singleton Pattern

Singleton: Motivation

Beschränkung der Anzahl von Exemplaren zu einer Klasse

Meist: nur ein einzelnes Exemplar Motivation: Zentrale Kontrolle Z B Facade Repository Abstract Factory Motivation: Zentrale Kontrolle Z.B. Facade, Repository, Abstract Factory

Aber auch: feste Menge von Exemplaren Motivation 1: begrenzte Ressourcen (z.B. auf mobilen Geräten) Motivation 2: Teure Objekterzeugung durch „Object Pool“ vermeiden z B 1000 Enterprise Java Beans vorhalten nach Nutzung zurück in z.B. 1000 Enterprise Java Beans vorhalten, nach Nutzung zurück in den Pool


Singleton: Struktur + Implementierung

Besitzt nur private Konstruktoren:

private Singleton() {

getInstance()instanceOperation()

Singletonprivate Singleton() {

this.Singleton(arg1, ..., argN);}private Singleton(...) {

...}

Liefert eine Instanz (typischerweise immer die Selbe):

instanceOperation()

-instancePool-instanceData Speichert die einzige

Instanz oder begrenzte

}public static Singleton getInstance() {

if (instancePool == null)instancePool = new Singleton();

return instancePool;

Nur private Konstruktorend d h i d hi d d Cli b li bi i l I

gMenge an Instanzen }

dadurch wird verhindert, dass Clients beliebig viele Instanzen erzeugen können

in Java muss explizit ein privater Konstruktor mit leerer Argumentliste implementiert werden, damit kein impliziter öffentlicher Konstruktor vom Compiler erzeugt wird

instancePool als Registry für alle Singleton-Instanzen


g y g lookup-Mechanismus erforderlich um gezielt eine Instanz auszuwählen


Das Proxy Pattern

Proxy Pattern (auch: Surogate, Smart Reference)Reference)

Absicht St ll t t fü i d Obj kt Stellvertreter für ein anderes Objekt bietet Kontrolle über Objekt-Erzeugung und -Zugriff

Motivation kostspielige Objekt-Erzeugung verzögern (zB: große Bilder)

O verzögerte Objekterzeugung soll Programmstruktur nicht global verändern

IdeeIdee Bild-Stellvertreter (Proxy) verwenden Bild-Stellvertreter verhält sich aus Client-Sicht wie Bild Bild-Stellvertreter erzeugt Bild bei Bedarf

aTextDocumentimage

anImageProxyfile

anImage


Hauptspeicher Platte

Proxy Pattern: Beispiel

DocumentEditor<<interface>>

Graphic*

draw()getExtent()store()load()load()

Image ImageProxyif (image == 0){

image = loadImage(filename);}

<<creates>>

fileNameextent

image

image.draw()

if (image == 0){

imageDataextent

draw() draw()image if (image == 0){

return extent;} else {

return image.getExtent();}

getExtent()store()load()

getExtent()store()load()


}

Proxy Pattern: Schema

Client<<interface>>

Subject*

request()...

j

...realSubject request();

RealSubject ProxyrealSubject

request()...

request()...

realSubject.request();...

aProxyaRealSubject aClient request() request()


q () request()

Proxy Pattern: Verantwortlichkeiten

Proxy bi t t l i h I t f i "S bj t" bietet gleiches Interface wie "Subject" referenziert eine "RealSubject"-Instanz kontrolliert alle Aktionen auf dem "RealSubject"j

Subjectf f definiert das gemeinsame Interface

RealSubjectRealSubject das Objekt das der Proxy vertritt eigentliche Funktionalität

Zusammenspiel selektives Forwarding


selektives Forwarding

Proxy Pattern: Anwendbarkeit

Virtueller Proxy verzögerte Erzeugung "teurer" Objekte bei Bedarfg g g j Beispiel: Bilder in Dokument, persistente Objekte

Remote Proxy Zugriff auf entferntes Objekt Objekt-Migration Beispiele: CORBA, RMI, mobile Agenten e sp e e CO , , ob e ge te

Concurrency Proxy nur eine direkte Referenz auf RealSubject locking des RealSubjects vor Zugriff (threads)

Copy-on-Write k i höht i t "C C t " kopieren erhöht nur internen "CopyCounter" wirkliche Kopie bei Schreibzugriff und "CopyCounter">0 Verzögerung teurer Kopier-Operationen


Proxy Pattern: Anwendbarkeit

Protection Proxy (Zugriffskontrolle) S h l I t f Schmaleres Interface

"Kritische" Operationen ausgeblendet andere via Forwarding implementiert

ganz anderes Interface Autorisierung prüfen direkten Zugriff gewähren oder Forwardingdirekten Zugriff gewähren oder Forwarding

Beispiel: "CHOICES" Betriebssystem, JDK


Protection-Proxy im JDK (ab 1.2): GuardedObject GuardedObject Problem

Sichere Weitergabe eines schützenwerten Objektes an unbekannten Empfänger Sichere Weitergabe eines schützenwerten Objektes an unbekannten Empfänger Objektspezifische Zugriffsrechte Verzögerte Überprüfung der Zugriffsrechte

Idee: GuardedObject 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)

GuardcheckGuard(...)

bewachtesObj kt

Requestor GuardedObjectgetObject()

Objekt

Verbleibendes Problem Man muß sich darauf verlassen daß der "Requestor" das "bewachte


Man muß sich darauf verlassen, daß der Requestor das bewachte Objekt" selbst nur in ein GuardedObject verpackt weitergibt!

Proxy Pattern: Implementierung

„Consultation“ = Weiterleiten von Anfragen Allgemein: manuell erstellte Forwarding Methoden Allgemein: manuell erstellte Forwarding-Methoden C++: Operator-Overloading

Proxy redefiniert Dereferenzierungs-Operator:*anImage Proxy redefiniert Member-Accesss-Operator:anImage->extent() Proxy redefiniert Member-Accesss-Operator:anImage->extent()

Smalltalk: Reflektion Proxy redefiniert Methode "doesNotUnderstand: aMessage"

Lava: eigenes Sprachkonstrukt Lava: eigenes Sprachkonstrukt Proxy deklariert "consultee"-Variable

class Proxy {private consultee RealImage realImage;...

} Falls der Typ von "RealSubject„ dem Proxy bekannt sein muß:

Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ ... dem Proxy nicht bekannt sein muß:

Nur eine Proxy-Klasse für verschiedene RealSubject-Typen B i i l G d d Obj t“ ( h i F li )


Beispiel: „Guarded Object“ (vorherige Folie)

Proxy Pattern: Implementierung

Refenrenzierung des RealSubject vor Instantiierung O t d Z it bhä i "E t R f " Orts- und Zeit-unabhängige "Ersatz-Referenzen" Beispiele

Dateinamen CORBA IOR (Interoperable Object Reference)



Das Adapter Pattern

Adapter Pattern (auch: Wrapper)

Absicht Schnittstelle existierender Klasse an Bedarf existierender Clients anpassen Schnittstelle existierender Klasse an Bedarf existierender Clients anpassen

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

Idee Adapter-Klasse stellt Shape-Interface zur Verfügung ... implementiert Shape-Interface anhand der verfügbaren TextView-

Methoden


Methoden

Adapter Pattern: Beispiel

*

Existierende Klassen

Shape

BoundingBox()CreateManipulator()

DrawingEditorAdapter-Klasse

CreateManipulator()

Line TextViewtext

TextShape



getExtent()...

return text.getExtent()

return new TextManipulator()


return new TextManipulator()

Adapter Pattern (Objekt-Adapter): SchemaSchema

Target AdapteeClientadaptee

request() other()f()

f()

Adapterrequest()

f()

Adaptee_N ……

f()adaptee.other()

:Adapter:Client :Adaptee_N

request()request()other()

f()


Adapter Pattern (Objekt-Adapter): KonsequenzenKonsequenzen

Target AdapteeClientadaptee


f()

Adapterrequest()

f()d t th ()

Adaptee_N ……

Adaptiert eine ganze Klassenhierarchie Beliebige Adapter Subtypen können mit beliebigen Adaptee Subtypen

adaptee.other()

Beliebige Adapter-Subtypen können mit beliebigen Adaptee-Subtypen kombiniert werden ( siehe Objektdiagram auf vorheriger Folie)

Kombination wird erst zur Laufzeit, auf Objektebene, festgelegt Overriding nicht möglich

Die f()-Definition aus Adapter wird nicht anstelle der f()-Definition aus Adaptee für den f()-Aufruf aus der Methode other() verwendet


p () ()( siehe Objektdiagram auf vorheriger Folie)

Adapter Pattern (Object Adapter): VarianteVariante

Target

request()

Adapteeother()

Clientadaptee

f()q ()f()

Adapter

f()

Adapterrequest()

f()

Adaptee_N ……

Ad t N‘ ‘‘

Object Adapter mit Overriding

f()f() f()

Adaptee_N‘ …‘…‘

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 nicht veränderbar ist! Warum neue Unterklassen? Weil die Adaptee-Hierarchie nicht veränderbar ist!

Problem: Redundanz! Was konzeptionell nur ein mal in Adapter stehen sollte wird in jeder neuen

U t kl Ad t d d t i fü tW t bl !


Unterklasse von Adaptee redundant eingefügt Wartungsprobleme!

Class Adapter Idiom: Schema

„Vererbung ohne Subtyping“:Erbender erbt Methoden die nicht als Teil seines Interface sichtbar werden.

Target AdapteeClient

"private inheritance" in C++ "closed inheritance" in Eiffel


f()

<<implementation inheritance>>

Adapterrequest()

f()

Adaptee_N ……

p

anAdaptedAdaptee:Adapter:Client

f()

request() other()

f()f()

Class Adapter Idiom: Konsequenzen

Target

request()

Adapteeother()

Client

f()request() ()f()

f()

<<implementation inheritance>>

Adapterrequest()

f()

Adaptee_N ……

O

anAdaptedAdaptee:Adapter:Client

Overriding des Adaptee-Verhaltens leicht möglich Da Adapter eine Unterklasse von Adaptee ist, funktioniert das Overriding von

f() Keine zusätzliche Indirektion Keine zusätzliche Indirektion

nur ein Objekt statt zwei Adaptiert nur eine Klasse

nicht ihre Unterklassen


nicht ihre Unterklassen

Adapter Pattern: Konsequenzen

Class Adapter adaptiert nur eine Klasse Target AdapteeClient adaptiert nur eine Klasse ... nicht ihre Unterklassen Overriding des Adaptee-Verhaltens leicht möglich

ä ( O )

grequest()

Adapteef()

m()

Adapterrequest() Adapt_N

keine zusätzliche Indirektion (nur ein Objekt)

Object Adapter

q ()

:Adapter:Client :Adaptee

f()m()

j adaptiert eine ganze Klassenhierarchie Overriding schwieriger

redefiniertes Verhalten in spezifische Unterklasse des Adaptees einfügen redefiniertes Verhalten in spezifische Unterklasse des Adaptees einfügen Adapter benutzt diese Unterklasse Kombinierbarkeit mit anderen Unterklassen geht verloren

Object Adapter mit Delegation (roots.iai.uni-bonn.de/research/darwin) adaptiert eine ganze Klassenhierarchie O erriding des Adaptee Verhaltens leicht möglich


Overriding des Adaptee-Verhaltens leicht möglich


Das Bridge Pattern

Bridge Pattern (auch: Handle / Body)

Absicht S h itt t ll d I l ti t Schnittstelle und Implementierung trennen ... unabhängig variieren

Motivation portable "Window"-Abstraktion in GUI-Toolkit mehrere Variations-Dimensionen

Fenster-Arten: – normal / als Icon, – schließbar / nicht schließbar, – ...

Implementierungen: X Wi d– X-Windows,

– IBM Presentation Manager,– MacOS, – Windows XYZ,


,– ...

Bridge Pattern: Warum nicht einfach Vererbung einsetzen?

Neue Fenster-Art:"iconifizierbare" Fenster

Window Window

XWindow PMWindow IconWindowPMWindowXWindow

Probleme dieses Lösungsversuchs Ei Kl fü j d K bi ti F t A t / Pl ttf

XIconWindow PMIconWindow

Eigene Klasse für jede Kombination Fenster-Art / Plattform unwartbar

Client wählt Kombination Fenster-Art / Plattform (bei der Objekterzeugung)


plattformabhängiger Client-Code

Bridge Pattern: Idee

Trennung von Konzeptueller Hierarchie Implementierungs-Hierarchie Konzeptueller Hierarchie

Window WindowImp

bridgeimp

Implementierungs-Hierarchie

drawText()drawRect()

devDrawText()devDrawLine()

imp.devDrawLine()imp.devDrawLine()imp.devDrawLine()

IconWindow PMWindowImpXWindowImpTransientWindow

imp.devDrawLine()

drawBorder()

IconWindow

devDrawLine()devDrawText()

PMWindowImp


XWindowImp

drawCloseBox()

TransientWindow

drawRect()drawText() drawRect() XDrawLine() XDrawString()

Bridge Pattern: Schema

Client

basicOperation()

Implementor

operation()

Abstraction imp

imp.basicOperation()

RefinedAbstraction

basicOperation()

ConcreteImplementorA

basicOperation()

ConcreteImplementorB


Bridge Pattern: Anwendbarkeit

Dynamische Änderbarkeit I l ti t L f it ähl Implementierung erst zur Laufzeit auswählen

Unabhängige Variabilität neue Unterklassen in beiden Hierarchien beliebig kombinierbar neue Unterklassen in beiden Hierarchien beliebig kombinierbar

Implementierungs-Transparenz für Clients Änderungen der Implementierung erfordern keine Änderung /

N üb t d Cli tNeuübersetzung der Clients Vermeidung von "Nested Generalisations"

keine Hierarchien der Art wie in der Motivations-Folie gezeigt keine Hierarchien der Art wie in der Motivations Folie gezeigt keine kombinatorische Explosion der Klassenanzahl

Sharing mehrere Clients nutzen gleiche Implementierung z.B. Strings


Bridge Pattern: Implementierung

ImplementorAbstractionimp

Client

Instantiierung des richtigen ConcreteImplementors

imp

...

Falls Abstraction alle ConcreteImplementor-Klassen kennt: Fallunterscheidung im Konstruktor der ConcreteAbstraction a u te sc e du g o st u to de Co c ete bst act o Auswahl des ConcreteImplementor anhand von Parametern des

Konstruktors Alternativ: Default Initialisierung und spätere situationsbedingte Änderung Alternativ: Default-Initialisierung und spätere situationsbedingte Änderung

Falls Abstraction völlig unabhängig von ConcreteImplementor-Klassen sein soll: Entscheidung anderem Objekt überlassen Abstract Factory Pattern


Abstract Factory Pattern


Wichtige Design Patterns Teil 2Wichtige Design 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

Kontext GUI T lkit it GUI-Toolkits mit

Buttons, Menüs, etc. Forces

Vielfalt trotz Einheitlichkeit Einheitlicher Code in allen GUI-Elementen trotzdem verschiedene Effekte .. trotzdem verschiedene Effekte

Wiederverwendung Über verschiedene GUI-Elemente ansprechbare Operationen nur ein mal

programmierenprogrammieren Dynamik

dynamische Änderung der Aktionen von Menu-Einträgen kontext-sensitive Aktionen


Das Command Pattern: Idee

Operationen als Objekte mit Methode execute() darstellenI d GUI El t i h In den GUI-Elementen speichern

Application Menu MenuItemd t ()

Einheitlicher Aufruf

add(Document) add(Menuitem) clicked() command.execute();

command

Commandexecute()

Documentopen()close()cut()copy()

PasteCommandt ()

document

copy()paste()

execute()

d t t ()

VerschiedeneImplementierungen


document.paste();

Command Pattern: Schema und Rollen

<<interface>>CommandInvoker

tC d()Client

execute()setCommand()

ConcreteCommandexecute()

Receiveraction()

Command Interface Schnittstelle die festlegt as

Execute-Methode A sführen on Kommandos Schnittstelle, die festlegt, was

Commands tun können Mindestens Execute, optional auch

Undo Redo

Ausführen von Kommandos Undo-Methode

Rückgängig machen von Undo, Redo

Concrete Command Implementiert Command Interface

Kommandos Redo-Methode

Rückgängig gemachtes Kommando


„Controllers“ sind oft „ConcreteCommands“

wieder ausführen

Das Command Pattern: Konsequenzen

Entkopplung A f f i O ti d S ifik ti i O ti von Aufruf einer Operation und Spezifikation einer Operation.

Kommandos als Objekte Command-Objekte können wie andere Objekte auch manipuliert und Command Objekte können wie andere Objekte auch manipuliert und

erweitert werden. Komposition

F l C d Obj kt kö it C d Obj kt Folgen 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.


Das Command Pattern: Anwendbarkeit

Operationen als Parameter Variable Aktionen Variable Aktionen

referenziertes Command-Objekt austauschen Zeitliche Trennung

Befehl zur Ausführung, Protokollierung, Ausführung Speicherung und Protokollierung von Operationen

History-Liste History Liste Serialisierung

"Undo" von Operationen C O () () Command-Objekte enthalten neben execute() auch unexecute() werden in einer History-Liste gespeichert

Recover-Funktion nach Systemabstürzen History-Liste wird gespeichert Zustand eines Systems ab letzter Speicherung wiederstellbar

Unterstützung von Transaktionen Unterstützung von Transaktionen Transaktionen können sowohl einfache ("primitive"), als auch komplexe Command-

Objekte sein.

Implementierung des Command Patterns

Unterschiedliche Grade von Intelligenz Command-Objekte können "nur" Verbindung zwischen Sender und Empfänger sein, j g p g ,

oder aber alles selbstständig erledigen. Unterstützung von "undo"

Semantik Semantik Undo (unexecute()) und redo (execute()) müssen den exakt gegenteiligen Effekt haben!

Problem: In den wenigsten Fällen gibt es exact inverse Operationen Die Mathematik ist da eine Ausnahme 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.g p Typischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werden

sollen.

History-Liste Für mehrere Levels von undo/redo

Klonen vor Speicherung in der History-Liste Es reicht nicht eine Referenz auf die Objekte zu setzen!


Man muss das Objekt "tief" klonen, um sicherzustellen dass sein Zustand nicht verändert wird.

Patterns-Überblick

StrukturVerhalten Visitor Composite Visitor Observer Command

Composite Flyweight


Decorator

State Strategy

Decorator Adapter Proxy



Split Objects

Objekt-Erzeugung

Abstract Factory Builder

yp Singleton


Das Command und Observer PatternDas Command und Observer Patternin Java

Verbindung von Observer und Command in Java in Java

<<interface>>ActionListener

void actionPerfomed(ActionEvent evt)

<<implements>>

MyPasteCommand

void actionPerfomed(ActionEvent evt):MenuItem

: MyPasteCommand

:Button addActionListener(ActionListener)

actionPerformed(ActionEvent)

Observer

:JComponent registerKeyboardAction(ActionListener, KeyStroke, ...)


Command & Observer Observer Buttons, Menue-Einträge und Tasten

generieren "ActionEvents" Interface "ActionListener" ist vordefiniert "ActionListener" implementieren

Command & Observer gleiche Methode (z.B. actionPerformed)

spielt die Rolle der run() Methode eines Commands und die Rolle der update() Methode eines Observers

ActionListener implementieren ... und Instanzen davon bei Buttons,

MenuItems, etc registrieren

implementierende Klasse (z.B. MyPasteCommand) ist gleichzeitig ein Command und ein Observer

Verbindung von Observer und Command in Java verbindet auch Push und Pullin Java verbindet auch Push und Pull

<<interface>>ActionListener


<<implements>>

MyPasteCommand

void actionPerfomed(ActionEvent evt):MenuItem

: MyPasteCommand

:Button addActionListener(ActionListener)


Push Observer

:JComponent registerKeyboardAction(ActionListener, KeyStroke, ...)


Pull Observer Push Observer Subject „pushed“ eine „Event“-Instanz Der „Event“-Typ kann selbst definiert

werden In dieser Instanz können somit weitere

Pull Observer Die als Parameter übergebene

„Event“-Instanz enthält immer eine Referenz auf die Quelle des Events

Somit ist es möglich von dort weitere In dieser Instanz können somit weitere Informationen mit „gepushed“ werden (als Werte von Instanzvariablen)

gInformationen zu anzufragen („pull“)

Verbindung von Observer und Command in Java (2)in Java (2)

Zusätzliche Unterstützung für "Command"

<<interface>>ActionListenerCommand

Interface "Action" und Klasse "AbstractAction"

Akti i /

ActionListener


<<extends>>

<<interface>>Action

void putValue(String key, Object value)Object getValue(String key) Einheitliche Schnittstelle zur

Aktivierung / Deaktivierung

von MenuItems d di th

alte

n

Object getValue(String key)

boolean isEnabled()void setEnabled(boolean b)void addPropertyChangeListener(PropertyChangeListener listener)

Einheitliche Schnittstelle zur Speicherung von Parametern

für "Action" ...

denen diese "Action"

zugeordnet ist

m J

DK

en

void addPropertyChangeListener(PropertyChangeListener listener)void removePropertyChangeListener(PropertyChangeListener listener)

<<implements>>... Parameter

können ll di

im

AbstractAction// alles ausser void actionPerfomed(ActionEvent evt)

allerdings auch direkt als

Instanz-Variablen realisiert <<extends>>

MyPasteCommandvoid actionPerfomed(ActionEvent evt)

realisiert werden.

<<extends>>

Beispiel: Änderung der Hintergrundfarbe (1)(1)class ColorAction extends AbstractAction{ public ColorAction(..., Color c, Component comp)

{ ...color = c;target = comp;

}}

public void actionPerformed(ActionEvent evt){ target.setBackground(color);

i ()target.repaint();}

private Component target; class ActionButton extends JButtonp ate Co po e t ta get;private Color color;

}

{ public ActionButton(Action a){ ...

addActionListener(a);}

ColorActionÄndern der Hintergrundfarbe einer GUI-Komponente

}}

ActionButtonButtons die sofort bei Erzeugung mit einer Action verknüpft werden

Beispiel: Änderung der Hintergrundfarbe (2)(2)

Nutzung der ColorAction E i I t

class SeparateGUIFrame extends JFrame

Erzeugung einer Instanz 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

Elegante Verbindung von Observer und Command C d i d A ti Li t B tt M t Commands sind ActionListener von Buttons, Menus, etc.

Einheitlicher Aufru via actionPerformed(ActionEvent evt) Buttons und Menus sind PropertyChangeListener von Commands

Aktivierung / Deaktivierung

Wiederverwendung Wiederverwendung gleiche Action für Menu, Button, Key

Dynamik Wie ändert man die aktuelle Aktion? k i t t fü ll b t ff M It B tt t ??? ... konsistent für alle betroffenen MenuItems, Buttons, etc.???

Strategy Pattern!


gy


StrukturVerhalten

Klassifikation

Visitor CompositeVisitor Observer Command

Composite Flyweight


Decorator State Strategy

Decorator Proxy Adapter


Jetzt


Split ObjectsJetzt

Objekt-Erzeugung


yp Singleton


Das Factory Method Pattern

Factory Method

Ziel E t h id üb k k t Kl Obj kt ö Entscheidung über konkreter Klasse neuer Objekte verzögern

Motivation Framework mit vordefinierten Klassen "Document" und "Application" Template-Methode, für das Öffnen eines Dokuments:

1 Ch k b D k t A t b k t 1. Check ob Dokument-Art bekannt 2. Erzeugung einer Document-Instanz !?!

Erzeugung von Instanzen noch nicht bekannter Klassen!

Idee kt ll Kl t h id t Obj kt t d aktuelle Klasse entscheidet wann Objekte erzeugt werden

Aufruf einer abstrakten Methode Subklasse entscheidet was für Objekte erzeugt werden


implementiert abstrakte Methode passend

Factory Method: Beispiel

Framework

Document ApplicationD t()

*Document doc = doCreateDocument();docs

newDocument()doCreateDocument() docs.add(doc);

doc.open();

MyDocument MyApplicationdoCreateDocument() return new MyDocument()

Applikation

Factory Method: Schema

ProductanOperation()

Creator ...product = factoryMethod();anOperation()

factoryMethod()product = factoryMethod();...

ConcreteProductfactoryMethod()

ConcreteCreatorreturn new ConcreteProduct()

Factory Method kann abstrakt sein

factoryMethod()

kann Default-Implementierung haben

C t (A f f d F t M th d) Creator (Aufrufer der Factory Method) kann Klasse sein, die die Factory Method definiert kann Client-Klasse sein


Beispiel: parallele Vererbungs-Hierarchien

Factory Method: Anwendbarkeit

Klasse neuer Objekte unbekannt

Verzögerte Entscheidung über Instantiierung erst in Subklasse erst beim Client

M h Hilf kl Mehrere Hilfsklassen Wissen über konkrete Hilfsklassen an einer Stelle lokalisieren Beispiel: Parallele Hierarchien (nächste Folie) p ( )


Factory Method: Anwendbarkeit

Figure ManipulatorClientcreateManipulator()...

downClick()drag()upClick()

T tFiLi Fi Li M i l t T t i l tcreateManipulator()...

TextFigurecreateManipulator()...

LineFiguredownClick()drag()upClick()

LineManipulatordownClick()drag()upClick()

Textmanipulator

upClick() upClick()

Verbindung paralleler Klassenhierarchien Factory Method lokalisiert das Wissen über zusammengehörige Klassen Restlicher Code der Figure-Hierarchie und Client-Code ist völlig


Restlicher Code der Figure Hierarchie und Client Code ist völlig unabhängig von spezifischen Manipulators (nur vom Manipulator-Interface)

Factory Method: Implementierung

Fester "Produkt-Typ" j d U t kl t

class Creator {Product create(){ MyProduct(); } jede Unterklasse erzeugt

festgelegte Produkt-ArtProduct create(){ MyProduct(); }

}

Codierter "Produkt-Typ"class Creator {

Product create(int id) {if (id==1) return MyProduct1();if (id==2) return MyProduct2();

Codierter Produkt Typ Parameter oder Objekt-Variable

kodiert "Produkt-Typ" Fallunterscheidung anhand if (id==2) return MyProduct2();

...}

}

gCode

mehrere Produkte mehr Flexibilität Idiom reflektiver Sprachen

S ll lk

class Creator {Object create(Class prodType) {

Klassen-Objekt als "Produkt-Typ" Parameter oder Objekt-Variable

ist "Produkt Typ"

• Smalltalk• Java

Object create(Class prodType) {return prodType.getInstance();

}}

ist Produkt-Typ direkte Instantiierung mehr Flexibilität bessere Wartbarkeit

Reflektiver Aufruf des parameterelosen Default Konstruktors


bessere Wartbarkeit kein statischer Typ-Check

Default-Konstruktors

Factory Method: Konsequenzen

Code wird abstrakter / wiederverwendbarer k i f t Abhä i k it ifi h Kl keine festen Abhängigkeiten von spezifischen Klassen

Verbindung paralleler Klassenhierarchieng p Factory Method lokalisiert das Wissen über Zusammengehörigkeiten

evtl. künstliche Subklassen nur zwecks Objekterzeugung


Factory Method: Anwendungen

überall in Toolkits, Frameworks, Class Libraries U id B i i l "Fi d M i l t " Unidraw: Beispiel "Figure und Manipulator" MacApp und ET++: Beispiel "Document und Application"

Smalltalk's Model-View-Controller Framework FactoryMethoden-Template: defaultController H k M th d Hook-Methode: defaultControllerClass

OrbixOrbix Erzeugung des richtigen Proxy

leichte Ersetzung von Standard-Proxy durch Caching Proxy



Das Abstract Factory Pattern

Abstract Factory

Ziel hö i Obj kt dt T zusammengehörige Objekte verwandter Typen erzeugen ... ohne deren Klassenzugehörigkeit fest zu codieren

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


Abstract Factory: Beispiel

createWindow()

WidgetFactory ClientcreateWindow()createScrollBar()

Wi dWindow

createWindow()MotifWidgetFactory

createWindow()PMWidgetFactory PMWindow MotifWindow

createScrollBar() createScrollBar()

Scrollbar


PMScrollbar MotifScrollBar

Abstract Factory: Schema

createProductA()

AbstractFactory ClientcreateProductA()createProductB()

AbstractProductA

createProductA()ConreteFactory1

createProductA()ConreteFactory2 ProductA2 ProductA1

()createProductB()

()createProductB()

AbstractProductB


ProductB2 ProductB1

Abstract Factory: Implementierung

ConcreteFactories sind Singletons Produkt Erzeugung via Factory Methods Produkt-Erzeugung via Factory-Methods fester Produkt-Typ (eine Methode für jedes Produkt)

Nachteil neues Produkt erfordert Änderung der gesamten Factory-Hierarchie

Codierter "Produkt-Typ" (eine parametrisierte Methode für alle Produkte)) Vorteil

leichte Erweiterbarkeit um neues Produkt Nachteile: Nachteile:

alle Produkte müssen gemeinsamen Obertyp haben Clients können nur die Operationen des gemeinsamen Obertyps nutzen Verzicht auf statische Typsicherheit Verzicht auf statische Typsicherheit

Klassen-Objekt als "Produkt-Typ" (eine parametrisierte Methode) Vorteil

P d kt f d t k i l i Ä d d F t neues Produkt erfordert keinerlei Änderungen der Factory Nachteil

Verzicht auf jegliche statische Typinformation / Typsicherheit

Abstract Factory: Implementierung

Produktfamilie = Subklasse V t il Vorteil

Konsistenz der Produkte Nachteil

neue Produktfamilie erfordert neue Subklasse, auch bei geringen Unterschieden

Produktfamilie = von Clients konfigurierte assoziative Datenstruktur Varianten

P t t d Cl i Prototypen und Cloning Klassen und Instantiierung

Vorteil keine Subklassenbildung erforderlich

Nachteil Verantwortlichkeit an Clients abgegeben


g g konsistente Produktfamilien können nicht mehr garantiert werden

Abstract Factory: Konsequenzen

Abschirmung von Implementierungs-Klassen Namen von Implementierungsklassen erscheinen nicht im Code von Namen von Implementierungsklassen erscheinen nicht im Code von

Clients Clients benutzen nur abstraktes Interface

Leichte Austauschbarkeit von Produktfamilien Name einer ConcreteFactory erscheint nur ein mal im Code

bei ihrer Instantiierung bei ihrer Instantiierung Leicht austauschbar gegen andere ConcreteFactory Beispiel: Dynamisches Ändern des look-and-feel

d C t F t i t tii andere ConcreteFactory instantiieren alle GUI-Objekte neu erzeugen

Konsistente Benutzung von Produktfamilien Konsistente Benutzung von Produktfamilien Keine Motif-Scrollbar in Macintosh-Fenster

Schwierige Erweiterung um neue Produktarten Schwierige Erweiterung um neue Produktarten Schnittstelle der AbstractFactory legt Produktarten fest Neue Produktart = Änderung der gesamten Factory-Hierarchie

Abstract Factory: Anwendbarkeit

System soll unabhängig sein von Obj kt E Objekt-Erzeugung Objekt-Komposition Objekt-Darstellungj g

System soll konfigurierbar sein Auswahl aus verschiedenen Produkt-Familien

konsistente Produktfamilienkonsistente Produktfamilien nur Objekte der gleichen Familie "passen zusammen"

Library mit Produktfamilie anbieten Clients sollen nur Schnittstelle kennen nicht die genauen Teilprodukt-Arten / -Implementierungen


... nicht die genauen Teilprodukt Arten / Implementierungen


StrukturVerhalten

Klassifikation

Visitor CompositeJetzt

Visitor Observer Command

Composite Flyweight


Decorator State Strategy

Decorator Proxy Adapter



Split Objects

Objekt-Erzeugung


yp Singleton


Das Composite Pattern

Composite Pattern

Ziel k i A ti St kt d t ll ("i t T il ") rekursive Aggregations-Strukturen darstellen ("ist Teil von") Aggregat und Teile einheitlich behandeln

Motivation Gruppierung von Graphiken


Composite Pattern: Beispiel

Graphicdraw() childrendraw()

add(Graphic)remove(Graphic)

getChildren()

PictureText draw() {for all c in childrenc.draw()

draw()add(Graphic)

draw()

Linedraw()

}remove(Graphic)getChildren()

:Text

:Line

:Picture :Picture

:Text


:Text :Picture :Picture

Composite Pattern: Struktur

ComponentClient*

Componentoperation()

add(Component)remove(Component)

childrenClient

getChildren()

CompositeLeaf operation() {for all c in childrenoperation()operation()c.operation()

}

operation()add(Component)

remove(Component)getChildren()



add() {}

oderadd() {throw new MessageNotSupportedException()}


add() {throw new MessageNotSupportedException()}

Composite Pattern: Verantwortlichkeiten

Component (Graphic) i I t f ll T il bj kt

Componentoperation() children

*

gemeinsames Interface aller Teilobjekte default-Verhalten Interface für Zugriff auf Teilobjekte (!)


getChildren()g j ( )

evtl. Interface für Zugriff auf Elternobjekte

L f (R t l Li T t) Leaf (Rectangle, Line, Text) "primitive" Teil-Objekte implementieren gemeinsames Interface

CompositeLeafoperation()


operation()

p g leere Implementierungen für Teilzugriffs-Interface

C it (Pi t )


Composite (Picture) speichert Teilobjekte implementiert gemeinsames Interface durch forwarding


implementiert gemeinsames Interface durch forwarding implementiert Teilzugriffs-Interface

Composite Pattern: Implementierung

Wenn Composites wissen sollen wovon sie Teil sind Explizite Referenzen auf Composite in

Componentoperation()

add(Component)

children

*

Explizite Referenzen auf Composite in Component Klasse

Wenn mehrere Composites Components


getChildren()

pare

gemeinsam nutzen sollen Schließt explizite Referenz der Components

auf Composite aus oder erfordert dass Components

CompositeLeafoperation()


operation()

ent1

auf Composite aus oder erfordert, dass Componentswissen, dass sie Teile mehrerer Composites sind

Component Interface


p "Sauberes Design": Verwaltungs-Operationen (add, remove) in Composite,

da sie für Leafs nicht anwendbar sind. Wunsch nach einheitlicher Behandlung aller Graphic Objekte durch Clients Wunsch nach einheitlicher Behandlung aller Graphic-Objekte durch Clients Verwaltungs-Operationen in Component mit default-Implementierung

die nichts tut Leaf-Klassen sind damit zufrieden Composites müssen die


Leaf Klassen sind damit zufrieden, Composites müssen die Operationen passend implementieren.

Composite Pattern: Alternative Struktur (add / remove nicht in Component“)(add / remove nicht in „Component )

ComponentClient*

Component

operation()getChildren()

childrenClient

CompositeLeaf operation() {for all c in childrenc.operation()

}


(C t)

operation()getChildren()

}remove(Component)getChildren()

Component getChildren() {return null

}


Composite Pattern: Konsequenzen

Einheitliche Behandlung T il Teile Ganzes

Ei f h Cli t Einfache Clients Dynamisches Binden statt Fallunterscheidungen

L i ht E it b k it Leichte Erweiterbarkeit neue Leaf-Klassen neue Composite-Klassen p ohne Client-Änderung

Evtl. zu allgemeing Einschränkung der Komponenten-Typen schwer „run-time type checks“ (instanceof)



Das Visitor Pattern

Das Visitor Pattern

Absicht R ä t ti O ti f El t i Obj kt t kt Repräsentation von Operationen auf Elementen einer Objektstruktur Neue Operationen definieren, ohne die Klassen dieser Objekte zu ändern


Visitor Pattern: Motivation

Beispiel: Compiler thält Kl hi hi fü A d ü k i P i h enthält Klassenhierarchie für Ausdrücke einer Programmiersprache

Problem Code einer Operation (z.B. Typüberprüfung) ist über mehrere Klassen Code einer Operation (z.B. Typüberprüfung) ist über mehrere Klassen

einer Datenstruktur verteilt Hinzufügen oder ändern einer Operation erfordert Änderung der gesamten

HierarchieHierarchie

TypeCheck()GenerateCode()

Node

GenerateCode()PrettyPrint()

TypeCheck()GenerateCode()P tt P i t()

AssignmentNodeTypeCheck()GenerateCode()

i ()

VariableRefNode


PrettyPrint()PrettyPrint()

Visitor Pattern: Idee (1)

Visitor Kl di ll i it M th d f t di i i Klasse die alle visit...-Methoden zusammenfasst, die gemeinsam eine

Operation auf einer Objektstruktur realisieren Visit...-Methode

Ausprägung der Operation auf einem bestimmtem Objekttyp Hat Parameter vom entsprechenden Objekttyp

Kann somit alle Funktionalitäten des Typs nutzen um das zu besuchende Kann somit alle Funktionalitäten des Typs nutzen um das zu besuchende Objekt zu bearbeiten

VisitorvisitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)

visitAssignment(AssignmentNode)

TypeCheckingVisitorvisitAssignment(AssignmentNode)

CodeGeneratingVisitor


g gvisitVariableRef(VariableRefNode)

g gvisitVariableRef(VariableRefNode)

Visitor Pattern: Idee (2)

Accept-Methoden in allen Klassen der betroffenen Klassenhierarchie H b Vi it l P t Haben Visitor als Parameter

„Diese Operation soll auf mir ausgeführt werden!“ Rufen die jeweils zu ihnen passende visit...-Methode auf

„Diese Variante der Operation muss auf mir ausgeführt werden!“ Übergeben „this“ als Parameter

*

accept(NodeVisitor)

NodeProgram *

accept(NodeVisitor v)

AssignmentNode

accept(NodeVisitor v)

VariableRefNode

accept(NodeVisitor v) accept(NodeVisitor v)

v visitAssignment(this) v visitVariableRef(this)


v.visitAssignment(this) v.visitVariableRef(this)

Visitor Pattern: Schema (Statisch)

visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

VisitorClient

visitConcreteElementA(ConcreteElementA)

ConcreteVisitor1visitConcreteElementA(ConcreteElementA)

ConcreteVisitor2visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

accept(Visitor)

ElementObjectStructure *

accept(Visitor v)

ConcreteElementA

accept(Visitor v)

ConcreteElementB

accept(Visitor v)operationA()

accept(Visitor v)operationB()

v visitConcreteElementB(this)v visitConcreteElementA(this)


v.visitConcreteElementB(this)v.visitConcreteElementA(this)

Visitor Pattern: Verantwortlichkeiten / ImplementationImplementation

Objektstruktur-Hierarchie Ei h itli h t M th d Einheitliche accept-Methode

Visitor-Hierarchie Je eine visit-Methode für jede Klasse der Objektstruktur mit Parameter vom

Typ der jeweilige Klasse

Traversierung der Objektstruktur kann definiert sein in der besuchten Objektstruktur (Methode accept(...)) oder der besuchten Objektstruktur (Methode accept(...)) oder dem Visitor-Objekt (Method visit...(...))


Visitor Pattern: Zusammenarbeit

welche Operation auf welchem Objekt ... ist wie implementiert

:ObjectStructure a:ConcreteElementA b:ConcreteElementB v:ConcreteVisitor:ObjectStructure a:ConcreteElementA b:ConcreteElementB v:ConcreteVisitoraccept(v)

accept(v)visitConcreteElementA(a)

operationA()

accept(v) visitConcreteElementB(b)visitConcreteElementB(b)

ti B()operationB()


Double dispatch

Das Visitor Pattern: Konsequenzen

Hinzufügen neuer Operationen ist einfach. Neue Visitor Klasse Neue Visitor-Klasse

Hinzufügen neuer Objektklassen ist sehr aufwendig. Neue Objekt-Klasse Neue visit... - Methode in allen Visitors

Sammeln von Zuständen Visitor-Objekte können Zustände der besuchten Objekte aufsammeln und (evtl.

später) auswerten.p ) Eine Übergabe von zusätzlichen Parametern ist dafür nicht nötig.

Verletzung von Kapselung 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


Oft muss mehr preisgegeben werden als (ohne Visitor) nötig wäre.

Das Visitor Pattern: Anwendbarkeit

Funktionale Dekomposition Z hö i O ti ll f t d Zusammengehörige Operationen sollen zusammengefasst werden ... statt in einer Klassenhierarchie verteilt zu sein

Stabile Objekt-Hierarchiej selten neue Klassen aber oft neue Operationen

Heterogene Hierarchie viele Klassen mit unterschiedlichen Schnittstellen Operationen die von den Klassen abhängen Operationen die von den Klassen abhängen

Anwendungsbeispiel Java-Compiler des JDK 1.3


Das Visitor Pattern: Implementierung

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 T visitT(T)yp ( )

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 Jede konkrete visitT(T) Methode benutzt dabei die spezifischen

Operationen des besuchten Objekttyps T

Traversierung der Objektstruktur kann in der Objektstruktur (accept(...) Methoden) definiert sein


... oder im Visitor-Objekt (visit...(...) Methoden).


Gemeinsamkeiten und Unterschiede Gemeinsamkeiten und Unterschiede der Pattern

Abgrenzung: Facade, Singleton, Abstract Factory Factory

Facade V t kt S b t D t il (T d Obj kt ) Versteckt Subsystem-Details (Typen und Objekte)

Singleton Singleton Facaden sind meist Singletons (man braucht nur eine einzige)

Abstract Factory Zur Erzeugung konsistenter Sätze von Subsystem-Objekten Als Alternative zu Facade "Verstecken" plattform spezifischer Klassen Als Alternative zu Facade Verstecken plattform-spezifischer Klassen


Abgrenzung: Proxy, Decorator, Adpater

Proxy l i h I t f gleiches Interface kontrolliert Zugriff "Implementierungs-Detail" p g

Decoratorf erweitertes Interface

zusätzliche Funktionen „konzeptionelle Eigenschaft“„ p g

Adapter verschiedenes Interface ähnlich Protection-Proxy


Abgrenzung: Bridge, Adapter, Abstract FactoryFactory

Bridge ti i i t E tk l S h itt t ll d I l ti antizipierte Entkopplung von Schnittstelle und Implementierung

Adapterp nachträgliche Anpassung der Schnittstelle einer Implementierung

Abstract Factory nutzbar zur Erzeugung und Konfiguration einer Bridge


Abgrenzung: Factory / Template Method, Abstract Factory PrototypeAbstract Factory, Prototype

Factory Method V ö t E t h id üb di Kl i d Obj kt Verzögerte Entscheidung über die Klasse eines zu erzeugenden Objektes

Template Method Template Method ruft oft Factory Method auf

Abstract Factory gleiche Motivation gruppiert viele Factory Methods die zusammengehörige“ Objekte erzeugen gruppiert viele Factory Methods die „zusammengehörige Objekte erzeugen erzeugt feste Menge von Objekten von festen Obejkttypen

Prototype erfordert keine Unterklassenbildung dafür aber explizite initialize() Methode


... dafür aber explizite initialize()-Methode


„Patterns Create Architectures“

Ein Beispiel zum Zusammenspiel von Patterns Patterns

Bridge & Abstract Factory & Singleton

„Patterns Create Architectures“

Idee W P tt hlüb l t d t t t ht i Wenn man Patterns wohlüberlegt zusammen verwendet, entsteht ein

Grossteil einer Software-Architektur aus dem Zusammenspiel der Patterns.

Beispiel Zusammenspiel von Bridge, Factory und Singleton


Erinnerung ans Abstract Factory Pattern

WidgetFactory ClientcreateWindow()createScrollBar()

in der Praxis müssteWindow

in der Praxis müsste WidgetFactory ein

Singleton sein

createWindow()MotifWidgetFactory

createWindow()PMWidgetFactory PMWindow MotifWindow

createWindow()createScrollBar()

createWindow()createScrollBar()

Scrollbar

in der Praxis müsste hier das Bridge-

PMScrollbar MotifScrollBar

gPattern angewendet

werden

Erinnerung ans Bridge Pattern

Trennung von K t ll Hi hi

Implementierungs-Hierarchie

Konzeptueller Hierarchie

impClient


WindowImpdrawText()drawRect()

Window imp

devDrawLine()devDrawText()

XWindowImpdevDrawText()devDrawLine()

PMWindowImp

drawBorder()

IconWindow

drawCloseBox()

TransientWindow



Zusammenspiel: Bridge, Factory, SingletonSingleton

Client WidgetFactory<< konfiguriert >>

SingletonWidgetFactory.setFactory(WidgetFactory.MOTIF)WidgetFactory.getFactory()

PMWidgetFactorycreateWindow()createScrollBar()

MotifWidgetFactory

<< benutzt >>

WindowImpWindow imp

PMWindow MotifWindowIconWIndow TransientWindow

ScrollbarImpScrollbar imp

PMScrollbar MotifScrollBarFixedSB ProportionalSB


Rückblick: Was nützen Patterns?

Nutzen von Design Patterns (1)

Objekte / Klassen identifizieren Ab t kti di k i G tü k i d l W lt / d A l Abstraktionen, die kein Gegenstück in der realen Welt / dem Analyse-

Modell haben Beispiel:

Composite Pattern Abstraktionen von Prozessen Strategy Strategy State

"Strict modelling of the real world leads to a system that reflectst d ' liti b t t ill t ' Th b t ti th ttoday's realities but not necesarilly tomorrow's. The abstractions thatemerge during design are key to making a design flexible."



Granularität der Objekte festlegen F d Facade

ein "Riesen-Objekt" Flyweighty g

viele kleine, gemeinsam verwendbare Teilobjekte Builder

K iti G t Obj kt T il bj kt Komposition von Gesamt-Objekt aus Teilobjekten Visitor

Gruppe von konsistenten Aktionen Command

einzelne Aktion



Schnittstellen identifizieren hö t d was gehört dazu was gehört nicht dazu (Bsp. Memento)

Beziehungen zwischen Schnittstellen festlegen Subtyping

D t Decorator Proxy

Je eine Methode pro Klasse aus einer anderen Objekthierarchie Abstract Factory Builder Visitor



Wahl der Implementierung I t f Ab t kt Kl d k k t Kl Interface, Abstrakte Klasse oder konkrete Klasse

Grundthema fast aller Patterns Abstrakte Methode oder Hook Methode

von template method aufgerufene Methoden Overriding oder fixe Implementierung

Factory method Factory method Template method

Vererbung oder Subtyp-Beziehung Ad t D t St t St t C d Ch i f R ibilit Adapter, Decorator, State, Strategy, Command, Chain of Responsibility:

Gemeinsamer Obertyp, nicht gemeinsame Implementierung Vererbung oder Aggregation

Vererbung ist statisch Es wird oft mehr vererbt als gewünscht Beispiel: alle "split object patterns"


Nutzen von Design Patterns (5):

Patterns verkörpern Grundprinzipien guten Designs

Implementierungen austauschbar machen Typdeklarationen mit Interfaces statt mit Klassen Design an Interfaces orientieren nicht an Klassen Design an Interfaces orientieren, nicht an Klassen Client-Code wiederverwendbar für neue Implementierungen des gleichen

Interface

Objekt-Erzeugung änderbar gestalten "Creational Patterns" statt "new MyClass()" Client-Code wiederverwendbar für neue Implementierungen des gleichen

I t fInterface

Funktionalität änderbar gestalten A ti d F di t tt V b Aggregation und Forwarding statt Vererbung späte Konfigurierbarkeit, Dynamik weniger implizite Abhängigkeiten (kein "fragile base class problem")


Nichtfunktionale Anforderungen geben Hinweise zur Nutzung von Entwurfsmustern (Design Patterns)g ( g )

Identifikation von Entwurfsmustern anhand von Schlüsselwörtern in der Beschreibung nichtfunktionaler AnforderungenBeschreibung nichtfunktionaler Anforderungen Analog zu Abbot’s Technik bei der Objektidentifikation

Facade Pattern „muss mit einer Menge existierender Objekte zusammenarbeiten”, „stellt Dienst bereit“

Adapter Pattern Adapter Pattern „muss mit einem existierenden Objekt zusammenarbeiten”

Bridge Pattern „muss sich um die Schnittstelle zu unterschiedlichen Systemen kümmern

von denen einige erst noch entwickelt werden.“


g „ein erster Prototyp muss vorgeführt werden“

Nichtfunktionale Anforderungen geben Hinweise zur Nutzung von Entwurfsmustern (Fortsetzung)g ( g)

Proxy Pattern “ t t t i ” “muss ortstransparent sein”

Observer Pattern “muss erweiterbar sein”, “muss skalierbar sein” muss erweiterbar sein , muss skalierbar sein

Strategy Pattern “muss Funktionalität X in unterschiedlichen, dynamisch auswählbaren

A ä b it t ll kö ”Ausprägungen bereitstellen können” Composite Pattern

“komplexe Struktur” komplexe Struktur “muss variable Tiefe und Breite haben”

Abstract Factory Pattern “Herstellerunabhängig”, “Geräteunabhängig”, “muss eine Produktfamilie unterstützen”


muss eine Produktfamilie unterstützen

Überblick

Einführung G did Lit t MVC F k l B i i l Grundidee, Literatur, MVC-Framework als Beispiel

Beispiele wichtiger Patterns Observer, Strategy, Command Observer, Strategy, Command Facade, Singleton, Proxy, Adapter, Bridge Factory Method, Abstract Factory

C Composite, Visitor Patterns Create Architectures

Bridge Abstract Factory Singleton Bridge, Abstract Factory, Singleton Nutzen von Patterns Zusammenfassung und Ausblick

Arten von Patterns, Abgrenzung Weiterführende Themen


Arten von Patterns

Analysis Pattern Wi d k h d P bl i d A l h i S ft j kt Wiederkehrende Problemen in der Analysephase eines Softwareprojekts Martin Fowler: "Analysis Patterns", Addison-Wesley, 1997

Architecture Pattern ... beschreibt mögliche fundamentale Strukturen von Softwaresystemen. ... enthält vordefinierte Subsysteme und ihre Verantwortlichkeiten.

f O ... enthält Regeln und Richtlinien für die Organisation ihrer Beziehungen. Beispiel: Model-View-Controller

Design PatternDesign Pattern Schema für die Realisation von Subsystemen oder Komponenten eines

Softwaresystems Idi ( h C di P tt ) Idiom (auch: Coding Pattern)

Low-level design patterns für eine gegebene Programmiersprache. Beispiel: Wie stelle ich sicher, dass eine Instanz einer Java-Klasse nur


p ,innerhalb einer bestimmten anderen Klasse erzeugt werden kann?

Weitere Arten von Pattern

Organizational Patterns St kt d P i O i ti l G di i Struktur und Praxis von Organisationen; also Gruppen, die ein

gemeinsames Ziel verfolgen http://www.bell-labs.com/cgiuser/

OrgPatterns/OrgPatterns?OrganizationalPatterns

Anti-Patterns beschreiben typische Fehler ... und bestenfalls auch wie man sie wieder beseitigt


Abgrenzung: Patterns versus Algorithmen

Konkretheit Al ith lö k k t P bl i A d b i ht ( B Algorithmen lösen konkrete Probleme im Anwendungsbereicht (z.B.

Suchen, Sortieren) Pattern lösen generische Entwurfsprobleme (Dynamik, Wartbarkeit, ...)

Vollständigkeit Algorithmen sind vollständig Komplexität genau ermittelbar Algorithmen sind vollständig Komplexität genau ermittelbar Pattern sind „nur“ Schablonen


Abgrenzung

Framework M k i d Kl fü i ifi h 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)

Pattern versus Frameworks Patterns sind abstrakter

Frameworks existieren als konkreter, wiederverwendbarer Code Patterns sind nur Schablonen für Code

Patterns sind nicht anwendungsabhängigg g g Frameworks werden für konkrete Anwendungsbereiche eingesetzt Patterns sind anwendungsunabhängig

Frameworks nutzen Patterns


Frameworks nutzen Patterns

Weiterführende Themen

Pattern Catalogs S l l hä d P tt Sammlungen von lose zusammenhängenden Patterns

Pattern Systems y Sammlungen von stark zusammenhängenden Patterns mit engen

Verzahnungen

Pattern Languages verfolgen ein gemeinsames Ziel, dass durch die Zusammenarbeit der g g

enthaltenen Patterns erreicht werden kann inkl. einer Art "Grammatik", die alle mögliche Kombinationen aufzeigt


Pattern: Zusammenfassung

Betonung von Praktikabilität P tt i d b k t Lö fü i ß i d k h d Patterns sind bekannte Lösungen für erwiesenermaßen wiederkehrende

Probleme Lösungen, die sich noch nicht in der Praxis bewährt haben, sind keine

Pattern.

Patterns sind kein Allheilmittel 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 eingesetzt

werden.

Gesamteffekt Gesamteffekt Aufgabe des Softwarearchitekten verlagert sich von der Erfindung des

Rades zur Auswahl des richtigen Rades und seiner kreativen Anwendung


Documents

Kapitel 6 Entwurfsmuster (“Design Patterns”) · Beobachter müssen sich die Informationen vom Subjekt holen + Geringere Kopplung zwischen Subjekt und Beobachter. –Bh dhäfidhfühtBerechnungen