Entwurfsmuster

Entwurfsmuster
iTec
1

Inhalt 11. Patterns und Frameworks
q Einführung: was ist und wozu braucht man Patterns u. Frameworks ?
q wie werden Patterns beschrieben ?
q Beispiele für Designpatterns
– Singleton
– Proxy
– State
– Beobachter/Observer
– Adapter
– Kompositum
– Dekorierer
– Abstrakte Fabrik
iTec
2

Einführung 11. Patterns und Frameworks
was ist und wozu braucht man Patterns und Frameworks?
q Software-Entwicklung ist mühsam
q wiederverwendbare Software zu schreiben, ist noch mühsamer
q Hilfe bei dieser Mühe:
Design-Patterns und Frameworks, die für häufig
wiederkehrende Probleme bewährte Lösungsmuster
anbieten
iTec
3

Einführung 11. Patterns und Frameworks
Geschichte der Patterns
q Christopher Alexander (1977): A Pattern Language
wie können Standardlösungen immer wiederkehrender
Innenarchitekturprobleme sprachlich formuliert werden?
q Erich Gamma, R.Helm, R. Johnson, J. Vlissides (1995):
Design Patterns – Elements of reusable OO-Software
legten einen bis heute massgebenden Katalog von 23 Patterns vor
q heute:
es gibt kaum OO-Entwicklungen ohne Patterns !
es gehört zum Grundvokabular eines jeden SW-Ingenieurs !
iTec
4

Einführung 11. Patterns und Frameworks
zunächst einige wichtige Begriffe
Software Design
Die Aktivitäten, die aus den Anforderungen an ein
Softwaresystem eine Softwarelösung entwerfen.
Diese Lösung beschreibt die Systemstruktur als
Systemarchitektur (siehe nächste Folie) und dient der
Implementation des Systems als Blueprint.
.
q der Design enthält nicht die Implementation des Systems
q der Design enthält die eigentliche Lösung eines Problems
q der Design wird methodisch und mit Diagrammtechniken erarbeitet
iTec
5

Einführung 11. Patterns und Frameworks
wichtige Begriffe
Software-Architektur
eine Beschreibung der Teilsysteme und Komponenten eines
Softwaresystems und deren Beziehungen untereinander.
Teilsysteme und Komponenten werden unter verschiedenen
Blickwinkeln betrachtet, um verschiedene funktionale und
nichtfunktionale Aspekte zu beschreiben.
Eine Softwarearchitektur ist das Resultat des Software-Designs.
q Komponenten sind gekapselte, mit Schnittstellen versehene
Systemteile: Module, Bibliotheken, Klassen/Objekte
q nichtfunktionale Aspekte: z.B. Erweiterbarkeit, Zuverlässigkeit,
Kosten, Wartbarkeit, Portierbarkeit
q Beziehungen: zB. statisch, dynamisch, abhängig, enthalten, abgeleitet
iTec
6

Einführung 11. Patterns und Frameworks
wichtige Begriffe
Framework
Ein teilweise vorgefertigtes Softwaresystem das noch
"instanziiert" werden muss durch Einfügen fehlender Teile.
Dabei wird eine Architektur vordefiniert, in der wesentliche
Komponenten vorgefertigt sind, und diejenigen Stellen werden
genau definiert, in denen das Framework mit Implementationen
für ein spezielles System noch instanziiert werden muss/kann.
.
q Frameworks sind die grösstmöglich vorgefertigten Systemrohbauten
q Frameworks sind meist typisch für ganze Anwendungsbereiche, zB.:
– für interaktive Systeme mit GUIs – MFC (C++), JFC (JAVA)
– für verteilte OO-Systeme – CORBA, DCOM
iTec
7

Einführung 11. Patterns und Frameworks
Pattern Einordnung
q Idiom
Programmiermuster – wie in einer bestimmten Programmiersprache
kleine Programmierprobleme gelöst werden.
Beispiel in C/C++: wie man ein Feld durchläuft
q Spezifischer Design
ein spezifischer, persönlicher Design für ein bestimmtes Problem.
Kann schlau sein, aber versucht nicht, allgemein anwendbar zu sein
q Standard Design
ein Design für ein bestimmtes Problem, der Allgemeinheit erlangt
hat durch Wiederverwendung. Z.B. eine unternehmensweite Lösung
für das Y2000-Problem
q Design Pattern
eine Lösung für eine ganze Klasse von ähnlichen Problemen. Meistens
erst sichtbar nach längerer Anwendung von Standard-Designs.
iTec
8

Einführung 11. Patterns und Frameworks
wie wird man ein guter Schachspieler?
q lerne Regeln
Figurenamen und –zugmöglichkeiten, Schachbrettgeometrie etc.
q lerne Prinzipien
relativer Figurenwert, strategischer Wert des Brettzentrums,
Angriffsvermögen etc.
q schliesslich und vor allem: lerne von Spielen der Meister
Spielzüge und deren Anwendungssituationen: Muster (Patterns)
es gibt hunderte von solchen Spielzügen/Strategien
iTec
9

Einführung 11. Patterns und Frameworks
wie wird man ein guter Software-Designer?
q lerne Regeln
Algorithmen, Datenstrukturen, Programmiersprachen
q lerne Prinzipien
modulares Programmieren, objektorientiertes Programmieren
q schliesslich und vor allem: lerne von SW-Designs der "Meister"
Muster (Patterns) von allgemeinen Lösungen immer
wiederkehrender Designprobleme
iTec
10

Einführung 11. Patterns und Frameworks
Pattern Beispiel: Singleton
q Absicht
stellt sicher, daß von einer Klasse höchstens ein Objekt erzeugt
wird, und stellt einen globalen Zugriff auf das Objekt bereit
q Motivation
in manchen Anwendungen dürfen einige Klassen nur eine
Objektinstanz besitzen – z.B. ein Printer-Spooler Objekt, ein Firma
Objekt, ein Windows Manager Objekt, ein Roboter Objekt mit
Konfigurationsdaten zur Robotersteuerung, ein DB-Broker.
Objekt in globaler Variablen
keine Garantie für Einmaligkeit
besser:
lasse die Klasse selber ihren Konstruktor überwachen
iTec
11

Einführung 11. Patterns und Frameworks
Beispiel: Singleton
q Idee
– verberge alle Konstruktoren nach aussen: mache sie private
– biete eine neue Methode "instance" nach aussen an, die eine
Referenz auf (das einzige) Objekt zurückgibt
– diese Methode muss eine Klassenoperation sein (static)!
warum?
iTec
12

Einführung 11. Patterns und Frameworks
Beispiel: Singleton
class Singleton {
private static Singleton s = new Singleton();
}
private Singleton() { . . }
public static Singleton Instance() { return s; }
. . . //Attribute und Methoden
das das Klassenattribut Klassenattribut sshält
hält
eine eine Referenz Referenz auf auf das das einzige einzige
Objekt Objekt der der Klasse Klasse Singleton Singleton
mindestens mindestens einen einen Konstruktor Konstruktor
definieren definieren als als private: private:
kein kein (öffentlicher) (öffentlicher) Default- Default-
Konstruktor Konstruktor mehr mehr verfügbar verfügbar
einzige einzige öffentliche öffentliche Zugriffsmethodmethode
auf auf ein ein Singleton- Singleton-
Zugriffs-
Objekt: Objekt: ist ist Klassenmethode
Klassenmethode
Singleton s = Singleton.Instance();
Benutzung: Benutzung: ssreferenziert referenziert das das
einzige einzige Singleton-Objekt
Singleton-Objekt
iTec
13

Einführung 11. Patterns und Frameworks
Beispiel: Singleton (JAVA)
class Singleton {
private static Singleton s =
new Singleton(99);
private int i;
private Singleton(int x) { i = x; }
public static Singleton Instance() {
return s;
}
public int getValue() { return i; }
public void setValue(int x) { i = x; }
}
public class SingletonPattern {
public static void main(String[] args) {
Singleton s = Singleton.Instance();
System.out.println(s.getValue());
Singleton s2 = Singleton.Instance();
s2.setValue(9);
System.out.println(s.getValue());
}
}
iTec
Ausgabe: 99
9
14

Einführung 11. Patterns und Frameworks
es gibt drei Pattern Typen
1. Erzeugungsmuster (creational pattern)
beschreiben Strukturen, die den Prozeß der Objekterzeugung
enthalten. Das Anwendungsprogramm wird von der konkreten
Realisation der Objekterzeugung entkoppelt. Es arbeitet auf
einer höheren Abstraktionsebene und delegiert die Erzeugung
der Objekte an die Erzeugungsstrukturen
2. Strukturmuster (structural pattern)
zeigen auf, auf welche Art und Weise Klassen bzw. Objekte zu
größeren Strukturen zusammengefaßt werden können. Nahezu
alle der vonStrukturmustern beschriebenen Strukturen
entstehen zur Laufzeit, beruhen also auf der Technik der
dynamischen Objektkomposition
iTec
15

Einführung 11. Patterns und Frameworks
es gibt drei Pattern Typen
3. Verhaltensmuster (behavioral patterns)
beschreiben Strukturen, die am Kontrollfluß innerhalb der
Anwendung beteiligt sind. Sie konzentrieren sich also auf
Algorithmen und die Delegation von Zuständigkeiten.
iTec
16

Einführung 11. Patterns und Frameworks
iTec
17

Einführung 11. Patterns und Frameworks
Vorteile von Entwurfsmustern
q Entwickler lernen schnell besseres Design
q Entwickler werden produktiver
q Qualität der Software wird besser
q Kommunikation zwischen Entwicklern wird besser
q Kommunikation bei der Wartung wird besser
iTec
18

Patternbeschreibung 11. Patterns und Frameworks
q Name
den wir als Kürzel für das Muster benutzen können, wenn wir uns darüber
unterhalten.
q Absicht kurze (1 – 2 Sätze) Beschreibung des Ziels des Patterns
q Problem
beschreibt die typische Situation, die eine neue Lösung erfordert. Oft
wird hier ein ganz konkretes Problem beschrieben, anhand dessen das
einzuführende Muster ausprobiert werden kann.
q Lösungsidee
skizziert, wie das Muster aussehen könnte, mit dem das im vorigen
Abschnitt beschriebene Problem gelöst werden könnte.
q Struktur
wird in einem UML Diagramm angegeben, das die statische Struktur der
beteiligten Klassen verdeutlicht.
q Die Beteiligten
iTec
Hier werden die beteiligten Klassen noch einmal in Worten aufgezählt
19
und ihre Rollen ausführlicher beschrieben.

Patternbeschreibung 11. Patterns und Frameworks
q Zusammenspiel
erklärt die Kooperation zwischen den beteiligten Klassen. Dieser Abschnitt
enthält oft auch ein (UML) Diagramm, in dem der Austausch von Nachrichten
zwischen Objekten verdeutlicht wird.
q Anwendbarkeit
beschreibt Situationen, in denen das Muster sinnvoll eingesetzt werden kann,
bzw. die Bedingungen, die gelten müssen, damit es eingesetzt werden kann.
q Folgen
beschreibt die Vor- und Nachteile, die dieses Muster mit sich bringt.
q Implementation
diskutiert Aspekte, die bei Implementation des Musters zu bedenken sind
q Codebeispiele
gibt konkrete Implementationen des Musters an anhand eines typischen
Problems, in den wichtigsten OO-Sprachen (JAVA, C++)
q Bekannte Anwendungen (bekannt!)
q Verwandte Muster
geht auf Beziehungen zwischen diversen Mustern ein; es ist selten so, daß
eine Problemklasse nur durch ein einziges Muster allein entschärft wird.
20
iTec

Proxy 11. Patterns und Frameworks
q Name
Proxy
q Absicht
stelle ein Stellvertreter/Platzhalter für ein Objekt zur Verfügung, um
über dieses Platzhalter-Objekt Zugriff auf das ursprüngliche Objekt
zu garantieren
q Problem
manchmal ist die Erzeugung und Initialisierung eines Objektes
aufwendig – grosse Datenmenge (z.B. Bilddaten), oder "entlegener"
Ort wo das Objekt gespeichert ist (Netz, verteilte DB), oder grosse
Anzahl von Objekten bei Initialisierung einer komplexen Anwendung
q Lösungsidee verschiebe die Objektinitialisierung bis zum eigentlichen
Gebrauch seitens des Verwenders (Klient), und stelle ihm solange nur
ein Stellvertreterobjekt zur Verfügung (Schnittstelle mit den
Operationen des eigentlichen Objekts).
Der Klient soll den Proxy so sehen als ob er das richtige Objekt wäre.
iTec
21

Proxy 11. Patterns und Frameworks
Struktur
Klassendiagramm
Klient
Subjekt
{abstract}
operation()
. . . ()
iTec
EchtesSubjekt
operation()
. . . ()
Objektdiagramm
einKlient:
operation()
vertritt
einProxy:
Proxy
operation()
. . . ()
operation()
operation() {
vertritt.operation();
}
einEchtesSubjekt:
22

Proxy 11. Patterns und Frameworks
q Rollen
Klient: greift auf ein Subjekt über ein Proxy zu, so als ob es
ein EchtesSubjekt wäre. Er ist aber nur mit dem Proxy direkt
verbunden (Referenz, Zeiger)
Subjekt: stellt die gemeinsame Schnittstelle dar, sodass Proxy
überall dort verwendet werden kann, wo eine EchtesSubjekt
gebraucht wird. Hält meistens nur die Operationen (alle
Attribute von EchtesSubjekt geschützt).
Insbesondere stellt Subjekt sicher, dass Proxy und
EchtesSubjekt gleich aussehen
Proxy: ist der Ansprechpartner für Nachrichten eines
Klients. Hält eine Referenz/Zeiger auf das EchteSubjekt, und
ist verantwortlich für die Erzeugung (und evtl. Zerstörung) von
EchtesSubjekt.
iTec
EchtesSubjekt:
enthält die Daten und den Programmcode
23

Proxy 11. Patterns und Frameworks
Rollen (Fortsetzung)
es gibt mehrere Typen von Proxy:
q Remote-Proxy
EchtesSubjekt (Objekte) befindet sich in einem anderen
Adressraum (anderer Prozess, oder woanders im Netzwerk).
Ein Remote -Proxy kodiert und schickt einen Request an
EchtesSubjekt
q Virtuelles Proxy
erzeugt ein umfangreiches Objekt im gleichen Adressraum "auf
Anfrage"
q Schutz-Proxy
kontrolliert den (geschützten) Zugriff auf EchtesSubjekt, z.B.
über Zugriffsrechte
iTec
24

Proxy 11. Patterns und Frameworks
Folgen
q ein Remote-Proxy kann einem Klient verbergen, dass das angesprochene
Objekt (EchtesSubjekt) in anderem Adressraum liegt
q ein Virtuelles Proxy kann optimieren:
– verzögerte Objektinitialisierung (vielleicht nie)
– Lastausgleich bei initialisierungsintensiven Anwendungen
q ein virtuelles Proxy kann selber einfache Daten halten
iTec
25

Proxy 11. Patterns und Frameworks
iTec
26

interface Subjekt {
int getA();
float getB();
}
class Proxy implements Subjekt {
private EchtesSubjekt vertritt;
// delegiere Methodenaufrufe an EchtesS:
}
Proxy 11. Patterns und Frameworks
Beispiel in Java: virtueller Proxy
public int getA() {
iTec
return getEchtesSubjekt().getA(); }
public float getB() {
return getEchtesSubjekt().getB(); }
protected EchtesSubjekt getEchtesSubjekt() {
if ( vertritt == null )
vertritt = new EchtesSubjekt();
return vertritt;
}
lazy lazy initialization
class EchtesSubjekt implements Subjekt {
protected int a;
protected int b;
public int getA() {
System.out.println("EchtesSub.getA()");
return a; }
public float getB() {
System.out.println(" EchtesSub.getB()");
return b; }
public EchtesSubjekt() {a=1; b=1;}
}
public class Klient {
public static void main(String args[]) {
Proxy p = new Proxy();
System.out.println(" a: " + p.getA() );
System.out.println(" b: " + p.getB() );
}
}
27

Zustand/State 11. Patterns und Frameworks
q Name
Zustand/State
q Absicht
lass ein Objekt sein Verhalten ändern (Ausführung einer
Operation) wenn sein interner Zustand sich ändert
q Problem ein Objekt hat interne Zustände (Attributwerte), die
einige seiner Operationen beeinflussen. z.B. Datei öffnen:
Datei
dateiname : String
offen : boolean
oeffnen()
schliessen()
weitereOp()
Spezialisierung
Datei
dateiname : String
oeffnen()
schliessen()
weitereOp()
Problem: ein Dateiobjekt müsste
seine Klasse wechseln können
iTec
OffeneDatei
oeffnen()
schliessen()
GeschlosseneDatei
oeffnen()
schliessen()
28

Zustand/State 11. Patterns und Frameworks
q Lösungsidee
lagere den zustandsabhängigen Teil aus der Klasse aus (eigene
Klasse), implementiere in der Klasse nur den zustandsunabhängigen
Teil, und delegiere zustandsabhängige Operationen an die
ausgelagerte Klasse
q Struktur
operation() {
state.opAbhängig();
}
KlasseMitZustand
opAbhängig()
opUnabhängig()
1
state
Zustand
{abstract}
opAbhängig()
ZustandA
opAbhängig()
ZustandB
opAbhängig()
. . .
Zustandsänderung: - wie wird er geändert ?
- wer bzw. wo wird ein Zustand geändert ?
iTec
29

Zustand/State 11. Patterns und Frameworks
Rollen
q KlasseMitZustand
die eigentliche Klasse, die nur den zustandsunabhängigen Teil
enthält (evtl. mit Operationen die den Zustand verändern). Sie
hält eine Referenz auf den aktuellen Zustand, über die
zustandsabhängige Operationen delegiert werden.
q Zustand
abstrakte Schnittstelle (Polymorphismus) für die delegierten,
zustandsabhängigen Operationen
q konkreter Zustand (ZustandA, ZustandB)
implementieren die zustandsabhängigen Operationen
iTec
Zustandsänderungen:
ersetze aktuell referenziertes Zustandsobjekt durch ein neues
30

Zustand/State 11. Patterns und Frameworks
Anwendbarkeit:
1. wenn ein Objekt Operationen hat, deren Logik von einem
Zustand des Objektes selber abhängt der sich zur Laufzeit
ändern kann
2. das Objekt wenig Zustände hat und die Zustandsübergänge
selber einen einfache Zustandsübergangsgraphen besitzen
3. falls 2 nicht erfüllt ist, empfiehlt sich eine Realisierung mit
einem endlichen Zustandsautomat
iTec
31

Zustand/State 11. Patterns und Frameworks
wenn man komplexe Zustandsübergänge hat, benutzt man vorzugsweise
einen endlichen Zustandsautomaten:
iTec
Zustand
z_i
Zustand
z_j
Ereignis e_k
/
Aktion a_m
im im Zustand z_j z_j führt führt
das das Ereignis e_k e_k zum zum
Folgezustand z_j z_j und und
löst löst Akton Akton a_m a_m aus aus
Zustand
Ereignis
e_1
e_2
. . .
e_k
. . .
z_1 z_2 . . . z_i . . .
(folgezustand,
aktion)
Darstellung in in einer einer
Tabelle von von Paaren:
(folgezustand,aktion)
( z_j ,
a_m )
32

Zustand/State 11. Patterns und Frameworks
ComplexClass
...
actState : State
act : Action;
... event1(..) {
//operation op1 implements event 1
actState = hasSTT.transit(actState,
E1, act );
switch (act) {
case A1: action1(..); //execute action
break;
case A2: action2(..);
. . .
}
event2(..)
...
action1(..) //action A1
action2(..) //action A2
. . .
iTec
hasSTT
1..* 1
stTable //state table
StateTransitionTable
create(ComplexClass cp) //loads table
save()
addState( State st )
addEvent( Event ev )
addTransition(State st1, State st2,
Event ev, Action act)
removeState(...)
...
State transit( State st, Event ev,
Action &act)
33

Zustand/State 11. Patterns und Frameworks
Konsequenzen
q es strukturiert das Objektverhalten nach Zuständen:
– jede Zustandsklasse enthält die Zustandsbesonderheiten
– leichter les- und vor allem wartbar
q unterstützt Zustandsklassifizierung: Zustände sind manchmal
klassifizierbar durch Super-/Subklassenbeziehungen
q Zustände werden explizit gemacht
iTec
34

Beobachter/Observer 11. Patterns und Frameworks
q Name: Beobachter (Observer)
q Absicht
Objekte können Daten bei einem Informationsanbieter
abonnieren. Bei jeder Änderung der abonnierten Daten werden
die Abonnenten automatisch über die Änderung informiert, die
sich dann die geänderten Daten holen.
q Problem
voneinander abhängige Objekte sollen nicht zu stark aneinander
gekoppelt werden, was Wiederverwendbarkeit einschränken
würde.
q Lösungsidee
Trennung von Informationsbereitsteller und einer Menge von
Informationsverarbeitern bzw. Darstellern der Information. Die
Bereitsteller müssen die Verarbeiter nicht direkt kennen: statt
direkter Kommunikation über Aufrufe benutze eine indirekte
über Benachrichtigungen.
iTec
35

Beobachter/Observer 11. Patterns und Frameworks
Struktur
Subjekt
{abstract}
- beobachtetVon : ListOfBeobachter
#benachrichtigen()
+registrieren(beob:Beobachter)
+löschen(beob:Beobachter)
beobachtetVon ?
1..* ? beobachtet
für alle beo in beobachtetVon:
beo.aktualisieren(. . . );
*
Beobachter
{abstract}
- beobachtet : Subjekt
+aktualisieren(. . . )
beobachtet.getMeineDaten();
. . . //aktualisiere zustand
Client
setMeineDaten(x)
MeinSubjekt
-meineDaten : Data
+getMeineDaten(): Data
+setMeineDaten(d:Data)
. . .
. // bearbeite und
. // aktualisiere
. // meineDaten
benachrichtigen();
MeinBeobachter
- zustand
+aktualisieren(. . . )
iTec
36

Beobachter/Observer 11. Patterns und Frameworks
Teilnehmer
q Subjekt
kennt seine Beobachter (beliebig viele) als abstrakte Beobachter;
bietet Schnittstelle zur (Ent)Registrierung von Beobachtern;
hat Operation zur Benachrichtigung registrierter Beobachter
q Beobachter
bietet einen Typ (abstrakte Klasse/Interface) der benachrichtigt
werden kann von Subjekten
q MeinSubjekt
wird unabhängig von Beobachtern programmiert: hält aber Daten von
denen Beobachter-Objekte abhängig sind;
sendet (fast automatisch) Benachrichtigungen an Beobachter-Objekte
wenn Daten sich ändern
q MeinBeobachter
ist abhängig und hält eine Referenz zu einem MeinSubjekt-Objekt;
enthält Daten die mit Daten des Subjekts konsistent sein müssen;
implementiert iTec die aktualisiere-Operation zur Benachrichtigung
37

Beobachter/Observer 11. Patterns und Frameworks
Zusammenspiel
q jedes Objekt der Klasse Subjekt führt eine Liste von Beobachtern, welche
an Veränderungen im Zustand dieses Objekts interessiert sind. registrieren
bzw. loeschen fügt Beobachter in die Liste ein bzw. entfernt sie.
q nach jeder Veränderung schickt das Subjekt sich selbst die Nachricht
benachrichtigen. Diese iteriert die Liste der Beobachter und schickt jedem
Beobachter die Nachricht aktualisieren. Ggf. können Informationen (z. B.
die Art des eingetretenen Ereignisses, oder das benachrichtigende Objekt
selber) als Parameter mitgegeben werden.
q jeder benachrichtigte Beobachter reagiert, indem er beim benachrichtigenden
Sujekt mit getXXX- Nachrichten die ihn interessierenden
Informationen abruft.
q alternativ können der aktualisiere-Nachricht die veränderten Daten gleich
mitgegeben werden, wodurch der Abruf durch getXXX entfällt. Dieses
"Bring"-Prinzip ist effizient, koppelt aber Subjekt und Beobachter stärker
als das mit getXXX realisierte "Hol"-Prinzip.
iTec
38

Beobachter/Observer 11. Patterns und Frameworks
Zusammenspiel
setMeineDaten
ms :MeinSubjekt
registrieren
mb
registrieren
db
mb :MeinBeobachter
db :DeinBeobachter
benachrichtigen
aktualisieren
getMeineDaten
Data
aktualisieren
getMeineDaten
Data
iTec
39

Beobachter/Observer 11. Patterns und Frameworks
Anwendbarkeit
q wenn eine Änderung in einem Objekt Änderungen in anderen
verlangt, und das erstere weiss zur Programmierzeit oder zum
Systemstart nicht, welche anderen von ihm abhängen
q wenn man also dynamische Abhängigkeiten hat
q wenn man Abhängigkeiten in reinen Client/Server-Beziehungen
modellieren möchte zwecks leichterer Änderbarkeit
weiss von
Clientklasse
Serverklasse
weiss nichts von
iTec
40

Beobachter/Observer 11. Patterns und Frameworks
Folgen
q schwache, einseitige Kopplung zwischen unabhängiger und
abhängigen Klassen: erstere kennt nur eine abstrakte
Schnittstelle zur Benachrichtigung
q sauberer Design: Aktualisierungslogik im abhängigen Teil, nicht
im bestimmenden (nur benachrichtigen, nicht aktualisieren)
q dadurch können die beiden Klassentypen zu unterschiedlichen
Systemebenen gehören (nächste Folie)
q unterstützt eine Art Broadcasting
iTec
41

Beobachter/Observer 11. Patterns und Frameworks
bekannte Anwendungen
von Präsentationsschicht unabhängige Anwendungslogik
Präsentationsschicht
GUI-Komponenten GUI-Komponenten repräsentieren
repräsentieren
Daten Daten der der Anwendungslogikschicht
Anwendungslogikschicht
GUI-Komponente1
GUI-Komponente2
GUI-Komponente3
Klasse1
Anwendungslogikschicht
Klasse2
Klassen Klassen der der Anwendungslogikschicht
Anwendungslogikschicht
verarbeiten verarbeiten Daten, Daten, ohne ohne sie sie am am Bildschirschirm
zu zu präsentieren
Bild-
präsentieren
iTec
Abhängigkeit
42

Beobachter/Observer 11. Patterns und Frameworks
Implementation
q wann soll die Registrierung (Löschen) geschehen?
meistens im Konstruktor (Destruktor) eines Beobachters
q mehrere Subjekte: wie erkennen, welches Subjekt benachrichtigt?
Parameter des Subjektes (this) bei Benachrichtigung übergeben
q muss immer gleich aktualisiert werden?
nein, man kann eine lazy-computing Technik einsetzen
iTec
43

Beobachter/Observer 11. Patterns und Frameworks
lazy computing: erst dann berechnen, wenn Daten gebraucht werden
Client
getMeinAttribut()
MeinBeobachter
-meinAttribut: Typ //abhängiges Attr.
-meinAttributStatus //valid/invalid
+benachrichtige()
+getMeinAttribut(): Typ
void benachrichtige() {
meinAttributStatus = invalid;
}
Typ getMeinAttribut() {
if (meinAttributStatus == invalid)
{
beobachtet.getMeineDaten();
. . . //Neuberechnung von meinAttribut
meinAttributStatus = valid;
}
return meinAttribut; }
iTec
Vorteil:
weniger Berechnungen, falls Subjekt
wesentlich öfter benachrichtigt als
Beobachter befragt wird
44

Beobachter/Observer
public class MeinSubjekt
extends Subjekt {
private int wert;
public MeinSubjekt( int wert ) {
this.wert = wert;
}
public void setWert( int wert )
{
this.wert = wert;
benachrichtigen();
}
public int getWert() {
return wert;
}
}
iTec
4. Patterns und Frameworks
public abstract class Subje kt {
}
private Beobachter[] beobachtetVon =
new Beobachter[MAXB];
private int anzBeobachter = 0;
public void registrieren( Beobachter beob ) {
beobachtetVon[ anzBeobachter++] = beob;
}
public void löschen( Beobachter beob ) {
for ( int i = 0; i < anzBeobachter; ++i ) {
if (beobachtetVon[i] == beob) {
- - observerCnt;
for ( ; i < anzBeobachter; ++i)
beobachtetVon[ i ] = beobachtetVon[ i + 1 ];
break;
}
}
}
public void benachrichtigen() {
for (int i = 0; i < anzBeobachter; ++i)
beobachtetVon[i].aktualisieren( this );
}
45

Beobachter/Observer 11. Patterns und Frameworks
interface Beobachter {
public void aktualisieren( Subje kt subjekt );
}
public class MeinBeobachter
implements Beobachter {
int abhgWert; //abhängiger Wert
public class Anwendung {
public static void main( String[] args )
MeinSubjekt sub = new MeinSubjekt( 99 );
MeinBeobachter beo =
new MeinBeobachter( sub );
}
public MeinBeobachter( Subjekt subjekt ) {
abhgWert = subjekt.getWert() / 2;
subjekt.registrieren( this );
}
public void aktualisieren( Subjekt subjekt ) {
abhgWert = subjekt.getWert() / 2;
//zum Beispiel
}
public int getAbhgWert() {
return abhgWert;
}
iTec
}
}
sub.setWert( 2 );
System.out.println( "abhgWert: " +
beo.getAbhgWert() );
hier hier wird wird im im Hintergrund der der
abhängige Wert Wert von von
MeinBeobachter aktualisiert.
Ausgabe: abhgWert: 11
46

Adapter 11. Patterns und Frameworks
q Name: Adapter
q Absicht
erlaubt die Zusammenarbeit von Klassen die unterschiedliche Schnittstellen
haben. Adapter wird als verbindendes Element zwischen die
beiden Klassen eingefügt.
q Problem
Schnittstellenproblem: eine Klasse "Verwender" (Klient) soll eine andere
Klasse "Dienstanbieter" (Ziel) verwenden. Der Verwender kann jedoch
auf den Dienstanbieter nicht zugreifen, da der Verwender eine andere
Schnittstelle erwartet als die, die vom Dienstanbieter angeboten wird.
q Lösungsidee
Der Dienstanbieter wird in einen Adapter eingepackt. Der Adapter
bietet die Schnittstelle an, die der Verwender benötigt.
Dazu gibt es zwei Varianten:
• Objektadapter
• Klassenadapter
iTec
Adapter
47

Adapter 11. Patterns und Frameworks
Struktur: Objektadapter
Klient
benutzt
Ziel
operation()
adaptiert
AdaptierteKlasse
spezifischeOperation()
Adapter
operation()
operation()
. . .
adaptiert.spezifischeOperation()
. . .
Adaption:
q andere Operationensignatur – Operations- und Parameternamen,
Parametertypen und -reihenfolge
q andere Operationsfunktionen – ähnliche, aber nicht genau gleiche
48
iTec
Semantik

Adapter 11. Patterns und Frameworks
Adapter Beispiel:
ein Zeicheneditor mit fremder Komponente TextAnzeige
1 manipuliert *
Zeicheneditor
zeichne()
begrenzungsrahmen()
GraphischesObjekt
{abstract}
begrenzungsRahmen()
zeichne()
TextAnzeige
getUrsprung()
getHoehe()
getBreite()
zeigMich()
Linie
begrenzungsRahmen()
zeichne()
Kreis
begrenzungsRahmen()
zeichne()
iTec
TextAnzeige passt nicht zu GraphischesObjekt:
Problem für den Zeicheneditor
49

Adapter 11. Patterns und Frameworks
Adapter Beispiel: ein Zeicheneditor
mit fremder Komponente TextAnzeige
1 manipuliert *
Zeicheneditor
zeichne()
begrenzungsrahmen()
GraphischesObjekt
{abstract}
begrenzungsrahmen()
zeichne()
einseitige Beziehung:
TextAnzeige auch auch ohne ohne
Quellcode verwendbar
1
text
TextAnzeige
getUrsprung()
getHoehe()
getBreite()
zeigMich()
Linie
begrenzungsrahmen()
zeichne()
Kreis
begrenzungsrahmen()
zeichne()
Text
begrenzungsrahmen()
zeichne()
1
iTec
begrenzungsrahmen()
text.getHoehe()
text.getBreite()
. . .
zeichne()
. . .
text.zeigMich()
. . .
50

Adapter 11. Patterns und Frameworks
Struktur: Klassenadapter
Klient
Ziel
operation()
AdaptierteKlasse
spezifischeOperation()
Adapter
operation()
benutzt Mehrfachvererbung
operation()
. . .
spezifischeOperation()
. . .
iTec
51

Adapter 11. Patterns und Frameworks
Folgen
q Klassenadapter
benutzt nur eine Objekt, während Objektadapter aus zwei
bestehen
q Objektadapter
kann auch Objekte von Unterklassen der adaptierten Klasse
adaptieren, was der Klassenadapter nicht kann
iTec
52

Adapter 11. Patterns und Frameworks
Implementation in JAVA: Objektadapter mit einem Interface
class WasIchHabe {
public void g() {}
public void h() {}
}
interface WasIchMoechte {
void f();
}
class WasIchBenutze {
public void op(WasIchMoechte wim) {
wim.f();
}
}
class Adapter implements WasIchMoechte {
//Referenz auf was adaptiert werden soll
private WasIchHabe wasichhabe;
//Konstruktor verbindet Adapter mit WasIchHabe
public Adapter(WasIchHabe wih) {
wasichhabe = wih;
}
public void f() {
// Implementiert Methode mit den
// Methoden in WasIchHabe:
wasichhabe.g();
wasichhabe.h();
}
}
WasIchBenutze WasIchMoechte WasIchHabe
iTec
Adapter
53

Kompositum 11. Patterns und Frameworks
Zweck
Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-
Hierarchien zu repräsentieren.
Das Kompositionsmuster ermöglicht es dem Klienten (Benutzer
dieses Musters), sowohl einzelne Objekte als auch Kompositionen
von Objekten einheitlich zu behandeln.
Motivation
viel verwendet in Grafik-Anwendungen
und im Produktionsbereich (Produktbäume)
iTec
54

Kompositum 11. Patterns und Frameworks
Beispiel:
Grafikanwendung
Grafik
zeichne()
hinzufügen(Grafik)
entfernen(Grafik)
holeNächstesKind()
{abstract}
*
enthält
iTec
Linie
zeichne()
Rechteck Text
zeichne() zeichne()
für für alle alle g in in "enthält":
g.zeichne();
Bild
zeichne() //Delegation!!
hinzufügen(Grafik g)
entfernen(Grafik)
holeNächstesKind()
füge füge g g ein ein in in
"enthält" "enthält"
55

Kompositum 11. Patterns und Frameworks
iTec
56

Kompositum 11. Patterns und Frameworks
Komponente
• Deklariert die Schnittstelle für Objekte in der zusammengefügten Struktur.
• Implementiert, sofern angebracht, ein Defaultverhalten für die allen Klassen gemeinsame
Schnittstelle (ist in JAVA dann abstrakte Klasse).
• Deklariert eine Schnittstelle zum Zugriff auf und zur Verwaltung von Kindobjekten.
• Definiert optional eine Schnittstelle zum Zugriff auf das Elternobjekt einer Komponente
innerhalb der rekursiven Struktur und implementiert sie, falls dies angebracht erscheint.
Blatt
• Repräsentiert Blattobjekte in der Komposition. Ein Blatt besitzt keine Kindobjekte.
• Definiert Verhalten für die primitiven Objekte in der Komposition.
Kompositum
• Definiert Verhalten für Komponenten, die Kindobjekte haben können.
• Speichert Kindobjektkomponenten.
• Implementiert kindobjekt-bezogene Operationen der Schnittstelle von Komponente.
Klient
Rollen
57
• Manipuliert iTec die Objekte in der Komposition durch die Schnittstelle von Komponente.

Kompositum 11. Patterns und Frameworks
Verwendung
Verwende das Kompositionsmuster, wenn
• Teil-Ganzes-Hierarchien von Objekten repräsentiert werden sollen
• KKKlienten in der Lage sein sollen, die Unterschiede zwischen
zusammengesetzten und einzelnen Objekten zu ignorieren.
Klienten behandeln alle Objekte in der zusammengesetzten Struktur
einheitlich.
iTec
58

Singleton/Kompositum 11. Patterns und Frameworks
Beispiel
ein binärer Suchbaum: Entwurf als Kompositum und mit leerem
Baum als Singleton
q gewünscht: eine Klasse eines binären Suchbaums, dessen
Objekte auch leer sein können: Binärbaum ohne Elemente
q Anforderung: der leere Baum muss genauso ansprechbar sein
wie ein nichtleerer binärer Suchbaum: also mit Operationen
– isEmpty(), isIn(Object o), insert(Object o)
q ein leerer Baum kann also nicht als Nullreferenz realisiert
werden !
iTec
59

Singleton/Kompositum 11. Patterns und Frameworks
ein binärer Suchbaum:
Entwurf als Kompositum
und mit leerem Baum
als Singleton
«Interface»
BinSearchTree
isEmpty(): boolean
isIn(Object o): boolean
insert(Object o): BinSearchTree
0..2
hasFather
hasChild
iTec
«Singleton»
EmptyTree
empty: EmptyTree
isEmpty(): boolean
isIn(Object o): boolean
insert(Object o): BinSearchTree
Node
info: Object
leftChild: BinSearchTree
rightChild: BinSearchTree
isEmpty(): boolean
isIn(Object o): boolean
insert(Object o): BinSearchTree
0..1
60

Singleton/Kompositum 11. Patterns und Frameworks
ein binärer Suchbaum: Entwurf als Kompositum und mit leerem
Baum als Singleton
:ClientClass
empty:EmptyTree
b =
EmptyTree.Instance()
Instance()
b = b.insert(o1)
b = b.insert(o2)
b = b.insert(o3)
insert(o1)
insert(o2)
insert(o3)
new(o1)
b:Node
{b.info < o1}
{b.info > o2}
new(o2)
new(o3)
b.leftChild:Node
b.rightChild:Node
iTec
61

Singleton/Kompositum 11. Patterns und Frameworks
ein binärer Suchbaum:
JAVA Code
einzige einzige Instanz Instanz als als
Klassenattribut
Klassenattribut
alle alle Konstruktoren
Konstruktoren
sind sind damit damit privat privat
public interface BinSearchTree {
boolean isEmpty();
boolean isIn(Object e);
BinSearchTree insert(Object e);
}
//----------------------------------------------------------------
public class EmptyTree implements BinSearchTree {
private static EmptyTree empty = new EmptyTree();
private EmptyTree() {}
Benutzung: Benutzung:
Instance() Instance() als als "Konstruktor"
"Konstruktor"
gibt gibt einziges einziges empty empty als als
EmptyTree-Objekt EmptyTree-Objekt heraus heraus
hier hier wird wird aus aus dem dem einzigen einzigen
EmptyTree-Objekt EmptyTree-Objekt jeweils jeweils
ein ein neuer neuer Baum Baum erzeugt erzeugt der der
nur nur aus
iTec aus einer einer Wurzel Wurzel besteht besteht
public static EmptyTree Instance() {
return empty;
}
public boolean isEmpty() { return true; }
public boolean isIn(Object e) { return false; }
public BinSearchTree insert(Object e) {
return new Node(e);
}
}
62

Singleton/Kompositum 11. Patterns und Frameworks
public class Node implements BinSearchTree {
protected Object info;
protected BinSearchTree left;
protected BinSearchTree right;
public Node(Object info) {
}
this.info = info;
left = EmptyTree.Instance();
right = EmptyTree.Instance();
public boolean isEmpty() { return false; }
public boolean isIn(Object e) {
switch ( info.compareTo(e) ) {
case -1: return left.isIn(e);
case 0: return true;
case +1: return right.isIn(e);
}
return false;
} iTec
Kompositum: Kompositum:
füge füge leere leere Bäume Bäume
als als Blätter Blätter ein ein
public BinSearchTree insert(Object e) {
switch ( info.compareTo(e) ) {
case -1:
left = left.insert(e);
break;
case 0: break;
case +1:
right = right.insert(e);
break;
}
return this;
}
}
63

Singleton/Kompositum 11. Patterns und Frameworks
Benutzung des binären Suchbaumes
public static void main( String args[ ] ) {
}
BinSearchTree tree = EmptyTree.Instance();
tree = readTree( tree, "dateiname" );
. . .
public BinSearchTree readTree( BinSearchTree bst, String datei ) {
int wert;
// in einer Schleife werte einlesen
. . .
bst = bst.insert( Integer(wert) ); Achtung: Achtung: falls falls ein ein leerer leerer Baum Baum
. . .
unser unser Binärbaum Binärbaum
} hat hat allgemeine allgemeine
Knoten, Knoten, die die Informationen Informationen vom vom
Typ Typ Object Object halten halten (keine (keine Templates!) Templates!)
Deshalb: Deshalb: Wrapperklasse Wrapperklasse um um den den
Integerwert! Integerwert!
iTec
übergeben übergeben wird, wird, ändert ändert sich sich
die die Objektreferenz Objektreferenz durch durch die die
Einfügung Einfügung des des ersten ersten Knotens Knotens
64

Kompositum 11. Patterns und Frameworks
wichtig beim Kompositum ist die Unterscheidung von Klassen- und
Objektbäumen – das Kompositum generiert Objektbäume
Klasse1
objA
Klasse11
Klasse12
objB
objC
objD
objE
objF
Klasse121
Klasse122
q Klassenbäume sind statische Vererbungshierarchien
q Objektbäume sind dynamisch erzeugte Bäume mit Knotenobjekten
iTec
65

Dekorierer 11. Patterns und Frameworks
q Name: Dekorierer (decorator oder wrapper)
q Absicht: füge einem Objekt dynamisch Zusatzfunktionalität hinzu
q Problem: wenn man zu einer Basisfunktionalität wie Grafikdarstellung
oder einer Ein-/Ausgabe vielfache Zusatzfunktionalität wie
in einem Baukasten frei kombinierbar hinzufügen möchte, ergibt
sich rasch eine kombinatorische Vielfalt, die man nur noch schwer in
einer statischen Klassenstruktur darstellen und warten kann.
q Lösungsidee: kombiniere die Zusatzfunktionalität dynamisch in einer
Umhüllung in mehreren Schichten (Wrapper) um das ursprüngliche
Objekt herum. Jede Hülle (Dekoriererklasse) kann genauso
angesprochen werden wie das ursprüngliche Objekt
iTec
66

Dekorierer 11. Patterns und Frameworks
Struktur
Komponente
{abstract}
+operation()
1
KonkreteKomponente
Dekorierer
hatKomponente
{abstract}
+operation()
+operation()
operation() {
zusatzoperationA();
//sende operation weiter:
hatKomponente.operation();
}
KonkreterDekoriererA
+operation()
#zusatzOperationA()
KonkreterDekoriererB
+operation()
#zusatzOperationB()
. . .
iTec
67

Dekorierer 11. Patterns und Frameworks
Rollen
q Komponente:
die Schnittstelle für einen Klienten zum Gebrauch eines
dekorierten Objektes
q KonkreteKomponente:
Objekt, das eine Basisfunktionalität bereitstellt welche mit
Zusatzfunktionalität dekoriert werden kann
q Dekorierer:
enthält eine Referenz zu einer weiteren Komponente auf der
die Operation weitergesandt wird
q KonkreterDekorierer:
fügt Zusatzfunktionalität zur Operation der
KonkretenKomponente hinzu (dekoriert)
iTec
68

Dekorierer 11. Patterns und Frameworks
Zusammenspiel
dA:KonkreterDekoriererA
hatKomponente
dB:KonkreterDekoriererB
hatKomponente
kp:KonkreteKomponente
operation()
zusatzOperationA()
operation()
zusatzOperationB()
operation()
iTec
69

Dekorierer 11. Patterns und Frameworks
Beispiel
. . .
/*display text*/
. . .
Component
{abstract}
+draw()
1
hasComponent
TextView
+draw()
Decorator
{abstract}
+draw()
hasComponent. draw()
scrollDraw()
hasComponent. draw()
borderDraw()
BorderDecorator
+draw()
#borderDraw()
ScrollDecorator
+draw()
#scrollDraw()
BW 1
:BorderDecorator
SW 1
:ScrollDecorator
T 1
:TextView
draw()
iTec
draw()
draw()
70

Dekorierer 11. Patterns und Frameworks
Konsequenzen
q die Verbindung der Komponenten über hatKomponente wird im
Konstruktor erzeugt:
KonkreteKomponente kp
= new KonkreteKomponente();
KonkreterDekoriererA kdA = new KonkreterDekoriererA( kp ); //kdA mit kp verbunden
KonkreterDekoriererB kdB = new KonkreterDekoriererB( kdA ); //kdB " kdA "
. . .
kdB.operation();
oder:
KonkreterDekoriererB kdB = new KonkreterDekoriererB(
iTec
KonkreterDekoriererB
KonkreterDekoriererA
KonkréteKomponente
new KonkreterDekoriererA(
new KonkreteKomponente( ) ) );
71

Dekorierer 11. Patterns und Frameworks
Konsequenzen
q das Muster erlaubt, alle Kombinationen von Zusatzfunktionalität
in einer einfachen Klassenstruktur zu beschreiben.
Eine explizite Beschreibung wäre sehr aufwendig.
q es ist einfach, neue Zusatzfunktionalität einzufügen
q Nachteil: das vom Klienten angesprochene Objekt ist ein
Dekorierer, nicht das Hauptobjekt (KonkreteKomponente):
alle Dekorierer müssen sämtliche Operationen des Hauptobjekts
anbieten, auch wenn sie diese nicht dekorieren
iTec
allerdings können diese Operationen für alle Konkreten-
Dekorierer in der (abstrakten) Superklasse Dekorierer mit
einfacher Delegation an das Hauptobjekt implementiert werden
(siehe nächste Folie)
72

Dekorierer 11. Patterns und Frameworks
nichtdekorierte Operationen
werden einfach zur
KonkretenKomponente
durchgereicht
Komponente
{abstract}
+operation1()
+operation2()
+operation3()
1
hatKomponente
KonkreteKomponente
+operation1()
+operation2()
+operation3()
Dekorierer
+operation1()
+operation2()
+operation3()
{abstract}
operation2() {
hatKomponente.operation2();
}
operation3() {
hatKomponente.operation3();
}
operation1() {
zusatzoperationA();
//sende operation weiter:
hatKomponente.operation1();
}
iTec
KonkreterDekoriererA
+operation()
#zusatzOperationA()
KonkreterDekoriererB
+operation()
#zusatzOperationB()
. . .
73

Dekorierer 11. Patterns und Frameworks
Zusammenspiel: Durchreichen nichtdekorierter Operationen
dA:KonkreterDekoriererA
hatKomponente
dB:KonkreterDekoriererB
hatKomponente
kp:KonkreteKomponente
operation3()
operation3()
operation3()
iTec
74

Objektfabriken 11. Patterns und Frameworks
Problem:
Polymorphismus in Vererbungshierarchien:
man kann Spezialisierungen
polymorph benutzen, und neue
Spezialisierungen verlangen keine
Änderung bei der Benutzung: schön!
pPZ
alles wird zu Polygon
. . .
void optimiereLayout( Polygon[] pP, int anzahl) {
. . .
for ( i=0; i < anzahl; i++ ) {
f[i] = pP[i].berechneFlaeche();
. . .
pP[i].verschieben(dx, dy);
pP[i].fuellen( rot );
}
. . .
Aber:
irgendwo muss man die Objekte
erzeugen - und da muss man
konkret werden. Diese Erzeugungen
können weit verstreut sein - eine
Änderung wird aufwendig und
fehleranfällig
iTec
Polygon[] pPZ;
. . .
pPZ[k++] = new Dreieck(p1,p2,p3);
. . .
pPZ[k++] = new Rechteck(lo, ru);
. . .
pPZ[k++] = new Polygon(parray);
. . .
optimiereLayout( pPZ, k ) ;
Änderungswunsch:
Änderungswunsch:
DreieckMitGrafik(
DreieckMitGrafik(
p1, p1, p2, p2, p3 p3 ))
75

Objektfabriken 11. Patterns und Frameworks
Lösungsidee:
kann man nicht auch die Erzeugung kapseln - und dann sogar
polymorph gestalten?
Antwort:
ja, und zwar in einer "Objekterzeugungsfabrik" - Object Factory
erzeuge (gewünschtesObjekt )
Objektfabrik
neues Objekt
erzeuge( Dreieck)
FigurenFabrik
neues Dreieck
Fabrikmuster sind sind
Erzeugungsmuster
iTec
new DreieckMitGrafik(...)
76

Objektfabriken 11. Patterns und Frameworks
abstract class Figur {
public abstract void zeichne();
public abstract void lösche();
}
public static Figur fabrik( String typ )
throws FalscheFigurenErzeugung {
if ( typ.equals("Kreis") ) return new Kreis();
if ( typ.equals("Rechteck") ) return new Rechteck();
throw new FalscheFigurenErzeugung( typ );
}
class Kreis extends Figur {
Kreis() {} //Konstruktor mit Paketsichtbarkeit
public void zeichne() {
System.out.println("Kreis.zeichne");
}
public void lösche() {
System.out.println("Kreis.loesche");
}
}
class Rechteck extends Figur { . . .
iTec
1. Schritt:
wie man die Erzeugung
von Objekten kapselt
77

Objektfabriken 11. Patterns und Frameworks
public class FigurenFabrik1 {
String figlist[] = { "Kreis", "Rechteck",
"Rechteck", "Kreis", "Kreis", "Rechteck" };
List figuren = new ArrayList();
public void test() {
try {
for( int i = 0; i < figlist.length; i++)
figuren.add( Figur.fabrik( figlist[i] ) );
} catch( FalscheFigurenErzeugung e ) {
System.out.println( e.getMessage() );
}
Iterator figIt = figuren.iterator();
while( figIt.hasNext() ) {
Figur f = (Figur)figIt.next();
f.zeichne();
f.lösche();
}
}
public static void main(String args[]) {
new FigurenFabrik1().test();
}
}
iTec
78

Objektfabriken 11. Patterns und Frameworks
2. Schritt: wie man eine polymorphe Erzeugung bereitstellt:
das Fabrikmuster
Abhängigkeit (UML)
abstrakte Produkt Meu fabrik(. fabrik(. . .) .{
.) {
abstrakte Klasse: Klasse:
Product return return create(. create(. ...);
Product fabrik(..) fabrik(..)
.);
nicht }
nicht implementiert implementiert
}
Produkt
operation1(..)
operation2(..)
. . .
(Name)
ProduktFabrik
create(. . .): Produkt
fabrik( . . . ): Produkt
fabrik(..)
Klient
KonkretesProdukt
KonkretesProdukt(..)
operation1(..)
operation2(..)
. . .
iTec
(Konstruktor)
KonkretesProduktFabrik
create(. . .): Produkt
Eine Anwendung benutzt die Produktfabrik, um
Objekte zu erzeugen. Die KonkreteProduktFabrik
erzeugt ein KonkretesProdukt, dessen Klasse für die
Anwendung transparent ausgetauscht werden kann.
79

Objektfabriken 11. Patterns und Frameworks
Fabrik-Beispiel: eine Menufabrik
Menu
addOption(option:String)
removeOption(option:String)
select(): String
. . .
Menu Menu fabrik(String fabrik(String titel) titel) {{
return return create(titel); create(titel);
}}
Menufabrik
create(titel:String): Menu
fabrik(titel:String): Menu
iTec
KonsoleMenu
addOption(option:String)
removeOption(
option:String)
select(): String
. . .
AWTMenu
. . .
KonsoleMenufabrik
create(titel:String):
Menu
AWTMenufabrik
create(titel:String):
Menu
80

Objektfabriken 11. Patterns und Frameworks
das Fabrikmuster kapselt die Erzeugung von Objekten einer Klasse.
Häufig sind aber Objekte mehrerer zusammenhängender Klassen in
einer Fabrik zu erzeugen.
das AbstrakteFabrik Muster
erzeuge (gewünschtesObjekt1 )
Objekt1fabrik
neues Objekt1
gemeinsame Basis
(z.B. graphische Menuelemente ein
bestimmtes Betriebssystem)
erzeuge (gewünschtesObjekt2 )
Objekt2fabrik
neues Objekt2
iTec
81

Objektfabriken 11. Patterns und Frameworks
AbstrakteFabrik: die Struktur
iTec
82

Objektfabriken 11. Patterns und Frameworks
Anwendbarkeit von Abstrakten Fabriken
q wenn man eine Anwendung braucht, die von der Erzeugung
ihrer "Produkte" und deren Komposition/Aggregation
unabhängig sein soll
q wenn man Produktfamilien hat
q im Design von Klassenbibliotheken
da Polymorphismus einer der Pfeiler des objektorientierten Ansatzes ist,
und eine polymorphe Objekterzeugung das Gegenstück zu polymorpher
Benutzung von Objekten ist, ist das Fabrikmuster eines der am
weitesten verbreiteten überhaupt!
iTec
83