SE1011 Kap5 2

Software Engineering
Wintersemester 2010/11
Kapitel 5: Entwurf
Prof. Dr. Markus Müller-Olm
Institut für Informatik, WWU Münster
Unter Verwendung von Folien von Herbert Kuchen

(WWU Münster)
Erinnerung: Wasserfallmodell der Softwareentwicklung
Planung
Definition
Entwurf
Implementierung
Test
Einsatz & Wartung

Überblick
5.1 Einführung
5.2 Schichtenarchitekturen
5.3 Prinzipien des Architekturenwurfs
5.4 Entwurfsmuster
Prof. Dr. Markus Müller-Olm, WWU Münster Software Engineering, WS 2010/2011, Kapitel 5: Entwurf 3
5.4 Entwurfsmuster
Bewährte Lösungsansätze für oft wiederkehrende Entwurfsprobleme
Auf Flexibilität, Wartungsfreundlichkeit und Erweiterbarkeit zielende

Systeme von Klassen
Wiederverwendung (engl. reuse) auf Entwurfsebene
Warum mit Entwurfsmustern beschäftigen?
Mechanismen kennen lernen, um Erweiterbarkeit und Änderbarkeit
eigener Software zu erreichen:
Entwurfmuster zeigen, dass und wie durch geschickte Strukturierung mehr
erreicht werden kann, als nur, dass die Software „irgendwie“ läuft.
Namen von Entwurfsmustern bieten gemeinsames Vokabular zur

Benennung gewisser Entwurfslösungen, dadurch:
einfachere und klarere Verständigung und Diskussion zwischen Entwicklern
einfachere und klarere Dokumentation von Entwurfsentscheidungen
Verständnis der in Frameworks verwendeten Entwurfsmuster:

z.B.: Java Swing: Observer-Muster, Kompositum-Muster, ...
Grund für Muster-Verwendung in Frameworks:
Erweiterung und Anpassung ohne Verändern vorgefertigter Klassen
ermöglichen
Referenzen zu Entwurfmustern
Klassisches Buch der „GoF“ („Gang of Four“):

E. Gamma, R Helm, R. Johnson, J. Vlisides
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley, 1995. (Deutscher Titel: Entwurfsmuster)
Neueres Buch, ungewöhnlich gemacht aber fundiert:

Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates
Head First Design Patterns
O´Reilly, 2004. (Deutsch: Entwurfsmuster von Kopf bis Fuß)
Das Buch diskutiert auch Realisierung in Java
Entwurfsmuster
Jedes Muster hat Vor- und Nachteile, z.B.:
Flexibilität ↔ Overhead,
#Objekte,
Welche Änderungen/Erweiterungen werden gut unterstützt?
Dasselbe Problem z.T. durch verschiedene, alternative Muster lösbar

→ Vor Muster-Anwendung überlegen, welches Muster die Ziele am
besten erreicht.
Dabei wahrscheinliche Änderungen/Erweiterungen vorhersehen
(Software-Technik-Maxime: „Anticipate Change“ !)
Muster kombinierbar
Klassenbasiert ↔ objektbasiert
Vererbung ↔ Komposition & Delegation
white box reuse ↔ black box reuse
Einteilung von Entwurfsmuster
1. Erzeugungsmuster:
z.B. Abstrakte Fabrik, Erbauer, Fabrikmethode, Prototyp, Singleton
2. Strukturmuster:
z.B. Adapter, Brücke, Dekorierer, Fassade, Fliegengewicht,
Kompositum, Stellvertreter
3. Verhaltensmuster:
z.B. Befehl, Beobachter, Besucher, Iterator, Memento, Strategie,
Interpreter, Schablonenmethode, Vermittler, Zustand,
Zuständigkeitskette
Die kursiv geschriebenen Muster werden im Folgenden besprochen.
5.4.1 Erzeugungsmuster
Erzeugungsmuster ...
kapseln den Erzeugungsprozess von Objekten
helfen dadurch, Systeme unabhängig von der Art der Erzeugung,
Zusammensetzung und. Repräsentation der Objekte zu machen
Klassenbasierte Erzeugungsmuster...
nutzen Vererbung zur Variation der instantierten Klasse
Objektbasierte Erzeugungsmuster ...

delegieren die Instantiierung an ein anderes, leicht
austauschbares Objekt
5.4.1.1 Abstrakte Fabrik
Abstrakte Fabrik:
objektbasiertes Erzeugungsmuster
Ziel:
Schnittstelle zum Erzeugen von Familien verwandter
Objekte bieten
Objektfamilie soll leicht konsistent austauschbar sein
Abstrakte Fabrik: Beispielanwendung
Ziel: Klassenbibliothek für Benutzerschnittstellen, die mehrere
Look&Feel-Standards unterstützen,
z.B. Motif, Presentation Manager
Grundidee: Anwendung (Klient) arbeit mit abstrakten Klassen für

Fenster, Scrollbar, etc., die für jeden unterstützen Standard speziell
erweitert werden:
Klient
Fenster
PMFenster MotifFenster
Scrollbar
PMScrollbar MotifScrollbar
Problem:
Bei Erzeugung von Graphikobjekten (new-Kommandos) muss sich
der Klient für den konkreten Standard entscheiden:
z.B. Fenster f = new PMFenster();
Bei Wechsel des Standards müssen alle new-Kommandos

konsistent geändert werden.

Lösungsidee: Erzeugungsprozess in „Fabrik“ kapseln
Unterliegende Heuristik: „Encapsulate what varies“
WidgetFabrik
ErzeugeScrollbar() Klient
ErzeugeFenster() Fenster
PMFenster MotifFenster
MotifWidget PMWidget
Fabrik Fabrik
ErzeugeScrollbar() Erzeuge Scrollbar() Scrollbar
ErzeugeFenster() ErzeugeFenster()
PMScrollbar MotifScrollbar
Statt z.B. Fenster f = new PMFenster;

jetzt: Fenster f = wf.ErzeugeFenster();
Die WidgetFabrik wf wird „global“ mit einer der konkreten Fabriken
initialisiert (z.B. unter Verwendung des Singleton-Musters).
Abstrakte Fabrik: Allgemeine Struktur
Abstrakte Fabrik Klient
ErzeugeProduktA()
ErzeugeProduktB() AbstraktesProd.A
ProduktA2 ProduktA1
KonkreteFabrik1 KonkreteFabrik2
ErzeugeProduktA() ErzeugeProduktA()
ErzeugeProduktB() ErzeugeProduktB()
AbstraktesProd.B
ProduktB2 ProduktB1
Erinnerung: Wird der Klassenname kursiv geschrieben, so ist die Klasse eine
abstrakte Klasse (im Sinne von UML).
In einer Java-Implementierung wäre sie also typischerweise eine abstrakte
Klasse oder ein Interface.
Abstrakte Fabrik: Bemerkungen
Anwendbarkeit (u.a.):
System soll mit Produktfamilie konfiguriert werden
Unabhängigkeit von konkreter Art der „Produkte“ erwünscht
Eigenschaften:
Austausch von Produktfamilie durch eine einzige Änderung,
den Austausch der konkreten Fabrik
Klassen der erzeugten Objekte durch Fabrik vom Klienten isoliert
Garantierte Konsistenz der erzeugten Objekte

z.B: PMFenster werden nicht mit MotifScrollbars kombiniert.
Unterstützung einer Produktfamilie mit anderer Schnittstelle schwierig
Bei sehr vielen unterstützten Produktfamilien wird das Muster geeignet

variiert um Subklassenexplosion zu vermeiden (siehe Gamma et. al.)
5.4.1.2 Fabrikmethode (Factory Method)
Klassenbasiertes Erzeugungsmuster
Ziel:
Eine Klasse (z.B. in einem Framework) muss Objekte erzeugen,
deren Klasse sie nicht kennt
Lösungsidee:
Klassenschnittstelle mit Operationen zum Erzeugen eines Objekts
Unterklassen entscheiden, von welcher Klasse das erzeugte Objekt

ist
Fabrikmethode: Beispielanwendung
Framework für Anwendungen, die mehrere Dokumente gleichzeitig
präsentieren/bearbeiten können
Verschiedene Anwendungen präsentieren verschiedene Arten von
Dokumenten (z.B. Texte, Bilder, MP3-Files etc.)
Dokument dokumente Anwendung

Öffne() ErzeugeDokument() Dokument dok =
Schliesse() NeuesDokument() ErzeugeDokument();
Speichere() ÖffneDokument() dokumente.FügeHinzu(dok);
SetzeZurück() dok.Öffne();
MeinDokument MeineAnwendung return

ErzeugeDokument() new MeinDokument()
Klassen Anwendung und Dokument sind abstrakt.

Klasse Anwendung erzeugt Dokumente, weiß aber nicht, welche.
Art des Dokuments wird erst von der Subklasse festgelegt
und zwar durch geeignetes Überschreiben der Methode ErzeugeDokument.
Fabrikmethode: Allgemeine Struktur
Erzeuger ...
Produkt Fabrikmethode() produkt =
EineOperation() Fabrikmethode();
...
KonkretesProdukt KonkreterErzeuger return new

FabrikMethode() KonkretesProdukt();
Bemerkung:
Oft sind Erzeuger und Produkt abstrakte Klassen und Fabrikmethode() ist
eine abstrakte Methode, d.h. in Klasse Erzeuger ist kein Rumpf für die
Fabrikmethode definiert.
Fabrikmethode: Bemerkungen
Anwendungskontext
Eine Klasse kennt die Klassen der zu erzeugenden Objekte nicht, muss
aber Objekte erzeugen und mit diesen weiterarbeiten
Eigenschaften
Fabrikmethoden werden in Frameworks oft verwendet
Erzeugerklasse und Fabrikmethode können ggf. auch konkret sein
(Default-Implementierung)
Verwendung von Fabrikmethoden führt zu Aufblähung der
Klassenhierarchie
Das hier gezeigte Default-Fabrikmethodenmuster wird durch komplexere
Klassenstrukturen ersetzt, wenn mehr Flexibilität benötigt wird
Verwandte Muster
Die Erzeuge-Methoden der Klasse Abstrakte Fabrik (beim Muster
„Abstrakte Fabrik“) sind Fabrikmethoden.
Inversion of Control
Werden Fabrikmethoden in Frameworks verwendet, so geht dies in

der Regel mit sogenannter „inversion of control“ einher, d.h.:
Nicht der Code des Programmierers ruft Methoden des Frameworks auf
(wie in einfachen Klassenbibliotheken).
Stattdessen wird der Code des Programmierers (nämlich hier die
Fabrikmethode) vom Framework aufgerufen.
Hollywood-Prinzip:
„Don‘t call us, we‘ll call you“ !
Wichtiges Unterscheidungsmerkmal zwischen Frameworks und

reinen Klassenbibliotheken; Fabrikmethoden sind nur ein Beispiel !
5.4.1.3 Singleton
Objektbasiertes Erzeugungsmuster
Ziel
Klasse mit genau einem Objekt (vgl. globale Variable)
Erzeugung weiterer Objekte wird abgefangen
Klasse bietet einfachen Zugriff auf Einzelobjekt
Beispielanwendung
Zur Konfiguration des Systems z.B. beim Abstrakte-Fabrik- oder
Erbauer- Muster
Singleton: Allgemeine Struktur
Singleton Anwendbarkeit
static GibInstanz() wenn genau ein Exemplar einer Klasse
erforderlich ist
SingletonOperation()
Exemplar soll „global“ zugreifbar sein
GibSingletonDaten()
static einzelExemplar
Eigenschaften
singletonDaten
Zugriffskontrolle auf Einzelexemplar
Ggf. Erzeugung des Einzelexemplars erst,
return einzelExemplar
wenn es tatsächlich benötigt wird
Strukturierter Ersatz für globale Variablen:
nur in Ausnahmefällen verwenden !
Bemerkung Strukturierterer Adressraum als bei globalen
Konstruktor von Singleton sollte Methoden:
Sichtbarkeit „private“ haben, z.B. singleton1.a(), singleton1.b()
damit mit new-Operator keine statt a(), b()
Instanzen erzeugt werden
können
5.4.2 Strukturmuster
Strukturmuster:
Klassen und Objekten zu größeren Strukturen komponieren
Klassenbasierte Strukturmuster:
Vererbung zur Komposition von Interfaces oder Klassen nutzen
Objektbasierte Strukturmuster:
Neue Funktionalität durch Objektkomposition realisieren
Größere Flexibilität durch die Möglichkeit, die Kompositon zur
Laufzeit zu verändern
5.4.2.1 Adapter
Adapter (auch: Wrapper genannt):
Klassen- oder objektbasiertes Strukturmuster
Ziel
Anpassung von Schnittstellen, z.B. Bibliotheksklassen

Hierbei ggf. auch Ergänzung fehlender Funktionalität
Adapter: Beispielanwendung
Zeicheneditor GrafischesObjekt TextAnzeige

Begrenzungsrahmen() GibAusmaße()
ErzeugeManipulator()
Linie
Begrenzungsrahmen()
Eine Subklasse von GrafischesObjekt soll Texte anzeigen.

Dabei soll existierende Bibliotheksklasse TextAnzeige mit ähnlicher
Funktionalität aber anderer Schnittstelle wiederverwendet werden
Adapter: Beispielanwendung (Forts.)
Zeicheneditor GrafischesObjekt TextAnzeige

Begrenzungsrahmen() GibAusmaße()
text
Linie Text
Begrenzungsrahmen() Begrenzungsrahmen()
ErzeugeManipulator() ErzeugeManipulator()
return new TextManipulator return text.GibAusmaße()
Die Adapterklasse Text passt die Klasse TextAnzeige an die Schnittstelle von
GrafischesObjekt an.
Zur Adaption kann weitergehende Transformation der Ergebnisse der adaptierten
Klasse nötig sein, als im gezeigten Beispiel.
Weiteres Anwendungsbeispiel: Anpassung von Datenbankschnittstellen.
Adapter: Allgemeine Struktur
1. Klassenadapter
Klient Ziel AdaptierteKlasse

Operation() Operation2()
Adapter
2. Objektadapter
Klient Ziel AdaptierteKlasse
adaptiertesObjekt
Adapter
Operation()
adaptiertesObjekt.Operation2()
Eigenschaften
1. Klassenadapter
- Adapter kann genau eine Klasse adaptieren, nicht aber ihre Unterklassen
- Adapter kann Teile der adaptierten Klasse modifizieren (überschreiben)
- Mehrfachvererbung oder zumindest mehrfaches Subtyping nötig
(wie in Java durch Interfaces ermöglicht ...)
- Nur ein Objekt zur Laufzeit (als Instanz der Adapter-Klasse)
2. Objektadapter
- Adapter kann mit anzupassender Klasse und allen ihren Unterklassen
zusammenarbeiten
- kein Überschreiben von Teilen der adaptierten Klasse
- Komposition & Delegation statt Vererbung
- zwei Objekte zur Laufzeit (Instanzen von Adapter und AdaptierterKlasse)
Adaptermuster: Bemerkungen
Objektadapter sind flexibler als Klassenadapter
Klassenadapter manchmal effizienter
Objektadapter-Muster folgt der OO-Entwurfsheuristik:

Objektkomposition ist oft besser als Vererbung
„favor object composition over inheritance“
5.4.2.2 Dekorierer (Decorator)
Objektbasiertes Strukturmuster
Ziel
Objekte dynamisch um Funktionalität erweitern

Flexiblere Alternative zur Unterklassenbildung
Dekorierer: Beispielanwendung
Eine graphische Textanzeige-Komponente soll mit Scrollbalken und
Umrahmungen versehen werden
Naive Lösung mit Subklassenbildung und Vererbung:
VisuelleKomponente
Zeichne()
TextAnzeige Fenster
Zeichne() Zeichne()
ScrollTextAnzeige RahmenTextAnzeige
Zeichne() Zeichne()
Probleme der naiven Lösung
Wie erhält man eine Textanzeige, die sowohl scrollen kann als auch
einen Rahmen hat? Weitere Subklasse?
Wie versieht man andere visuelle Kompenten mit der

Zusatzfunktionalität, z.B. Fenster oder Subklassen von TextAnzeige?
Subklassen dieser Klassen?
⇒ der naive Lösungsansatz führt zu unakzeptabler Explosion der

Anzahl der Klassen
Zusatzfunktionalität kann nicht dynamisch zu einem Textanzeigeobjekt

hinzugefügt werden, da das Objekt seine Klasse ändern müsste.
Dekorierer: Beispielanwendung
Ziel: grafisches Element auf Anforderung des Objektdiagramm:
Klienten umrahmen und/oder mit Scrollbalken Situation zur Laufzeit
versehen
Dekoriererobjekt speichert eine Referenz auf einRahmenDekorierer

das dekorierte Objekt und hat die gleiche komponente
Schnittstelle
Dekoriererobjekt leitet Anfragen weiter und fügt einScrollDekorierer

vorher oder nachher eigene komponente
Verhaltensbestandteile hinzu
Mehrfaches Dekorieren möglich eineTextAnzeige
Beachte: Wieder Komposition statt Vererbung !

(„favor object composition over inheritance“)
Dekorierer: Beispielanwendung (Fortsetzung)
VisuelleKomponente
Zeichne()
komponente
TextAnzeige Dekorierer
Zeichne() Zeichne() komponente.Zeichne()
ScrollDekorierer RahmenDekodierer
Zeichne() Zeichne()
ScrolleBis() ZeichneRahmen()
scrollPosition rahmenBreite
super.Zeichne();
ZeichneRahmen();
Dekorierer: Allgemeine Struktur
Komponente Anwendbarkeit
Operation()
komponente
Objekte dynamisch
KonkreteKomponente Dekorierer (d.h. (auch) zur Laufzeit) und
Operation() Operation()
transparent um Funktionalität erweitern
komponente.Operation()
DekoriererA DekodiererB Zusatzfunktionalität entfernbar

ZusatzFunktion()
zusatzZustand rahmenBreite Wenn Erweiterung durch
Unterklassenbildung nicht sinnvoll, z.B.
super.Operation(); wegen Explosion der Klassenanzahl
ZusatzFunktion();
Eigenschaften
Größere Flexibilität als statische Vererbung bzgl. Erweiterungsreihenfolge
(Hierarchisch hoch angesiedelte) Klassen werden nicht mit Funktionalität

überlastet, sondern für einzelne Aspekte wird bei Bedarf Funktionalität durch
weitere Klassen hinzugefügt
Dekorierer und dekoriertes Objekt sind nicht identisch

→ Vorsicht bei Vergleich !
Viele kleine Objekte

→ System evt. schwerer zu verstehen und zu debuggen !
5.4.2.3 Fassade (Facade)
Ziel:
Zusammenfassen der wichtigsten Schnittstellen eines Subsystems
zu einheitlicher Schnittstelle
Fassade bietet oft (auch) typische Kombinationen von
Subsystemoperationen als eigene Operation
→ vereinfachte Schnittstelle
Hierdurch einfachere Handhabung des Subsystems
Weniger Abhängigkeiten zwischen Subsystemen, insbesondere
wenn Zugriff ausschließlich über Fassade (→ Schichtenarchitektur)
Im Ausnahmefall und bei Bedarf kann auch Durchgriff auf
Einzelschnittstellen erlaubt bleiben; oft schlecht, da dann wieder
starke Abhängigkeit der Subsysteme
Fassade: Allgemeine Struktur
Klienten
Fassade
Sub−
System
Fassade: Beispielanwendung
Übersetzer-Subsystem enthält Klassen Scanner, Parser,
Codegenerator usw. mit eigenen Schnittstellen
Fassade kombiniert diese und bietet Operation uebersetze()
Uebersetzer
uebersetze()
Stream
Scanner Token
BytecodeStream Parser Symbol
CodeGenerator SyntaxbaumErbauer Knoten
RISC−CodeGenerator Anweisungsknoten
Anwendbarkeit
Wenn einfache Schnittstelle zu komplexem Subsystem

notwendig/erwünscht
Oft in Schichtenarchitekturen: Schnittstelle einer Schicht zu höheren
Schichten durch Fassade realisiert
Eigenschaften
Klienten kooperieren mit nur einem Fassadenobjekt statt mit

mehreren Subsystemobjekten
Änderungen innerhalb des Subsystems wirken sich nicht auf die
Klienten aus, wenn Zugriffe nur über die Fassade erfolgen
→ System flexibler, leichter wartbar, leichter portierbar
Adapter vs. Fassade
Beide Muster liefern veränderte Schnittstelle zu existierender

Funktionalität
Hauptunterschied: Zweck der Muster
Adapter: existierende Schnittstelle an erwartete Schnittstelle anpassen
Fassade: vereinfachte Schnittstelle zu Subsystem bereitstellen
5.4.2.4 Kompositum (Composite)
Ziel:
Darstellung rekursiver Objektstrukturen
Basiskomponenten und zusammengesetzte Komponenten

einheitlich behandelbar
Kompositum: Beispielanwendungen
1) Komponenten eines Dokuments enthalten weitere Komponenten,

z.B. Paragraph enthält Formel, Paragraph enthält Aufzählungsliste,
Aufzählungsliste enthält Aufzählungsliste etc.
2) Schachtelung von GUI-Elementen: z.B. Frame enthält Window,

Window enthält Textfelder und Buttons , ...
3) Kontrollstrukturen einer Programmiersprache beliebig schachtelbar

z.B. Schleife enthält Schleife → Syntaxbaum
Verarbeitung orientiert sich an Syntaxbaum (z.B. Typüberprüfung)
4) Ein arithmetischer Ausdruck besteht aus Teilausdrücken;

die Auswertung orientiert sich an der entsprechenden Baumstruktur
Beispiel:
Repräsentation arithmetischer Ausdrücke
Beispielausdruck: (x * 3) + (y – 2) Objektdiagramm
+ :Addition
* − :Multiplikation :Subtraktion
x 3 y 2 :Variable :Konstante :Variable :Konstante

name = "x" wert = 3 name = "y" wert = 2
wert = 42 wert = 999
Beispiel:
Repräsentation arithmetischer Ausdrücke
Beispielausdruck: (x * 3) + (y – 2) Klassendiagramm
ArithmetischerAusdruck
2
+
eval()
e1,e2
* −
Konstante Variable Addition
x 3 y 2 wert name
eval()
eval() wert
GibTeilausdruck1()
eval()
GibTeilausdruck2()
return e1.eval()+e2.eval();
Kompositum: Allgemeine Struktur
Klient Komponente
*
Operation()
FuegeHinzu(Komponente)
Entferne(Komponente)
GibKindObjekt(int)
oft konkretere Multiplizität bei
konkreten Kompositum−Klassen
z.B. 2 bei Additionsausdrücken
Blatt Kompositum
FuegeHinzu(Komponente)
Entferne(Komponente)
GibKindObjekt(int)
ruft für jedes Kindobjekt k

k.Operation();
auf und kombiniert die Resultate
Kompositum:Bemerkungen
Anwendbarkeit:
Repräsentation rekursiver Objektstrukturen
Eigenschaften:
Klientencode ist unabhängig von Art des vorliegenden Kompositums
(elementar oder zusammengesetzt)
Neue Kompositions- und Blattklassen sind leicht ergänzbar
Verwandte Muster und Bemerkungen:

Wird oft zusammen mit Dekorierermuster verwendet
Dann Dekorierer und Kompositum-Klassen Subklassen von Komponente
Ggf. Blätter als Fliegengewichte (siehe Gamma et. al.)
Ggf. Sharing
Iteratormuster und Besuchermuster zur Traversierung
5.4.2.5 Stellvertreter (Proxy, Surrogate)
Ziel:
Zugriff auf Objekt durch vorgelagerten Stellvertreter kontrollieren
Z.B. bei ...

umfangreichen Objekten auf Festplatte (z.B. Bilder, Audio, Video)
Objekten auf entfernten Rechnern
Stellvertreter: Beispielanwendung
Ein grafischer Editor soll Bilder erst bei Bedarf von der Festplatte laden
Bis dahin werden sie durch Stellvertreter repräsentiert
Der Stellvertreter veranlasst das rechtzeitige Laden des Bildobjektes
Objektdiagramm:
(Situation zur Laufzeit)
einTextDokument
bild
einBildProxy einBild
dateiname daten
im Hauptspeicher auf Festplatte
Stellvertreter: Beispielanwendung (Fortsetzung)
Grafik
Klassendiagramm: DokumentenEditor
Zeichne()
GibAusmasse()
Speichere()
Lade()
Bild BildProxy
bildImp dateiname
ausmasse ausmasse
Zeichne() bild Zeichne()
GibAusmasse() GibAusmasse()
Speichere() Speichere()
Lade() Lade()
if (bild == Null) if (bild == Null)

return ausmasse; bild = LadeBild(dateiname);
else return bild.GibAusmasse(); bild.Zeichne();
Beachte: GibAusmasse beantwortet Anfrage ggf. ohne das Bild zu laden;

könnte z.B. für Layout-Zwecke (Seitenumbruch) reichen
Stellvertreter: Allgemeine Struktur
Subjekt
Klient
Operation()
...
Original Proxy
original
... ...
...
original.Operation(); ...
Anwendbarkeit
Remote-Proxy:
zur Kommunikation mit Server-Objekt, z.B. bei CORBA
Proxy-Objekt „lebt“ auf Seite des Clients und leitet Aufrufe an das Objekt
auf dem Server weiter
Virtuelles Proxy (vgl. Bsp.):

erzeugt teure Objekte erst bei Bedarf
verzögert Kosten für Erstellung und Initialisierung
Schutz-Proxy:
kontrolliert den Zugriff auf das Originalobjekt, z.B. Zugriffsrechte
Smart Reference
ähnelt einer Referenz, führt jedoch Zusatzsoperation aus
z.B. reference-counting, Objekt bei Bedarf aus DB laden, bei Zugriff in
DB sperren, Copy-on-Write (verzögertes Kopieren)
Stellvertreter vs. Dekorierer
Stellvertreter und Dekorierer haben ähnliche Struktur und Eigenschaften
Hauptunterschied: Zweck der Muster
Dekorierer: Verhalten zu Objekten hinzufügen
Stellvertreter: Zugriff auf Objekte kontrollieren
Fortsetzung folgt ...

SE1011 Kap5 2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SE1011 Kap5 2

Originaltitel:

Hochgeladen von

Copyright:

Verfügbare Formate

Software Engineering

Unter Verwendung von Folien von Herbert Kuchen

Einsatz & Wartung

5.3 Prinzipien des Architekturenwurfs

Bewährte Lösungsansätze für oft wiederkehrende Entwurfsprobleme

Auf Flexibilität, Wartungsfreundlichkeit und Erweiterbarkeit zielende

Wiederverwendung (engl. reuse) auf Entwurfsebene

Namen von Entwurfsmustern bieten gemeinsames Vokabular zur

Verständnis der in Frameworks verwendeten Entwurfsmuster:

Klassisches Buch der „GoF“ („Gang of Four“):

Neueres Buch, ungewöhnlich gemacht aber fundiert:

Dasselbe Problem z.T. durch verschiedene, alternative Muster lösbar

Die kursiv geschriebenen Muster werden im Folgenden besprochen.

Objektbasierte Erzeugungsmuster ...

Grundidee: Anwendung (Klient) arbeit mit abstrakten Klassen für

Bei Wechsel des Standards müssen alle new-Kommandos

Unterliegende Heuristik: „Encapsulate what varies“

Statt z.B. Fenster f = new PMFenster;

Unabhängigkeit von konkreter Art der „Produkte“ erwünscht

Garantierte Konsistenz der erzeugten Objekte

Unterstützung einer Produktfamilie mit anderer Schnittstelle schwierig

Bei sehr vielen unterstützten Produktfamilien wird das Muster geeignet

Unterklassen entscheiden, von welcher Klasse das erzeugte Objekt

Dokument dokumente Anwendung

MeinDokument MeineAnwendung return

Klassen Anwendung und Dokument sind abstrakt.

KonkretesProdukt KonkreterErzeuger return new

Werden Fabrikmethoden in Frameworks verwendet, so geht dies in

Wichtiges Unterscheidungsmerkmal zwischen Frameworks und

Adapter (auch: Wrapper genannt):

Klassen- oder objektbasiertes Strukturmuster

Anpassung von Schnittstellen, z.B. Bibliotheksklassen

Zeicheneditor GrafischesObjekt TextAnzeige

Eine Subklasse von GrafischesObjekt soll Texte anzeigen.

Zeicheneditor GrafischesObjekt TextAnzeige

return new TextManipulator return text.GibAusmaße()

Klient Ziel AdaptierteKlasse

Objektadapter sind flexibler als Klassenadapter

Klassenadapter manchmal effizienter

Objektadapter-Muster folgt der OO-Entwurfsheuristik:

Objekte dynamisch um Funktionalität erweitern

Naive Lösung mit Subklassenbildung und Vererbung:

Wie versieht man andere visuelle Kompenten mit der

⇒ der naive Lösungsansatz führt zu unakzeptabler Explosion der

Zusatzfunktionalität kann nicht dynamisch zu einem Textanzeigeobjekt

Dekoriererobjekt speichert eine Referenz auf einRahmenDekorierer

Dekoriererobjekt leitet Anfragen weiter und fügt einScrollDekorierer

Mehrfaches Dekorieren möglich eineTextAnzeige

Beachte: Wieder Komposition statt Vererbung !

DekoriererA DekodiererB Zusatzfunktionalität entfernbar

Größere Flexibilität als statische Vererbung bzgl. Erweiterungsreihenfolge

(Hierarchisch hoch angesiedelte) Klassen werden nicht mit Funktionalität

Dekorierer und dekoriertes Objekt sind nicht identisch

Viele kleine Objekte

BytecodeStream Parser Symbol

CodeGenerator SyntaxbaumErbauer Knoten

Wenn einfache Schnittstelle zu komplexem Subsystem

Klienten kooperieren mit nur einem Fassadenobjekt statt mit

Beide Muster liefern veränderte Schnittstelle zu existierender

Hauptunterschied: Zweck der Muster

Adapter: existierende Schnittstelle an erwartete Schnittstelle anpassen

Fassade: vereinfachte Schnittstelle zu Subsystem bereitstellen