kapitel 6 entwurfsmuster (design patterns) · das observer pattern: einführung zabsicht stellt...

Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel

Kapitel 6

Entwurfsmuster (Design Patterns)

Stand: 27.11.2007

© 2000-2007 Dr. Günter Kniesel

Einführung: Die Grundidee von Pattern

Pattern (Muster) wurden zuerst im Bereich der Architektur beschrieben.

Grundlegende Idee: Alle Ingenieurdisziplinen benötigen eineGrundlegende Idee: Alle Ingenieurdisziplinen benötigen eine Terminologie ihrer wesentlichen Konzepte sowie eine Sprache, die diese Konzepte in Beziehung zueinander setzt.

Ziele von Pattern in der Welt der Software:Dokumentation von Lösungen wiederkehrender Probleme umDokumentation von Lösungen wiederkehrender Probleme, um Programmierer bei der Softwareentwicklung zu unterstützen. Schaffung einer gemeinsamen Sprache, um über Probleme und ihre Lö hLösungen zu sprechen.Bereitstellung eines standardisierten Katalogisierungsschemas um erfolgreiche Lösungen aufzuzeichnen.

Bei Pattern handelt es sich weniger um eine Technologie (wie z.B. bei UML) als um eine Kultur der Dokumentation und Unterstützung guter

Vorlesung Softwaretechnologie, Wintersemester 2007/8 06-2 R O O T S

UML), als um eine Kultur der Dokumentation und Unterstützung guter Softwarearchitektur.

Einführung: Literatur zu Pattern und SoftwareErich Gamma Richard Helm Ralph Johnson John Vlissides (Gang of Four):Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four):"Design Patterns - Elements of Reusable Object-Oriented Software"Addison-Wesley, 1995

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

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

Patterns im WWWPatterns Home Page: http://www.hillside.net/g pPortland Pattern Repository: http://c2.com/ppr/index.htmlBrad Appleton: "Patterns and Software: Essential Concepts and Terminology„ http://www.bradapp.net/docs/patterns-intro.htmlp pp pDoug Lea, Patterns-Discussion FAQ, http://gee.oswego.edu/dl/pd-FAQ/pd-FAQ.htmlBuchliste: http://c2.com/cgi/wiki?PatternRelatedBookList


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

a = 50%b = 30% Modelc = 20%

- X - X

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

View + Controller View + Controller



a = 50%b = 30%c = 20%Änderungen am

Modell werden propagiertpropagiert

- X - X

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



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

- X - X

a = 50%

- X

b = 30%c = 20%

• mehrere Views sind gleichzeitig möglich• neue Views können ohne Änderung des Modells hinzugefügt werden


• neue Views können ohne Änderung des Modells hinzugefügt werden


Propagierung von Änderungen: Observer Patternkommt z.B. auch bei Client/Server-Programmierung

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

zur Benachrichtigung der Clients zum Einsatz- X

- XGeschachtelte Views: Composite Pattern

View enthält weitere Views, wird aber wie ein einziger View behandelteinziger View behandelt.kommt z.B. auch bei Parsebäumen im Compilerbauzum Einsatz (Ausdrücke).

Reaktion auf Events im Controller: Strategy PatternEingabedaten können validiert werden - XEingabedaten können validiert werden (Daten, Zahlen, etc.).Controller können zur Laufzeit gewechselt werden.


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

Überblick

Einführung Grundidee, Literatur, MVC-Framework als Beispiel

Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandFacade, Singleton, Proxy, Adapter, BridgeFactory Method, Abstract FactoryComposite, Visitor

Patterns Create ArchitecturesPatterns Create ArchitecturesBridge, Abstract Factory, Singleton

Nutzen von PatternsZusammenfassung und Ausblick

Arten von Patterns, AbgrenzungWeiterführende Themen


Das Observer Pattern: Einführung

AbsichtStellt eine 1-zu-n Beziehung zwischen Objekten herWenn das eine Objekt seinen Zustand ändert, werden die davon abhängigen Objekte benachrichtigt und entsprechend aktualisiert

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

MotivationVerschiedene Objekte sollen zueinander konsistent gehalten werdenVerschiedene Objekte sollen zueinander konsistent gehalten werdenAndererseits sollen sie dennoch nicht eng miteinander gekoppelt sein. (bessere Wiederverwendbarkeit)

Diese Ziele stehen in einem gewissen Konflikt zueinander. Man spricht von „conflicting forces“, also gegenläufig wirkenden Kräften.


g g g g

Das Observer Pattern: Beispiel

Trennung von Daten und DarstellungWenn in einer Sicht Änderungen vorgenommen werden, werden alle anderen Sichten aktualisiert – Sichten sind aber unabhängig voneinander.

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

- X - X- X

a = 50%b = 30%

20%


c = 20%

Das Observer Pattern: Anwendbarkeit

Das Pattern ist im folgenden Kontext anwendbar:

AbhängigkeitenEin Aspekt einer Abstraktion ist abhängig von einem anderen Aspekt. Aufteilung dieser Aspekte in verschiedene Objekte erhöht Variationsmöglichkeit und Wiederverwendbarkeit.

FolgeänderungenÄnderungen an einem Objekt erfordert Änderungen an anderen Objekten. E i t i ht b k t i i l Obj kt ä d t d üEs ist nicht bekannt, wieviele Objekte geändert werden müssen.

Lose Kopplungpp gObjekte sollen andere Objekte benachrichtigen können, ohne Annahmen über die Beschaffenheit dieser Objekte machen zu müssen.


Das Observer Pattern: Struktur


Rollenaufteilung / Verantwortlichkeiten

Observer („Beobachter“ auch: Subscriber, Listener)update (auch: handleEvent)

Reaktion auf Zustandsänderung des Subjects

Subject („Subjekt“ auch: Publisher)attach(auch: register addListener)attach(auch: register, addListener)

Observer registrierendetach (auch: unregister, removeListener)

registrierte Observer entfernennotify

update-Methoden aller registrierten Observer aufrufenp g

setStatezustandsändernde Operation(en)zustandsändernde Operation(en)für beliebige Clients

getStatebf d kt ll Z t d


abfrage des aktuellen Zustandsdamit Observer feststellen können was sich genau geändert hat

Das Observer Pattern: Zusammenarbeit der Objekte


Das Observer Pattern: KonsequenzenUnabhängigkeitUnabhängigkeit

„Subjekte“ und „Beobachter“ können unabhängig voneinander variiert werden.„Beobachter“ können hinzugefügt werden, ohne „Subjekte“ oder andere Beobachter“ zu ändern„Beobachter zu ändern.

„Subjekte“ können ohne „Beobachter“ wiederverwendet werden. Umgekehrt ebenfalls.

„Broadcast“-NachrichtenSubjekt benachrichtigt alle angemeldeten BeobachterB b ht t h id b i N h i ht b h d l d i iBeobachter entscheiden, ob sie Nachrichten behandeln oder ignorieren

Abstrakte KopplungSubjekte aus tieferen Schichten eines Systems können mit Beobachtern aus höheren Schichten kommunizieren, ohne die Schichten zu verletzen.

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


auslösen.

Das Observer Patterns: Implementierung

Speicherung der Beziehung zwischen Subjekt und BeobachterInstanzvariable im Subjekt oder ...globale (Hash-)Tabelleglobale (Hash )Tabelle

Beobachtung mehrer SubjekteDie graphische Darstellung einer Tabelle könnte mehrere Subjekte beobachten. Dann muss die „update()“-Methode einen zusätzlichen Parameter haben, der das Subjekt angibt.

Wer ruft "notify()" auf?) " tSt t ()" M th d d S bj kta) "setState()"-Methode des Subjekts:

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

b) Klienten:+ Mehrere Änderungen können akkumuliert werden.


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

Implementierung des Observer Patterns

KonsistenzZustand eines Subjekts muss vor Aufruf von "notify()" konsistent sein.Vorsicht bei Vererbung bei Aufruf jeglicher geerbert Methoden die möglicherweise „notify()“ -aufrufen :

public class MySubject extends Subject {public void doSomething(State newState) {

d S thi ( St t ) // ft " tif ()" fsuper.doSomething(newState); // ruft "notify()" auf

this.modifyMyState(newState); // zu spät!}

}}

Dokumentation von „notify()“-Aufrufen erforderlich„ y()Besser: In Oberklsse „Template-Method Pattern“ anwenden um sicherzustellen, dass „notify()“-Aufrufe immer am Schluß einer Methode stattfinden


stattfinden.


Wie werden die Informationen über eine Änderung weitergegeben: h“ ll“„push“ vs. „pull“

push: Subjekt übergibt in „update()“ detaillierte Informationen über Änderungen.p j g p () g+ Berechnungen werden seltener durchgeführt.– Beobachter sind weniger wiederverwendbar

pull: Subjekt übergibt in „update()“ keinerlei Informationen, aber die Beobachter müssen sich die Informationen vom Subjekt holen

+ Geringere Kopplung zwischen Subjekt und Beobachter.– Berechnungen werden häufiger durchgeführt.

Zwischenformen sind möglich



Fortgeschrittene Techniken

Differenzierung von EreignissenDifferenzierung von EreignissenBeobachter-Registrierung nur für spezielle Ereignisseweniger "Rückfragen" / höhere Effizienz

ChangeManagerlt t B i h i h S bj kt d B b htverwaltet Beziehungen zwischen Subjekt und Beobachter.

(Speicherung in Subjekt und Beobachter kann entfallen.)definiert die Aktualisierungsstrategiebenachrichtigt alle Beobachterverzögerte Benachrichtigung möglich

Insbesondere wenn mehrere Subjekte verändert werden müssen bevor dieInsbesondere wenn mehrere Subjekte verändert werden müssen, bevor die Aktualisierungen der Beobachter Sinn macht


Das Observer Patterns: Bekannte Anwendungen

Bekannte AnwendungenModel-View-Controller-Framework in SmalltalkJava Foundation Classes / SwingOberon SystemDiverse Client/Server Modelle z B Java RMIDiverse Client/Server-Modelle, z.B. Java RMI



Propagierung von Änderungen: Observer Patternkommt z.B. auch bei Client/Server-Programmierung

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

zur Benachrichtigung der Clients zum Einsatz- X

- XGeschachtelte Views: Composite Pattern

View enthält weitere Views, wird aber wie ein einziger View behandelteinziger View behandelt.kommt z.B. auch bei Parsebäumen im Compilerbauzum Einsatz (Ausdrücke).

Reaktion auf Events im Controller: Strategy PatternEingabedaten können validiert werden - XEingabedaten können validiert werden (Daten, Zahlen, etc.).Controller können zur Laufzeit gewechselt werden.


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

Vorlesung Softwaretechnologie 2007/8Kapitel 4: Design Patterns R O O T Sap te es g atte s

Let's play patterns!

Aufgabe

IntegerBagMenge von integers

IntegerAdderAddiert alles was sich im Bag befindet und gibt Ergebnis aus

I t P i tIntegerPrinterGibt den kompletten Inhalt eines IntegerBag aus


Mögliche Lösung

Siehe http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html


Das Strategy Pattern: Einführung

AbsichtKapselung einer Familie von Algorithmen mit der Möglichkeit, sie beliebig auszutauschen.

MotivationBerechnung von ZeilenumbrüchenBerechnung von Zeilenumbrüchen

mehrere Algorithmen können eingesetzt werdenneue Varianten sollen später hinzugefügt werden können

S (f )Struktur (für obiges Beispiel)


Das Strategy Pattern: Anwendbarkeit und Struktur

Anwendbar in folgendem KontextEinige ähnliche Klassen unterscheiden sich nur in gewissen Aspekten des Verhaltens. Diese können in ein Strategie-Objekt ausgelagert werden.g j g gVerhalten ist abhängig von äußeren RandbedingungenVerschiedene Varianten eines Algorithmus werden benötigt

B it t hi dli h Z it /Pl t k l itätz.B. mit unterschiedlicher Zeit-/Platzkomplexität.Kapselung von Daten eines komplexen Algorithmus

Struktur (allgemein)


Das Strategy Pattern: Implementierung

Alternative Schnittstellen zwischen Kontext und Strategien1. Kontext übergibt alle relevanten Daten an die Strategie-Methode2. Kontext übergibt this an Strategie-Methode flexibelste Lösung3. Strategie-Objekt speichert bei Initialisierung feste Referenz auf Kontext

Implementierung von Default-Verhalten möglichIn der Kontext-Klasse wird ein Default-Verhalten verwendet, wenn kein Strategie-Objekt gesetzt ist.

(T1,...,Tn)(Context)

default


(T1,...,Tn) (T1,...,Tn) (T1,...,Tn)(Context) (Context) (Context)

Implementierung: Fallunterscheidung in Kontext

ContextInterface() {if ( ll)

...if (strategy == null)

... default ...else strategy.AlgorithmInterface();

}

Vorteile???

NachteileUneinheitliche Lösung: Kontext muss Default-Strategie kennen


Implementierung: „Default-Strategie“-Klasse

ContextInterface() {...

...strategy.AlgorithmInterface();...

}

AlgorithmInterface() {d f lt

Dies Variante ist als das "Null Pattern"

bekannt.

Dies Variante ist als das "Null Pattern"

bekannt.

Dies ist eine Anwendung des "Null Object Pattern"

Ideejede Zuweisung "Strategy s = null;" ersetzen durch "Strategy s = new DefaultStrategy();"

... default ...}

Abfragen auf null und entsprechende Fallunterscheidungen löschenVorteile

einheitliche Lösung, klare Trennung von Kontext und Strategien


einheitliche Lösung, klare Trennung von Kontext und Strategien lesbarerer Code

Das Strategy Pattern: Konsequenzen

KonzeptuellFamilie von zusammengehörigen AlgorithmenAuswahl verschiedener Implementierungen desselben Verhaltensdynamische Alternative zu UnterklassenbeziehungPolymorphismus statt Fallunterscheidungen (if then else switch case)Polymorphismus statt Fallunterscheidungen (if-then-else, switch-case)leichtere Erweiterbarkeit

Konsequenzen aus ImplementierungKontext übergibt evtl. Parameter, die nicht jedes Strategie-Objekt benötigt

thi üb b i t ll ithis zu übergeben ist allgemeinerZusätzliche Nachrichten zwischen Kontext und Strategie Erhöhte Anzahl an Objekten

Möglicherweise können aber Strategie-Objekte gemeinsam verwendet werdenFlyweight-Pattern



Zwischenfazit: Was also sind Patterns?

Definition: Was ist jetzt also ein Pattern?

Definitionsvorschlag

"A pattern is the abstraction from a concrete formwhich keeps recurring in specific non-arbitrary contexts."which keeps recurring in specific non arbitrary contexts.

Dirk Riehle, Heinz Züllighoven:"Understanding and Using Patterns in Software Development",

TAPOS 2, 1 (1996).( )

Definitionsvorschlag

"Each pattern is a three-part rule, which expresses a relation between a certain context,p ,

a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve

themselves "


themselves.Richard Gabriel, on the Patterns Home Page

Aber nicht...

"A pattern is a solution to a problem in a context."anonym ;-)

GegenbeispielProblem: Wie werden Objekte im Speicher alloziert?K t t Ei ß OO S t i i R h it i t llKontext: Ein großes OO-System in einem Rechner mit virtuellem Speicher.Lösung: Führe einige typische Anwendungen durch und stelle fest, g g yp g ,welche Objekte häufig miteinander kommunizieren. Plaziere diese Objekte auf derselben Seite im virtuellen Speicher.

BegründungDas ist kein Pattern - es ist "nur" eine Lösung für ein Problem in einem Kontext. Damit es zu einem Pattern werden kann, muss ein Lösungsprinzip abstrahiert werden das auch für andere wiederkehrende Probleme in


abstrahiert werden, das auch für andere wiederkehrende Probleme in ähnlichen Kontexten eingesetzt werden kann.

Bestandteile eines Patterns: Kontext, Problem, Forces

KontextDie Vorbedingungen unter denen das Pattern benötigt wird. ( Anwendbarkeit des Pattern)( Anwendbarkeit des Pattern)

ProblemBeschreibung des Problems oder der Absicht des PatternsZiel und gewünschte Eigenschaften die in einem bestimmten Kontext mit bestimmten Randbedingungen/Kräften erreicht werden sollen. Die Kräfte und die Ziele scheinen sich zu widersprechen.

Randbedingung / Kräfte (Forces)Randbedingung / Kräfte (Forces)Die relevanten Randbedingungen und Einschränkungen, die berücksichtigt werden müssen.Wi di it i d i t i d i K flikt t hWie diese miteinander interagieren und im Konflikt stehen.Die daraus entstehenden Kosten.Typischerweise durch ein motivierendes Szenario illustriert.


Bestandteile eines Patterns: Lösung

Die Lösung wird beschrieben durch die Teilnehmer, ihre Rollen, ihre statischen Beziehungen und dynamische Zusammenarbeitg y

TeilnehmerDie Typen (Interfaces und Klassen) die in der Lösung eine Rolle spielen.

RollenAlle Namen in der Beschreibung eines Patterns bezeichnen nur die Rollen der entsprechenden Interfaces, Klassen, Methoden, Felder, Assotiationen.p , , , ,Sie werden bei der Implementierung durch zur Anwendung und Rolle passende Namen ersetztBeispiel: RolleBeispiel: Rolle

Statische Beziehungen und dynamische ZusammenarbeitKlassendiagramm, dynamisches Diagramm, TextMeistens ist das Verständnis des dynamischen Verhaltens entscheidendDenken in Objekten (Instanzen) statt Klassen (Typen)!


Übersicht aller Bestandteile eines Patterns

Name des PatternsProblem, das vom Pattern gelöst wirdgKontext, in dem das Pattern angewendet werden kannRandbedingungen/Kräfte (forces), die das Pattern beeinflussenLösung. Beschreibung, wie das gewünschte Ergebnis erzielt wirdBeispiele der Anwendung des PatternsR lti d K t t d A d d P ttResultierender Kontext aus der Anwendung des PatternsErläuterung (rationale), warum das Pattern funktioniertBezug zu anderen PatternsBezug zu anderen PatternsBekannte Verwendungen des Patternsoptional: Zusammenfassung (auch: "pattern thumbnail")g ( )

(Es wurden auch andere Schemata für die Beschreibung von Pattern definiert Dieses hier ist recht ausführlich )


von Pattern definiert. Dieses hier ist recht ausführlich.)


Wichtige Design Patterns

StrukturVerhalten

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

VisitorObserver

CompositeFlyweight

CommandTemplate MethodCh i f R ibilit

y g

Bisher Chain of Responsibility

StateDecoratorProxy

Bisher

JetztStrategyMultiple Vererbung

yAdapterBridgeF d

Jetzt

Facade

Split Objects

FactoryFactory Method

PrototypeSingleton


Objekt-Erzeugung

Factory MethodBuilder

Singleton

Erläuterung zur Klassifikation

Verhaltens-PatternsVerhalten leicht erweiterbar, komponierbar, dynamisch änderbar oder explizit manipulierbar machen

Struktur-PatternsObjekte mit fehlendem Zustand rekursive StrukturenObjekte mit fehlendem Zustand, rekursive StrukturenVerschiedenste Formen der Entkopplung (Schnittstelle / Implementierung, Identität / physikalische Speicherung, ...)

Split Object PatternsZiel: Dynamisch änderbares Verhalten, gemeinsame Verwendung oder Entkopplung von Teilobjektenpp g jWeg: Aufteilung eines konzeptionellen Gesamtobjektes in modellierte Teilobjekte die kooperieren um das Verhalten des konzeptionellen Gesamtobjektes zu realisierenGesamtobjektes zu realisieren

Erzeugungs-PatternsFlexibilität indem die Festlegung von konkret zu erzeugenden Objekte ( XYZ()) it i ö li h ö t i d d tl L f it


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

Selbsttest

Ordnen Sie beim Nacharbeiten die auf der vorherigen Folie genannten Ziele den Ihnen dann

bekannten Patterns zu!bekannten Patterns zu!

Diskutieren Sie ihre Einschätzung mit Ihren Kollegen!



Das Facade Pattern

Facade Pattern

AbsichtMenge von Interfaces eines Subsystems zusammenfassenAbhängigkeiten der Clients von der Struktur des Subsystems reduzieren

client classes client classes

subsystem Facade

subsystem yclasses

yclasses

Motivation / BeispielCompiler mit Subsystemen

Scanner


...CodeGenerator

Facade Pattern: Beispiel

compilersubsystem

Compiler

compile()

Stream

subsystemclasses

Scanner Token

compile()

Parser Symbol

BytecodeStream ProgramNodeBuilder ProgramNode

CodeGenerator ExpressionNodeStatementNode VariableNode

StackMachineCodeGen. RISCCodeGenerator


Facade Pattern: Anwendbarkeit

einfaches Interface zu einem komplexen Subsystemeinfache Dinge einfach realisierbar (aus Client-Sicht)anspruchsvolle Clients dürfen auch "hinter die Facade schauen"

zB für seltene, komplexe Anpassungen des Standardverhaltens

viele Abhängigkeiten zwischen Klassenreduzieren durch Facade-Objekte

hierarchische Strukturierung eines Systemi F d l Ei ti kt i j d Ebeine Facade als Einstiegspunkt in jede Ebene


Facade Pattern

Implementierung: Konfigurierbarkeit einer Facadeeigene Facade-Subklasse pro Konfiguration

oder andere Subsystem-Objekte instantiieren

Abgrenzung: SingletonFacaden sind meist Singletons (man braucht nur eine einzige)g ( g )

Abgrenzung: Abstract Factoryzur Erzeugung konsistenter Sätze von Subsystem-Objektenals Alternative zu Facade "Verstecken" plattform-spezifischer Klassen



Das Singleton Pattern

Singleton: Motivation

Beschränkung der Anzahl von Exemplaren zu einer Klasse

Meist: nur ein einzelnes ExemplarZ.B. Facade, Repository, System, Factory (vgl. Abstract Factory)

Aber auch: festen Menge von ExemplarenMotivation 1: begrenzte RessourcenMotivation 1: begrenzte Ressourcen.Motivation 2: Teure Objekterzeugung durch „Object Pool“ vermeiden

z.B. 1000 Enterprise Java Beans vorhalten, nach Nutzung zurück in den Poolden Pool


Singleton: Struktur + ImplementierungBesitzt keinen öffentlichen Konstruktor:

Singleton

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

}private Singleton(...) { Liefert eine Instanz (typischerweise immer die

getInstance()instanceOperation()

-instancePooli t D t

...}

Liefert eine Instanz (typischerweise immer die Selbe):

public static Singleton getInstance() {if (instancePool == null)

-instanceDataSpeichert die einzige Instanz oder begrenzte Menge an Instanzen

( )instancePool = new Singleton();

return instancePool;}

Kein öffentlicher Konstruktordadurch wird verhindert, dass Clients beliebig viele Instanzen erzeugen g gkönnenin Java muss explizit ein nicht-öffentlicher Konstruktor mit leerer Argumentliste implementiert werden, damit kein impliziter öffentlicherg p , pKonstruktor vom Compiler erzeugt wird

instancePool als Registry für alle Singleton-Instanzenl k M h i f d li h i lt i I t ähl


lookup-Mechanismus erforderlich um gezielt eine Instanz auszuwählen


Das Adapter Pattern

Adapter Pattern (auch: Wrapper)

AbsichtSchnittstelle existierender Klasse an Bedarf existierender Clients anpassen

Motivation Graphik-Editor bearbeitet Shapes

Li i R ht kLinien, Rechtecke, ...durch "BoundingBox" beschrieben

Textelemente sollen auch möglich seinKlasse TextView vorhandenbietet keine "BoundingBox"-Operation

Integration ohnegÄnderung der gesamten Shape-Hierarchie und ihrer ClientsÄnderung der TextView-Klasse

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


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): Schema

Target

request()

Adapteeother()

Clientadaptee

f()q ()f()

Adapter

f()

Adapterrequest()

f()adaptee.other()

Adaptee_N ……

:Adapter:Client :Adaptee_N

request()request()other()

f()


Adapter Pattern (Objekt-Adapter): Konsequenzen

Target

request()

Adapteeother()

Clientadaptee

f()q ()f()

Adapter

f()

Adapterrequest()

f()adaptee.other()

Adaptee_N ……

Adaptiert eine ganze Klassenhierarchie B li bi Ad t S bt kö it b li bi Ad t S btBeliebige Adapter-Subtypen können mit beliebigen Adaptee-Subtypen kombiniert werden ( siehe Objektdiagram auf vorheriger Folie)Kombination wird erst zur Laufzeit, auf Objektebene, festgelegt

Overriding nicht möglichDie f()-Definition aus Adapter wird nicht anstelle der f()-Definition aus Adaptee für den f()-Aufruf aus der Methode other() verwendet


Adaptee für den f() Aufruf aus der Methode other() verwendet( siehe Objektdiagram auf vorheriger Folie)

Adapter Pattern (Object Adapter): Variante

Target

request()

Adapteeother()

Clientadaptee

f()q ()f()

Adapter

f()

Adapterrequest()

f()

Adaptee_N ……

Ad t N‘ ‘‘f()f() f()

Adaptee_N‘ …‘…‘

Object Adapter mit Overridingzu Adapteee und jede Unterklasse des Adaptees eine weitere Unterklasse

i fü i di d d fi i t V h lt i fü t i d ( l B f())einfügen, in die das redefinierte Verhalten eingefügt wird (also z.B. f())Warum neue Unterklassen? Weil die Adaptee-Hierarchie nicht veränderbar ist!

Problem: Redundanz!


Was konzeptionell nur ein mal in Adapter stehen sollte wird in jeder neuen Unterklasse von Adaptee redundant eingefügt Wartungsprobleme!

Class Adapter Idiom: Schema„Vererbung ohne Subtyping“:

Erbender erbt Methoden die nicht als Teil seines Interface sichtbar werden.

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

Target

()

Adapteeth ()

Client

request() other()f()

f()

<<implementation inheritance>>

Adapterrequest()

f()

Adaptee_N ……

anAdaptedAdaptee:Adapter:Client

f()

p p p:Client

request() other()

f()


f()

Class Adapter Idiom: Konsequenzen

T t Ad tCli t Target

request()

Adapteeother()

f()

Client

f()

AdapterAdaptee N


request()f()

Adaptee_N ……

Overriding des Adaptee Verhaltens leicht möglich


Overriding des Adaptee-Verhaltens leicht möglichDa Adapter eine Unterklasse von Adaptee ist, funktioniert das Overridingvon f()

Keine zusätzliche Indirektionnur ein Objekt statt zwei

Adaptiert nur eine Klasse


Adaptiert nur eine Klassenicht ihre Unterklassen

Adapter Pattern: Konsequenzen

Class Adapteradaptiert nur eine Klasse

Targetrequest()

Adapteef()

m()

Client

AdapterAdapt N

... nicht ihre UnterklassenOverriding des Adaptee-Verhaltens leicht möglichkeine zusätzliche Indirektion (nur ein Objekt)

request()

:Adapter:Client :Adaptee

Adapt_Nf()

m()

keine zusätzliche Indirektion (nur ein Objekt)

Object Adapter

:Adapter:Client :Adaptee

jadaptiert eine ganze KlassenhierarchieOverriding schwieriger

d fi i t V h lt i ifi h U t kl d Ad t i füredefiniertes Verhalten in spezifische Unterklasse des Adaptees einfügenAdapter benutzt diese UnterklasseKombinierbarkeit mit anderen Unterklassen geht verloren

Object Adapter mit Delegation (roots.iai.uni-bonn.de/research/darwin)adaptiert eine ganze Klassenhierarchie


adaptiert eine ganze KlassenhierarchieOverriding des Adaptee-Verhaltens leicht möglich

Class Adapter Idiom: Schema

TargetClient„Vererbung ohne Subtyping“:

request()"private inheritance" in C++

oder"closed inheritance" in Eiffel

Adaptee


specificRequest()

Adapter

req est()request() specificRequest()




Zweiweg-Adapter ("Two-way adapters")

Adapter soll auch das Adaptee-Interface erfüllen Beispiel: QOCA (constraint solving toolkit) und Unidraw (Graphischer editor)Explizite Variablen-Repräsentation in beiden SystemenIntegration erfordert Zwei-Weg-AdapterIntegration erfordert Zwei Weg Adapter

Implementierungmultiple Vererbung

lti l D l ti

(QOCA class hierarchy) (Unidraw class hierarchy)

multiple DelegationEinfach-Vererbung und einfach-Delegation

ConstraintVariable StateVariable

(QOCA class hierarchy) (Unidraw class hierarchy)

ConstraintStateVariable


ConstraintStateVariable

Adapter Pattern: Konsequenzen (2)

Aufwand des Adapterseinfache Namens-Anpassung

show() --> print()beliebiges anderes Interface

ganz andere Semantikganz andere Semantik


Adapter Pattern: Anwendbarkeit

Nachträgliche AnpassungSchnittstelle einer existierenden Klasse anpassen

Bisherige Adpater-VariantenVorausschauend Anpassungs-Möglichkeit einbauen

Kl t f d i b k t Cli t b t t dKlasse so entwerfen, dass sie von unbekannten Clients benutzt werden kann, die andere Interfaces erwarten

„Pluggable Adapters“


Adapter Pattern: Pluggable Adapters

Motivation TreeDisplay soll beliebige Baumstrukturen darstellenBeispiel: Datei-Hierarchie, Vererbungs-Hierarchie

IdeeIdeeSchnittstellen-Anpassbarkeit in TreeDisplay "einbauen"Minimales Interface identifizieren das TreeDisplay von den angezeigten p y g gEntities kennen mussAdaptierbarkeit dieses Interface an verschiedene Hierarchien vorsehen

ImplementierungsvariantenVererbungSimulierte DelegationParametrisierung mit "Blöcken"


a) Pluggable Adapter mit Vererbung und Abstrakten Operationen

<<Client, Target>>TreeDisplay

getChildren (Node)

Anpassungs-Interface ist Teil des TreeDisplayAbstrakte Methodeng ( )

createGraphicNode(Node)display()buildTree (Node n)

Adapter sind Unterklassen von TreeDisplay

<<Adapter>>DirectoryTreeDisplay

<<Adaptee>>FileSystemEntity

getChildren (Node)createGraphicNode(Node)

getChildren(n) Was, wenn ich getChildren(n)for each child {

addGraphicNode(createGraphicNode(child))

buildTree(child)

,die Art der

Anzeige zur Laufzeit ändern

ill?


buildTree(child)}

will?

b) Pluggable Adapter mit „Delegate Objects“

<<Client>>TreeDisplay

setDelegate(Delegate)

<<Target>>TreeAccessorDelegate

getChildren (TreeDisplay Node)

delegate

g ( g )display()buildTree (Node n)

getChildren (TreeDisplay, Node)createGraphicNode(TreeDisplay, Node)

<<Adapter>>DirectoryBrowser

<<Adaptee>>FileSystemEntitybackreference

getChildren (TreeDisplay, Node)createGraphicNode(TreeDisplay, Node)createFile()deleteFile()

delegate getChildren(this n)

Eigenes Anpassungs-InterfaceAbstrakte Methodendelegate.getChildren(this,n)

for each child {addGraphicNode(

delegate.createGraphicNode(this,child))buildTree(child)

Abstrakte MethodenAdapter implementieren InterfaceAdapter muessen an TreeDisplay rückfragen können, um dessen


buildTree(child)}

rückfragen können, um dessen Operationen zu nutzen

c) Pluggable Adapter Idiom in Smalltalk und Java

V l M d l

Smalltalk

V l M d l

Pseudo-Java

ValueModel

value:value

ValueModel

setValue()getValue()

adaptee adapteePluggableAdaptor

getBlocksetBlock

Objekt PluggableAdaptor Objekt

getBlocksetBlock GetBlock

value:value

setValue(Oject val)getValue()

getValue(Obj)

SetBlock

^ l k l d

setValue(Obj,Val)


^getBlock value: adaptee return getBlock.getValue(adaptee)

Blöcke in Smalltalk und Java

SmalltalkBlöcke sind Objekte die auf die Nachricht „value“ reagieren

Analog zu einem „Command“-Objekt das auf „run“ reagiertBlöcke können auf den Kontext zugreifen, in dem Sie definiert wurden!

können z B direkt auf Variablen des erzeugenden Kontexts zugreifenkönnen z.B. direkt auf Variablen des erzeugenden Kontexts zugreifen

JavaInstanzen einer „Inner Class“ können auf den Kontext der sie erzeugenden „Outer Class“-Instanz zugreifengetBlock und setBlock als inner classes der anzupassenden KlasseLeider ist damit ist keine unvorhergesehene Adaptierung realisierbar (Änderungen der anzupassenden Klasse wären erforderlich).


Adapter Pattern: Pluggable Adapter Implementierung

Vererbungmanchmal zu starr

Simulierte Delegationflexibler, da Anpassungsstrategie austauschbar

P t i i it "Blö k "Parametrisierung mit "Blöcken"flexibelste Varianteleider nur Smalltalk-Idiome de u S a ta d o„Innere Klassen“ in Java haben nicht die Ausdruckskraft von Smalltalk-Blöcken


Adapter Pattern: Abgrenzung

Bridgegleiches Interface

Decoratorgleiches Interface

kontrolliert Zugriff"Implementierungs-Detail"

zusätzliche / veränderte Funktion"konzeptionelle Eigenschaft"konzeptionelle Eigenschaft

Adapterverschiedenes Interfaceähnlich Protection-Adapter



Das Proxy Pattern

Proxy Pattern (auch: Surogate, Smart Reference)

AbsichtStellvertreter für ein anderes Objektbietet Kontrolle über Objekt-Erzeugung und -Zugriff

MotivationMotivation kostspielige Objekt-Erzeugung verzögern (zB: große Bilder)verzögerte Objekterzeugung soll Programmstruktur nicht global veränderng j g g g g

IdeeBild-Stellvertreter (Proxy) verwendenBild-Stellvertreter verhält sich aus Client-Sicht wie BildBild-Stellvertreter erzeugt Bild bei BedarfBild Stellvertreter erzeugt Bild bei Bedarf

aTextDocumentimage

anImageProxyfile

anImage


Hauptspeicher Platte

Proxy Pattern: Beispiel

DocumentEditor

draw()getExtent()

Graphic *

getExtent()store()load()

ImagefileName

ImageProxyif (image == 0){

image = loadImage(filename);}image.draw() imageData

<<creates>>

extent

draw()getExtent()

image

g ()

if (image == 0){return extent;

gextent

draw()getExtent() g

store()load()

return extent;} else {

return image.getExtent();}

gstore()load()


Proxy Pattern: Schema

ClientSubject *

request()...

...realSubject request();

RealSubject ProxyrealSubject

request()...

request()...

realSubject.request();...

aProxyaRealSubject aClient← request()← request()


q ()← request()

Proxy Pattern: Verantwortlichkeiten

Proxybietet gleiches Interface wie "Subject"referenziert eine "RealSubject"-Instanzkontrolliert alle Aktionen auf dem "RealSubject"

Subjectdefiniert das gemeinsame Interfaceg

RealSubjectdas Objekt das der Proxy vertritteigentliche Funktionalität

Zusammenspielselektives Forwarding


Proxy Pattern: Anwendbarkeit

Virtueller Proxyverzögerte Erzeugung "teurer" Objekte bei BedarfBeispiel: Bilder in Dokument, persistente Objekte

Remote ProxyyZugriff auf entferntes ObjektObjekt-MigrationB i i l CORBA RMI bil A tBeispiele: CORBA, RMI, mobile Agenten

Concurrency Proxyi di kt R f f R lS bj tnur eine direkte Referenz auf RealSubject

locking des RealSubjects vor Zugriff (threads)

C W itCopy-on-Writekopieren erhöht nur internen "CopyCounter"wirkliche Kopie bei Schreibzugriff und "CopyCounter">0


wirkliche Kopie bei Schreibzugriff und CopyCounter 0Verzögerung teurer Kopier-Operationen

Proxy Pattern: Anwendbarkeit

Protection Proxy (Zugriffskontrolle)Schmaleres Interface

"Kritische" Operationen ausgeblendetandere via Forwarding implementiert

ganz anderes Interfaceganz anderes InterfaceAutorisierung prüfendirekten Zugriff gewähren oder Forwarding

Beispiel: "CHOICES" Betriebssystem JDKBeispiel: "CHOICES" Betriebssystem, JDK


Protection-Proxy im JDK (ab 1.2): GuardedObject

ProblemSichere Weitergabe eines schützenwerten Objektes an unbekannten EmpfängerObjektspezifische Zugriffsrechtej p gVerzögerte Überprüfung der Zugriffsrechte

Idee: GuardedObjectIdee: GuardedObjectEnthält "bewachtes Objekt" und "Wächter" (Guard)Guard-Interface enthält nur die Methode checkGuard(Object)

Referenz auf bewachtes Objekt wird nur dann herausgegeben wenn

Guard

Referenz auf bewachtes Objekt wird nur dann herausgegeben, wenn checkGuard(Object)erfolgreich ist (sonst SecurityException)

checkGuard(...)

bewachtesObj kt

Requestor GuardedObjectgetObject()

Objekt

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


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

Proxy Pattern: Implementierung

„Consultation“Allgemein: manuell erstellte Forwarding-MethodenC++: Operator-Overloading

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

Smalltalk: ReflektionProxy redefiniert Methode "doesNotUnderstand: aMessage"

L i S hk t ktLava: eigenes SprachkonstruktProxy deklariert "consultee"-Variableclass Proxy {

private consultee RealImage realImage;private consultee RealImage realImage;...

}

Falls der Typ von "RealSubject dem Proxy bekannt sein muß:Falls der Typ von RealSubject„ dem Proxy bekannt sein muß: Je eine spezifische Proxy-Klasse für jeden RealSubject-Typ

... dem Proxy nicht bekannt sein muß:


yNur eine Proxy-Klasse für verschiedene RealSubject-Typen

Beispiel: „Guarded Object“ (vorherige Folie)

Proxy Pattern: Implementierung

Refenrenzierung des RealSubject vor InstantiierungOrts- und Zeit-unabhängige "Ersatz-Referenzen"Beispiele

DateinamenCORBA IOR (Interoperable Object Reference)CORBA IOR (Interoperable Object Reference)


Proxy Pattern: Abgrenzung

Proxygleiches Interface

Decoratorgleiches Interface

kontrolliert Zugriff"Implementierungs-Detail"

zusätzliche / veränderte Funktion"konzeptionelle Eigenschaft"konzeptionelle Eigenschaft

Adapterverschiedenes Interfaceähnlich Protection-Proxy



Das Bridge Pattern

Bridge Pattern (auch: Handle / Body)

AbsichtSchnittstelle und Implementierung trennen... unabhängig variieren

Motivation portable "Window"-Abstraktion in GUI-Toolkitmehrere Variations-Dimensionen

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

Implementierungen: – X-Windows, – IBM Presentation ManagerIBM Presentation Manager,– MacOS, – Windows XYZ, – ...


...

Bridge Pattern: Warum nicht einfach Vererbung einsetzen?

Window Window

Neue Fenster-Art:"iconifizierbare" Fenster

XWindow PMWindow IconWindowPMWindowXWindow

XIconWindow PMIconWindow

Probleme dieses LösungsversuchsEi Kl fü j d K bi ti F t A t / Pl ttfEigene Klasse für jede Kombination Fenster-Art / Plattform

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


plattformabhängiger Client-Code

Bridge Pattern: Idee

Trennung vonKonzeptueller Hierarchie

bridge

Implementierungs-Hierarchie

drawText()drawRect()

WindowdevDrawText()devDrawLine()

WindowImp

bridgeimp

drawRect() devDrawLine()

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

d B d ()

IconWindow

devDrawLine()

PMWindowImp

devDrawText()

XWindowImp

d Cl B ()

TransientWindow

drawBorder() devDrawLine()devDrawText()

devDrawText()devDrawLine()

drawCloseBox()


drawRect()drawText()

drawRect() XDrawLine() XDrawString()

Bridge Pattern: Schema

Client

ImplementorAbstraction imp

basicOperation()operation()

imp.basicOperation()

RefinedAbstraction ConcreteImplementorA ConcreteImplementorB

basicOperation() basicOperation()


Bridge Pattern: Verantwortlichkeiten

Abstractiondefiniert Interfacereferenziert Implementierung

RefinedAbstractionRefinedAbstractionerweitert das Interface

ImplementorInterface der Implementierungs-Hierarchiekann von Abstraction abweichenkann von Abstraction abweichen

ConcreteImplementorwirkliche Implementierung

Zusammenspiel


ZusammenspielForwarding

Bridge Pattern: Anwendbarkeit

D i h Ä d b k itDynamische ÄnderbarkeitImplementierung erst zur Laufzeit auswählen

Unabhängige Variabilitätneue Unterklassen in beiden Hierarchien beliebig kombinierbar

Implementierungs-Transparenz für ClientsÄnderungen der Implementierung erfordern keine Änderung / g p g gNeuübersetzung der Clients

Vermeidung von "Nested Generalisations"Vermeidung von Nested Generalisationskeine Hierarchien der Art wie in der Motivations-Folie gezeigtkeine kombinatorische Explosion der Klassenanzahl

Sharingmehrere Clients nutzen gleiche Implementierung


mehrere Clients nutzen gleiche Implementierungz.B. Strings

Bridge Pattern: Implementierung

Instantiierung des richtigen ConcreteImplementor

Falls Abstraction alle ConcreteImplementor-Klassen kennt:Fallunterscheidung im KonstruktorAuswahl des ConcreteImplementor anhand von Parametern desAuswahl des ConcreteImplementor anhand von Parametern des Konstruktors

Beispiel: Collectioni El t I l ti l k tt t Li twenig Elemente: Implementierung als verkettete Liste

viele Elemente: Implementierung als HashtableAlternativ: Default-Initialisierung und spätere situationsbedingte Änderung

Falls Abstraction völlig unabhängig von ConcreteImplementor-Klassen sein soll:sein soll:

Entscheidung anderem Objekt überlassenAbstract Factory Pattern


Bridge Pattern: Abgrenzung

Bridgeantizipierte Entkopplung von

Adapternachträgliche Anpassung der

Schnittstelle und Implementierung

Schnittstelle einer Implementierung

Abstract Factorynutzbar zur Erzeugung und Konfiguration einer BridgeKonfiguration einer Bridge


Patterns für Subsysteme ( siehe „Systementwurf“)

FacadeSubsystem abschirmen

SingletonNur eine einzige Facade-Instanz erzeugen

PProxyStellvertreter für entferntes Subsystem

AdapterAdapterAnpassung der realen an die erwartete Schnittstelle

Bridge Entkopplung der Schnittstelle von der Implementierung



Teil 2Teil 2- Object Design Patterns -

Command, Factory Method, Abstract Factory, Composite, Visitor„Patterns Create Architectures“

Rückblick: „Was nutzen Patterns?“


Das Command Pattern: Motivation

KontextGUI-Toolkits mit Buttons, Menüs, etc.

ForcesVielfalt trotz EinheitlichkeitVielfalt trotz Einheitlichkeit

Einheitlicher Code in allen GUI-Elementen .. trotzdem verschiedene Effekte

Wi d dWiederverwendungÜber verschiedene GUI-Elemente ansprechbare Operationen nur ein mal programmieren

Dynamikdynamische Änderung der Aktionen von Menu-Einträgenkontext-sensitive Aktionen


Das Command Pattern: Idee

O i l Obj k i M h d d llOperationen als Objekte mit Methode execute() darstellenin den GUI-Elementen speichern

Einheitlicher Aufruf

VerschiedeneImplementierungen


Das Command Pattern: Anwendbarkeit

Operationen als Parameter Variable Aktionen

referenziertes Command-Objekt austauschenZeitliche Trennung

Befehl zur Ausführung, Protokollierung, Ausführungg, g, gSpeicherung und Protokollierung von Operationen

History-ListeSerialisierungSerialisierung

"Undo" von OperationenCommand-Objekte enthalten neben execute() auch unexecute()werden in einer History-Liste gespeichert

Recover-Funktion nach SystemabstürzenHistory-Liste wird gespeicherty g pZustand eines Systems ab letzter Speicherung wiederstellbar

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


Transaktionen können sowohl einfache ( primitive ), als auch komplexe Command-Objekte sein.

Implementierung des Command Patterns

Unterschiedliche Grade von IntelligenzCommand-Objekte können "nur" Verbindung zwischen Sender und Empfänger sein, oder aber alles selbstständig erledigenoder aber alles selbstständig erledigen.

Unterstützung von "undo"Semantik

Undo (unexecute()) und redo (execute()) müssen den exakt gegenteiligen Effekt haben!Problem: In den wenigsten Fällen gibt es exact inverse Operationen

Die Mathematik ist da eine Ausnahme...Daher Zusatzinfos erforderlich

Damit ein Command-Objekt "undo" unterstützen kann, müssen evtl. zusätzliche Informationen gespeichert werden.Typischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werdenTypischerweise: Kopien des alten Zustands der Objekte die wiederhergestellt werden sollen.

History-ListeFür mehrere Levels von undo/redoFür mehrere Levels von undo/redo

Clonen vor Speicherung in der History-ListeEs reicht nicht eine Referenz auf die Objekte zu setzen! Man muss das Objekt "tief" Clonen, um sicherzustellen dass sein Zustand nicht verändert


j ,wird.

Das Command Pattern: Konsequenzen

Entkopplung von Aufruf einer Operation und Spezifikation einer Operation.

Kommandos als ObjekteCommand-Objekte können wie andere Objekte auch manipuliert und erweitert werdenerweitert werden.

KompositionFolgen von Command-Objekte können zu weiteren Command-Objekten zusammengefasst werden.

ErweiterbarkeitNeue Command Objekte können leicht hinzugefügt werden da keineNeue Command-Objekte können leicht hinzugefügt werden, da keine Klassen geändert werden müssen.


Aufgabe

die sich mit

ObserverStrategyCommand

lö lä tlösen lässt.


StrukturVerhalten

Patterns-ÜberblickStrukturVerhalten

VisitorObserver

CompositeFlyweight


y g

Chain of Responsibility

StateDecoratorAdapter

StrategyMultiple Vererbung

pProxyBridgeF dFacade

Split Objects


PrototypeSingleton


Objekt-Erzeugung


Singleton


Das Command und Observer PatternDas Command und Observer Patternin Java


Verbindung von Observer und Command in Java (1)

<<interface>>ActionListener

void actionPerfomed(ActionEvent evt)

MyPasteCommand

<<implements>>

:MenuItemvoid actionPerfomed(ActionEvent evt)

:Button

: MyPasteCommand

:JComponent( S )

← addActionListener(ActionListener)

→ actionPerformed(ActionEvent)

ObserverButtons, Menue-Einträge und Tasten

← registerKeyboardAction(ActionListener, KeyStroke, ...)

Command & Observergleiche Methode (z.B. actionPerformed)Buttons, Menue Einträge und Tasten

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

gleiche Methode (z.B. actionPerformed) spielt die Rolle der run() Methode eines Commands und die Rolle der update() Methode eines Observersimplementierende Klasse (z.B. MyPasteCommand) ist gleichzeitig ein


... und Instanzen davon bei Buttons, MenuItems, etc registrieren

MyPasteCommand) ist gleichzeitig ein Command und ein Observer

Verbindung von Observer und Command in Java (2)Zusätzliche Unterstützung für "Command"Zusätzliche Unterstützung für Command

Interface "Action" und Klasse "AbstractAction" <<interface>>

ActionListener

Akti i /

ActionListener

void actionPerfomed(ActionEvent evt)

<<extends>>

<<interface>>Action

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

Aktivierung / Deaktivierung

von MenuItems denen diese nt

halte

n

Object getValue(String key)

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

Einheitliche Schnittstelle zur Speicherung von Parametern

für "Action" ...

denen diese "Action"

zugeordnet ist

m J

DK

en

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

<<implements>>... Parameter

können allerdings

im

AbstractAction// alles ausser void actionPerfomed(ActionEvent evt)

allerdings auch direkt als

Instanz-Variablen realisiert

<<extends>>


MyPasteCommandvoid actionPerfomed(ActionEvent evt)

realisiert werden.

Beispiel: Änderung der Hintergrundfarbe (1)

class ColorAction extends AbstractAction{ public ColorAction(..., Color c, Component comp)

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

}

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

target.repaint();}}

private Component target;private Color color;

class ActionButton extends JButton{ public ActionButton(Action a)

{} { ...addActionListener(a);

}}

ColorActionÄndern der Hintergrundfarbe einer GUI-Komponente

ActionButton


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


Nutzung der ColorActionErzeugung einer Instanz

class SeparateGUIFrame extends JFrame{ public SeparateGUIFrame(){

Registrierung

{ ...JPanel panel = new JPanel();

Action blueAction = new ColorAction("Blue", ...,..., panel);( , , , p );

panel.registerKeyboardAction(blueAction,...);

l dd( A ti B tt (bl A ti ))panel.add(new ActionButton(blueAction));

JMenu menu = new JMenu("Color");menu.add(blueAction);( );...

}}



Nutzung der ColorActionErzeugung einer Instanz

class SeparateGUIFrame extends JFrame{ public SeparateGUIFrame(){

Registrierung

{ ...JPanel panel = new JPanel();

Action blueAction = new ColorAction("Blue", ...,..., panel);( , , , p );

panel.registerKeyboardAction(blueAction,...);

l dd( A ti B tt (bl A ti ))panel.add(new ActionButton(blueAction));

JMenu menu = new JMenu("Color");menu.add(blueAction);( );...

}} Der komplette Code des Beispiels steht auf der Website.

Beispiel und Erläuterung siehe: "Core Java 2" Kapitel 8


Beispiel und Erläuterung siehe: Core Java 2 , Kapitel 8, Abschnitt "Separating GUI and Application Code".

Fazit

Elegante Verbindung von Observer und CommandCommands sind ActionListener von Buttons, Menus, etc.

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

Aktivierung / DeaktivierungAktivierung / Deaktivierung

Wiederverwendunggleiche Action für Menu, Button, Key

DynamikDynamikWie ändert man die aktuelle Aktion?... konsistent für alle betroffenen MenuItems, Buttons, etc.???

Strategy Pattern!


StrukturVerhalten

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

VisitorObserver

CompositeFlyweight


y g


StateDecoratorProxy


yAdapterBridgeF dFacade

Split ObjectsJetzt


PrototypeSingleton


Objekt-Erzeugung


Singleton


Das Factory Method Pattern

Factory Method

ZielEntscheidung über konkreter Klasse neuer Objekte verzögern

MotivationF k it d fi i t Kl "D t" d "A li ti "Framework mit vordefinierten Klassen "Document" und "Application"Template-Methode, für das Öffnen eines Dokuments:

1. Check ob Dokument-Art bekannt2. Erzeugung einer Document-Instanz !?!

Erzeugung von Instanzen noch nicht bekannter Klassen!

Ideeaktuelle Klasse entscheidet wann Objekte erzeugt werden

Aufruf einer abstrakten MethodeSubklasse entscheidet was für Objekte erzeugt werden

implementiert abstrakte Methode passend


implementiert abstrakte Methode passend

Factory Method: Beispiel

Framework

D t A li ti*Document ApplicationnewDocument()

doCreateDocument()

Document doc = doCreateDocument();

docs.add(doc);doc.open();

docs

MyDocument MyApplicationdoCreateDocument() return new MyDocument()

Applikation


Applikation

Factory Method: Schema

ProductanOperation()

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

factoryMethod()product factoryMethod();...

ConcreteProductfactoryMethod()

ConcreteCreatorreturn new ConcreteProduct()

Factory Method kann abstrakt seinkann abstrakt seinkann Default-Implementierung haben

Creator (Aufrufer der Factory Method)kann Klasse sein, die die Factory Method definiertkann Client Klasse sein


kann Client-Klasse seinBeispiel: parallele Vererbungs-Hierarchien

Factory Method: Anwendbarkeit

Klasse neuer Objekte unbekannt

Verzögerte Entscheidung über Instantiierungerst in Subklasseerst beim Clienterst beim Client

Mehrere HilfsklassenWissen über konkrete Hilfsklassen an einer Stelle lokalisierenBeispiel: Parallele Hierarchien (nächste Folie)


Factory Method: Anwendbarkeit

Figure ManipulatorClientcreateManipulator()...

downClick()drag()upClick()

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

TextFigurecreateManipulator()...

LineFiguredownClick()drag()upClick()

LineManipulatordownClick()drag()upClick()

Textmanipulator

upClick() upClick()

Verbindung paralleler KlassenhierarchienFactory Method lokalisiert das Wissen über zusammengehörige KlassenR li h C d d Fi Hi hi d Cli C d i ölli


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

Factory Method: Implementierung

Fester "Produkt-Typ"jede Unterklasse erzeugt festgelegte Produkt Art

class Creator {Product create(){ MyProduct(); }

}festgelegte Produkt-Art

class Creator {

}

Codierter "Produkt-Typ"Parameter oder Objekt-Variable {

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

Parameter oder Objekt-Variable kodiert "Produkt-Typ"Fallunterscheidung anhand Code

}}

mehrere Produktemehr Flexibilität Idiom reflektiver Sprachen

• Smalltalk• Java

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

Klassen-Objekt als "Produkt-Typ"Parameter oder Objekt-Variable ist "Produkt-Typ"di k I ii

• Java

}}

direkte Instantiierungmehr Flexibilitätbessere Wartbarkeit

Reflektiver Aufruf des parameterelosen Default-Konstruktors


kein statischer Typ-Check

Factory Method: Konsequenzen

Code wird abstrakter / wiederverwendbarerkeine festen Abhängigkeiten von spezifischen Klassen

Verbindung paralleler KlassenhierarchienF t M th d l k li i t d Wi üb Z hö i k itFactory Method lokalisiert das Wissen über Zusammengehörigkeiten

evtl. künstliche Subklassennur zwecks Objekterzeugung


Factory Method: Anwendungen

überall in Toolkits, Frameworks, Class LibrariesUnidraw: Beispiel "Figure und Manipulator" MacApp und ET++: Beispiel "Document und Application"

Smalltalk's Model View Controller FrameworkSmalltalk's Model-View-Controller FrameworkFactoryMethoden-Template: defaultControllerHook-Methode: defaultControllerClass

OrbixErzeugung des richtigen Proxy

leichte Ersetzung von Standard-Proxy durch Caching Proxy


Factory Method: Abgrenzung

Template Methodruft oft Factory Method auf

Abstract Factoryft it F t M th d i l ti toft mit Factory Methods implementiert

gleiche Motivation

Prototypeerfordert keine Unterklassenbildung... dafür aber explizite initialize()-Methode



Das Abstract Factory Pattern

Abstract Factory

Zielzusammengehörige Objekte verwandter Typen erzeugen... ohne deren Klassenzugehörigkeit fest zu codieren

M ti tiMotivationGUI-Toolkit für mehrere PlattformenAnwendungsklassen nicht von plattformspezifischen Widgets abhängig e du gs asse c t o p att o spe sc e dgets ab ä g gmachenTrotzdem soll die Anwendung

alle Widgets konsistent zu einem "look and feel" erzeugen könnenalle Widgets konsistent zu einem look and feel erzeugen können"look and feel" umschalten können


Abstract Factory: Motivation

createWindow()createScrollBar()

WidgetFactory Client

Window


MotifWidgetFactorycreateWindow()createScrollBar()

PMWidgetFactory PMWindow MotifWindow

Scrollbar

PMScrollbar MotifScrollBar


Abstract Factory: Schema

createProductA()createProductB()

AbstractFactory Client

AbstractProductA

createProductA()createProductB()

ConreteFactory1createProductA()createProductB()

ConreteFactory2 ProductA2 ProductA1

AbstractProductB

ProductB2 ProductB1


Abstract Factory: Implementierung

ConcreteFactories sind SingletonsProdukt-Erzeugung via Factory-Methodsf t P d kt T ( i M th d fü j d P d kt)fester Produkt-Typ (eine Methode für jedes Produkt)

Nachteilneues Produkt erfordert Änderung der gesamten Factory-Hierarchie

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

Vorteilleichte Erweiterbarkeit um neues Produkt

Nachteile:alle Produkte müssen gemeinsamen Obertyp habenalle Produkte müssen gemeinsamen Obertyp habenClients können nur die Operationen des gemeinsamen Obertyps nutzenVerzicht auf statische Typsicherheit

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

neues Produkt erfordert keinerlei Änderungen der FactoryNachteil


NachteilVerzicht auf jegliche statische Typinformation / Typsicherheit

Abstract Factory: Implementierung

Produktfamilie = SubklasseVorteil

Konsistenz der ProdukteNachteil

neue Produktfamilie erfordert neue Subklasse auch bei geringenneue Produktfamilie erfordert neue Subklasse, auch bei geringen Unterschieden

Produktfamilie = von Clients konfigurierte assoziative DatenstrukturProduktfamilie = von Clients konfigurierte assoziative DatenstrukturVarianten

Prototypen und CloningKlassen und Instantiierung

Vorteilkeine Subklassenbildung erforderlichg

NachteilVerantwortlichkeit an Clients abgegebenkonsistente Produktfamilien können nicht mehr garantiert werden


konsistente Produktfamilien können nicht mehr garantiert werden

Abstract Factory: KonsequenzenAbschirmung von Implementierungs-KlassenAbschirmung von Implementierungs-Klassen

Namen von Implementierungsklassen erscheinen nicht im Code von ClientsClients benutzen nur abstraktes InterfaceClients benutzen nur abstraktes Interface

leichte Austauschbarkeit von ProduktfamilienN i C t F t h i t i l i C dName einer ConcreteFactory erscheint nur ein mal im Code

bei ihrer Instantiierungleicht austauschbar gegen andere ConcreteFactoryBeispiel: Dynamisches Ändern des look-and-feel

andere ConcreteFactory instantiierenalle GUI-Objekte neu erzeugen

konsistente Benutzung von Produktfamilienkeine Motif-Scrollbar in Macintosh-Fenster

schwierige Erweiterung um neue ProduktartenSchnittstelle der AbstractFactory legt Produktarten fest


Schnittstelle der AbstractFactory legt Produktarten festNeue Produktart = Änderung der gesamten Factory-Hierarchie

Abstract Factory: Anwendbarkeit

System soll unabhängig sein vonObjekt-ErzeugungObjekt-KompositionObjekt-Darstellung

System soll konfigurierbar seinAuswahl aus verschiedenen Produkt-Familien

konsistente Produktfamiliennur Objekte der gleichen Familie "passen zusammen"

Library mit Produktfamilie anbietenLibrary mit Produktfamilie anbietenClients sollen nur Schnittstelle kennen... nicht die genauen Teilprodukt-Arten / -Implementierungen


StrukturVerhalten

"Gang of Four"-Patterns: Überblick und KlassifikationJetzt StrukturVerhalten

VisitorObserver

CompositeFlyweight

Jetzt


y g


StateDecoratorProxy


yAdapterBridgeF dFacade

Split Objects


PrototypeSingleton


Objekt-Erzeugung


Singleton


Das Composite Pattern

Composite Pattern

Zielrekursive Aggregations-Strukturen darstellen ("ist Teil von")Aggregat und Teile einheitlich behandeln

M ti tiMotivationGruppierung von Graphiken


Composite Pattern: Beispiel

Graphicdraw() childrendraw()

add(Graphic)remove(Graphic)

getChildren()

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

draw()add(Graphic)

draw()

Linedraw()

}remove(Graphic)getChildren()

aText

aLine

aPicture aPicture

aText


aText aPicture aPicture

Composite Pattern: Struktur

Componentoperation() children

Client*

operation()add(Component)

remove(Component)getChildren()

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


operation()

}remove(Component)getChildren()


Composite Pattern: Verantwortlichkeiten*

Component (Graphic)gemeinsames Interface aller Teilobjekte

Componentoperation()

add(Component)(C t)

children

*

default-VerhaltenInterface für Zugriff auf Teilobjekte (!)evtl Interface für Zugriff auf Elternobjekte


evtl. Interface für Zugriff auf Elternobjekte

Leaf (Rectangle, Line, Text) CompositeLeaf( g )"primitive" Teil-Objekteimplementieren gemeinsames Interfacel I l ti fü T il iff I t f



operation()

leere Implementierungen für Teilzugriffs-Interface

Composite (Picture)p ( )speichert Teilobjekteimplementiert gemeinsames Interface durch forwarding


implementiert Teilzugriffs-Interface

Composite Pattern: Anwendbarkeit*

Componentoperation()

add(Component)(C t)

children

*


CompositeLeafoperation()

add(Component)remove(Component)

getChildren()

operation()


Composite Pattern: Implementierung*

Composites sollen wissen wovon sie Teil sindExplizite Referenzen auf Composite in Component Klasse

Component



children

Component KlasseMehrere Composites sollen Components gemeinsam nutzen

CompositeLeaf


(C )

operation()

parent1

schließt explizite Referenz der Components auf Composite aus odererfordert, dass Components wissen, dass sie Teile mehrerer Composites i d


sindComponent Interface

"Sauberes Design": Verwaltungs-Operationen (add, remove, getChildren) g g p ( g )in Composite, da sie für Leafs nicht anwendbar sind.Wunsch nach einheitlicher Behandlung aller Graphic-Objekte durch Clients

Verwaltungs-Operationen in Component mit default-Implementierung di i ht t tdie nichts tut

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


Composite Pattern: Konsequenzen

einheitliche BehandlungTeileGanzes

einfache Clientsd i bi di t tt F ll t h iddynamic binding statt Fallunterscheidungen

leichte Erweiterbarkeitneue Leaf-Klasseneue ea asseneue Composite-Klassenohne Client-Änderung

evtl. zu allgemeinEinschränkung der Komponenten-Typen schwerrun-time type checks (instanceof)run time type checks (instanceof)



Das Visitor Pattern

Das Visitor Pattern

AbsichtRepräsentation von Operationen auf Elementen einer Objektstruktur Neue Operationen definieren, ohne dass die Klassen dieser Objekte zu ändern


Das Visitor Pattern: Motivation

Beispiel: Compiler enthält Klassenhierarchie für Ausdrücke einer Programmiersprache

ProblemCode einer Operation ist über mehrere Klassen verteiltN O ti f d t Ä d d t Hi hi

Node

Neue Operation erfordert Änderung der gesamten Hierarchie

TypeCheck()GenerateCode()PrettyPrint()

AssignmentNodeVariableRefNode


g



Das Visitor Pattern: Idee (1)

Operation = ObjektZusammenfassung aller Methoden einer Operation in einer Klasse

visit -Methodenvisit...-MethodenAusprägung der Operation auf bestimmtem Objekttyp

visitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)

NodeVisitor

visitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)

TypeCheckingVisitorvisitAssignment(AssignmentNode)visitVariableRef(VariableRefNode)

CodeGeneratingVisitor

visitVariableRef(VariableRefNode) visitVariableRef(VariableRefNode)


Das Visitor Pattern: Idee (2)

"akzeptierende" Methoden in der betroffenen Klassenhierarchierufen die jeweils passende visit...-Methode auf

*

accept(NodeVisitor)

NodeProgram *

accept(NodeVisitor v)

AssignmentNode

accept(NodeVisitor v)

VariableRefNode

accept(NodeVisitor v) accept(NodeVisitor v)

v visitAssignment(this) v visitVariableRef(this)


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

Das Visitor Pattern: Schema

visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

VisitorClient

visitConcreteElementA(ConcreteElementA)

ConcreteVisitor1visitConcreteElementA(ConcreteElementA)

ConcreteVisitor2visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

visitConcreteElementA(ConcreteElementA)visitConcreteElementB(ConcreteElementB)

accept(Visitor)

ElementObjectStructure *

accept(Visitor v)

ConcreteElementA

accept(Visitor v)

ConcreteElementB

accept(Visitor v)operationA()

accept(Visitor v)operationB()

v visitConcreteElementB(this)v visitConcreteElementA(this)


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

Visitor Pattern: Verantwortlichkeiten / Implementation

Objektstruktur-Hierarchieeinheitliche accept-Methode

Visitor-Hierarchie je eine visit-Methode für jede Klasse der Objektstrukturj j j

Accept-Methodenhaben Visitor als Parameterhaben Visitor als Parameter"Welche Operation soll auf mir ausgeführt werden?"

Visit MethodenVisit-Methodenhaben Parameter vom Typ der jeweilige Klasse der Objektstruktur"Wie soll Operation X auf Objekten des Typs Y ausgeführt werden?"

Traversierung der Objektstruktur kann definiert sein in der Objektstruktur (Methode accept(...)) oder


j ( p ( ))im Visitor-Objekt (Method visit...(...))

Das Visitor Pattern: Zusammenarbeit


Das Visitor Pattern: Konsequenzen

Funktionale DekompositionEin Visitor fasst Methoden der gleichen Operation zusammen... und trennt Methoden verschiedener Operationen

HeterogenitätObjekt-Klassen können aus verschiedenen Hierarchien stammenj

Hinzufügen neuer Operationen ist einfachneue Visitor-Klasse

Hi fü Obj kt Kl i t h f diHinzufügen neuer Objekt-Klassen ist sehr aufwendigneue Objekt-Klasseneue visit... - Methode in allen Visitors

Sammeln von Zuständenwährend der Abwanderung eines Objektbaumsdafür keine zusätzlichen Parametern nötigdafür keine zusätzlichen Parametern nötig

Verletzung von KapselungKlassen der Objekstruktur müssen den Visitors ausreichend Funktionalität bieten


bietenOft müssen ihre Schnittstellen mehr preisgeben als sonst nötig

Das Visitor Pattern: Anwendbarkeit

Funktionale DekompositionZusammengehörige Operationen sollen zusammengefasst werden ... statt in einer Klassenhierarchie verteilt zu sein

Stabile Objekt-Hierarchielt Klselten neue Klassen

aber oft neue OperationenHeterogene Hierarchieg

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

AnwendungsbeispielJava-Compiler des JDK 1 3Java Compiler des JDK 1.3


Überblick


Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandBridge, Factory Method, Abstract Factory

Patterns Create ArchitecturesBridge, Abstract Factory, Singleton

N t P ttNutzen von PatternsZusammenfassung und Ausblick

Bestandteile eines Patterns, DefinitionBestandteile eines Patterns, DefinitionArten von Patterns, AbgrenzungWeiterführende Themen



„Patterns Create Architectures“

Ein Beispiel zum Zusammenspiel von PatternsPatterns

Bridge & Abstract Factory & Singleton

„Patterns Create Architectures“

IdeeWenn man Patterns wohlüberlegt zusammen verwendet, entsteht ein Grossteil einer Software-Architektur aus dem Zusammenspiel der Patterns.

BeispielBeispielZusammenspiel von Bridge, Factory und Singleton


Erinnerung ans Abstract Factory Pattern


WidgetFactory Client

Windowin der Praxis müsste WidgetFactory ein

Singleton seinSingleton sein


MotifWidgetFactorycreateWindow()createScrollBar()

PMWidgetFactory PMWindow MotifWindow

Scrollbar

PMScrollbar MotifScrollBar

in der Praxis müsste hier das Bridge-

Pattern angewendet werden


werden

Erinnerung ans Bridge Pattern

Trennung vonKonzeptueller Hierarchie Implementierungs-

HierarchieClient


WindowImpdrawText()drawRect()

Window impClient

devDrawLine()drawRect()

devDrawLine()

XWindowImpdevDrawText()

PMWindowImp

()

IconWindow

C ()

TransientWindowdevDrawLine()devDrawText()


drawBorder() drawCloseBox()


Zusammenspiel: Bridge, Factory, Singleton<< konfiguriert >>

Client WidgetFactory<< konfiguriert >>

SingletonWidgetFactory setFactory(WidgetFactory MOTIF)

PMWidgetFactorycreateWindow()MotifWidgetFactory

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

Wi d IWi d imp

createWindow()createScrollBar()<< benutzt >>

WindowImpWindow imp

PMWindow MotifWindowIconWIndow TransientWindow

ScrollbarImpScrollbar imp ScrollbarImpScrollbar imp


PMScrollbar MotifScrollBarFixedSB ProportionalSB


Rückblick: Was nützen Patterns?

Nutzen von Design Patterns (1)

Objekte / Klassen identifizierenAbstraktionen, die kein Gegenstück in der realen Welt / dem Analyse-Modell habenBeispiel:

Composite PatternComposite PatternAbstraktionen von ProzessenStrategyState

"Strict modelling of the real world leads to a system that reflects today's realities but not necesarilly tomorrow's. The abstractions that y yemerge during design are key to making a design flexible."



Granularität der Objekte festlegenFacade

ein "Riesen-Objekt"Flyweight

viele kleine gemeinsam verwendbare Teilobjekteviele kleine, gemeinsam verwendbare TeilobjekteBuilder

Komposition von Gesamt-Objekt aus TeilobjektenVisitor

Gruppe von konsistenten AktionenCommandCommand

einzelne Aktion



Schnittstellen identifizierenwas gehört dazuwas gehört nicht dazu (Bsp. Memento)

Beziehungen zwischen Schnittstellen festlegenBeziehungen zwischen Schnittstellen festlegenSubtyping

DecoratorProxy

Je eine Methode pro Klasse aus einer anderen ObjekthierarchieAbstract FactoryAbstract FactoryBuilderVisitor



Wahl der ImplementierungInterface, Abstrakte Klasse oder konkrete Klasse

Grundthema fast aller PatternsAbstrakte Methode oder Hook Methode

von template method aufgerufene Methodenvon template method aufgerufene MethodenOverriding oder fixe Implementierung

Factory methodT l t th dTemplate method

Vererbung oder Subtyp-BeziehungAdapter, Decorator, State, Strategy, Command, Chain of Responsibility: Gemeinsamer Obertyp, nicht gemeinsame Implementierung

Vererbung oder AggregationVererbung ist statischEs wird oft mehr vererbt als gewünschtBeispiel: alle "split object patterns"


Nutzen von Design Patterns (5):

Patterns erkörpern Gr ndprin ipien g ten DesignsPatterns verkörpern Grundprinzipien guten Designs

Implementierungen austauschbar machenImplementierungen austauschbar machenTypdeklarationen mit Interfaces statt mit KlassenDesign an Interfaces orientieren, nicht an KlassenClient-Code wiederverwendbar für neue Implementierungen des gleichen Interface

Objekt-Erzeugung änderbar gestalten"Creational Patterns" statt "new MyClass()"Cli C d i d db fü I l i d l i hClient-Code wiederverwendbar für neue Implementierungen des gleichen Interface

Funktionalität änderbar gestaltenAggregation und Forwarding statt Vererbung

ät K fi i b k it D ik


späte Konfigurierbarkeit, Dynamikweniger implizite Abhängigkeiten (kein "fragile base class problem")

Überblick


Beispiele wichtiger PatternsBeispiele wichtiger PatternsObserver, Strategy, CommandFacade, Singleton, Proxy, Adapter, BridgeFactory Method, Abstract FactoryComposite, Visitor

Patterns Create ArchitecturesPatterns Create ArchitecturesBridge, Abstract Factory, Singleton

Nutzen von PatternsZusammenfassung und Ausblick

Arten von Patterns, AbgrenzungWeiterführende Themen


Arten von Design Patterns

Analysis Patternwiederkehrende Problemen in der Analysephase eines SoftwareprojektsMartin Fowler: "Analysis Patterns", Addison-Wesley, 1997

Architektur Patternb h ibt ö li h f d t l St kt S ft t... beschreibt mögliche fundamentale Strukturen von Softwaresystemen.

... enthält vordefinierte Subsysteme und ihre Verantwortlichkeiten.

... enthält Regeln und Richtlinien für die Organisation ihrer Beziehungen.g g gBeispiel: Das Model-View-Controller Framework

Design PatternSchema für die Realisation von Subsystemen oder Komponenten eines Softwaresystems

Idiom (auch: Coding Pattern)( g )low-level design patterns für eine gegebene Programmiersprache.Beispiel: Wie stelle ich sicher, dass eine Instanz einer Java-Klasse nur innerhalb dieser Klasse erzeugt werden kann?


innerhalb dieser Klasse erzeugt werden kann?

Weitere Arten von Pattern

Organizational PatternsStruktur und Praxis von Organisationen; also Gruppen, die ein gemeinsames Ziel verfolgen http://www.bell-labs.com/cgiuser/ OrgPatterns/OrgPatterns?OrganizationalPatternsg g g

Anti-Patternsbeschreiben typische Fehlerbeschreiben typische Fehler... und bestenfalls auch wie man sie wieder beseitigt


Abgrenzung: Pattern sind keine Algorithmen

Patterns versus AlgorithmenAlgorithmen lösen feinkörnigere Probleme als Patterns (z.B. Suchen, Sortieren)Algorithmen sind deterministischer (weniger Implementierungs-Freiheitsgrade)g )Komplexität von Algorithmen lässt sich leichter fassen


Abgrenzung: Pattern sind keine Frameworks

Pattern versus FrameworksFramework

Menge von kooperierenden Klassen für einen spezifischen Anwendungsbereicherweiterbar durch Unterklassenbildung und Komposition von InstanzenHollywood-Prinzip ("Don't call us, we'll call you." --> Template Method Pattern)

Patterns sind abstrakterFrameworks existieren als konkreter wiederverwendbarer Code – PatternsFrameworks existieren als konkreter, wiederverwendbarer Code Patterns enthalten nur Beispiele von Code

Patterns sind weniger spezifischFrameworks werden für konkrete Anwendungsbereiche eingesetzt PatternsFrameworks werden für konkrete Anwendungsbereiche eingesetzt – Patterns können fast überall eingesetzt werden


Weiterführende Themen

Pattern Catalogs Sammlungen von lose zusammenhängenden Patterns

Pattern Systems S l t k hä d P tt itSammlungen von stark zusammenhängenden Patterns mit engen Verzahnungen

Pattern Languages verfolgen ein gemeinsames Ziel, dass durch die Zusammenarbeit der enthaltenen Patterns erreicht werden kannenthaltenen Patterns erreicht werden kann inkl. einer Art "Grammatik", die alle mögliche Kombinationen aufzeigt


Pattern: Zusammenfassung

Betonung von PraktikabilitätPatterns sind bekannte Lösungen für erwiesenermaßen wiederkehrende Probleme Sie sollen Softwareentwickler bei ihrer Arbeit unterstützen, nicht mehr und nicht wenigerg

"Aggressive Hintanstellung von Originalität"Lösungen, die sich noch nicht in der Praxis bewährt haben, sind keine PatternPattern.

Patterns sind kein AllheilmittelOriginalität bei der Anwendung von Patterns ist nach wie vor gefragt.g g g gEs muss immer noch abgewägt werden, welche Patterns, Pattern Languages, etc. eingesetzt werden.

GesamteffektGesamteffektAufgabe des Softwarearchitekten verlagert sich von der Erfindung des Rads zur Auswahl des richtigen Rads und seiner kreativen Verwendung



Rückblick, Selbsttest

Im Kapitel „Systementwurf“ kommen die 2 folgenden Folien vor.

Sie sollten nun in der Lage sein für die inzwischen besprochenen Design Patterns die auf den folgenden 2Sie sollten nun in der Lage sein, für die inzwischen besprochenen Design Patterns die auf den folgenden 2 Folien genannten Hinweise nachvollziehen.

Wenn nicht, schauen Sie sich die Pattern-Beschreibungen noch mal genau an!

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

IdeeIdentifikation von Design Patterns anhand von Schlüsselwörtern in der Beschreibung nichtfunktionaler AnforderungenAnalog zu Abbots Objektidentifikation durch Textanalyse

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

Hinweise auf Adapter Pattern“muss mit einem existierenden Objekt zusammenarbeiten”muss mit einem existierenden Objekt zusammenarbeiten

Hinweise auf Bridge Pattern„muss sich um die Schnittstelle zu unterschiedlichen Systemen kümmern von denen einige erst noch entwickelt werden.“„ein erster Prototyp muss vorgeführt werden“


Nichtfunktionale Anforderungen geben Hinweise zur Nutzung von Design Patterns (Fortsetzung)

Hinweise auf Composite Pattern“komplexe Struktur”, “muss variable Tiefe und Breite haben”

g g ( g)

Hinweise auf Façade Pattern“muss mit einer Menge existierender Objekte zusammenarbeiten”, "stellt

-Dienst bereit"...-Dienst bereitHinweise auf Proxy Pattern

“muss ortstransparent sein”Hinweise auf Observer Pattern

“muss erweiterbar sein”, “muss skalierbar sein” Hi i f St t P ttHinweise auf Strategy Pattern

“muss Funktionalität X in unterschiedlichen Ausprägungen bereitstellen können”



Ausgeblendete Folien

Auf "Split Objects"-Idee basierende Patterns

1. Das Strategy Pattern

Verbreitung von Patterns

ProzesseUnified Process

NotationenUML

P i hProgrammiersprachen Patterns als Sprachkonstrukte

LibrariesLibraries Java APIs

automatische Erkennung von Patternsre-engineering

Tools Generierung von Quelltexten (z B Together/J)Generierung von Quelltexten (z.B. Together/J)

Formalisierung von Patterns


Advanced Topics

Pattern LanguagesDescriptions of systems of patterns with matching initial and resulting contexts, together with a "grammar" that describes how to compose them.

Pattern SequencesConcrete sequences of patterns from a pattern languageConcrete sequences of patterns from a pattern language.Repeated application of pattern sequences lead to new higher-level patterns.This seems to be a fruitful basis for a formalization of patterns.


Das Command Pattern

Bekannte Anwendungenjavax.swing.undo.UndoableEdit


Das Visitor Pattern: Bekannte Anwendungen

Java-Compiler des JDK 1.3


Observer Aufgabe

Terminkalender-Einträge werden geändertVisuelle Anzeige aktualisierenMail-Benachrichtigungen verschickenBenachrichtigungsstrategie soll sehr weitgehend konfigurierbar sein


Änderungen gegenüber Vorlage (Patterns-Vorlesung aus SS2002))

Vieles gelöschtDesign-Vorlage eine Stufe größer (20 statt 18 Punkt auf 1 Ebene)g g g ( )

Folgeänderung: Verschiebung fixer Objekte auf vielen FolienFolgeänderung: Löschung von Leerzeilen auf Folien mit viel Text

Komplett überarbeitete Visitor-Pattern-Folien neu eingefügt (auf Basis von Pascal‘s Satz aus 2001))

Folie zu cloning im Prototype Pattern umfangreich überarbeitet (incl. f di A i ti )aufwendiger Animation)



Vorlesung Design PatternsSommersemester 2002

Dr. Günter KnieselInstitut für Informatik III

Universität BonnRömerstr. 164, 53117 Bonn

[email protected]


Dieses Material is nur für die Hörer der Vorlesung Design Patterns“ Dieses Material is nur für die Hörer der Vorlesung „Design Patterns (Sommersemester 2002) bestimmt. Es darf ausschliesslich zur Vor-und Nachbereitung der Vorlesung bzw. zur Vorbereitung auf die entsprechende Prüfung verwendet werdenentsprechende Prüfung verwendet werden.

Die Weitergabe an Personen außerhalb des oben erwähnten Personenkreises ist ohne ausdrückliche Genehmigung des Autors Personenkreises ist ohne ausdrückliche Genehmigung des Autors nicht zulässig.

Das komplette Material umfaßt 299 Folien. Die Einleitung und die p gBeschreibung des Observer und Command Patterns (Seite 6 bis 40) basieren auf Folien von Pascal Costanza. Die Folien zum Singleton Pattern (Seite 86 bis 89) sind ein Beitrag von Holger Mügge.


kapitel 6 entwurfsmuster (design patterns) · das observer pattern: einführung zabsicht stellt...

Documents