Entwurfsmuster - Design Pattern Entwurfsmuster - Design Pattern ...

Entwurfsmuster - Design Pattern 

Entwurfsmuster - Design Pattern 

Erste neuere Erfahrungen Ende der 80er Jahre 

Pattern für User Interfaces in Smalltalk von 

Cunningham und Beck 

C++ Idioms von Coplien 

Erich Gamma, Richard Helm, Ralph Johnson, 

John Vlissides (GoF) erarbeiteten Katalog von 

Pattern (1995) Standardwerk 

Ein Entwurfsmuster gibt eine bewährte 

generische Lösung für ein immer 

wiederkehrendes Entwurfsproblem, das 

in bestimmten Situationen auftritt. 

Universität Rostock, FB Informatik, Lehrstuhl Softwaretechnik Seite 1 


Pattern nach Gamma et. al. 

Mustername und Klassifizierung 

Zweck (kurze Darstellung des Musters) 

Auch bekannt als 

Motivation (exemplarisches Szenario) 

Anwendbarkeit (mögliche Verwendungen) 

Struktur (graphische Darstellung der strukturellen Eigenschaften) 

Akteure (beteiligte Klassen und Objekte) 

Konsequenzen (Vor- und Nachteile, Ergebnisse) 

Beispielcode 

Bekannte Verwendung 

Verwandte Muster (Unterschiede, Zusammenarbeit) 



Erzeugungsmuster Strukturmuster Verhaltensmuster 

Klasse Factory Method Adapter Interpreter 

Template Method 

Objekt Abstract Factory Adapter Chain of Responsibility 

Builder Bridge Commend 

Prototype Composite Iterator 

Singleton Decorator Mediator 

Facade 

Mementon 

Flywight 

Observer 

Proxy 

State 

Strategy 

Visitor 



Klassenmuster: 

– Beziehungen zwischen Klassen (Vererbungsstrukturen) 

– zur Übersetzungszeit festgelegt (statisch) 

Objektmuster: 

– Beziehungen zwischen Objekten 

– zur Laufzeit veränderbar (dynamisch) 

– nutzen auch in gewissem Grad Vererbung 


Erzeugungsmuster: 

– abstrahieren den Objekterzeugungsprozess 

– Klassenmuster nutzen Vererbung, um Teile der 

Objekterzeugung in Unterklassen zu verlagern 

– Objektmuster delegieren Objekterzeugung an ein 

anderes Objekt 



1


Strukturmuster: 

– setzen Klassen und Objekte zu größeren Strukturen 

zusammen 

– Klassenmuster nutzen Vererbung, um Schnittstellen und 

Implementierungen zusammenzuführen 

(einfaches Beispiel: Mehrfachvererbung) 

– hilfreich, um unabhängig voneinander entwickelte 

Bibliotheken zusammen arbeiten zu lassen 

– Objektmuster ermöglichen, Objekte zusammenzuführen 

– flexibler als Klassenmuster, da sich bei Objektstrukturen 

die Struktur zur Laufzeit ändern kann 


Verhaltensmuster: 

– beschreiben Interaktionen zwischen Objekten und 

Klassen und komplexe Kontrollflüsse 

– Klassenmuster verwenden Vererbung, um das Verhalten 

unter den Klassen zu verteilen 

– Objektmuster nutzen Aggregationen anstelle von 

Vererbung und beschreiben, wie Gruppen von Objekten 

zusammenarbeiten 



Klassenbibliotheken 

Menge wiederverwendbarer Klassen, die eine allgemeine 

Funktionalität zur Verfügung stellen 

unterschiedliche Topologien möglich: 

– Baum-Topologie (eine gemeinsame Wurzelklasse) 

– Wald-Topologie (mehrere Baumhierarchien) 

– Baustein-Topologie (unabhängige generische Klassen) 

Bibliotheken für unterschiedliche Anwendungsgebiete: 

z.B. Basisbibliotheken, GUI-Klassenbibliotheken, Bibliotheken zum 

Zugriff auf Datenbanken 

„einfache“ Klassenbibliotheken: 

– erzwingen keine bestimmte Anwendungsstruktur 

– Zweck: Code-Wiederverwendung 


Frameworks 

Menge zusammenarbeitender Klassen (konkrete und 

abstrakte), die einen wiederverwendbaren Entwurf 

implementieren 

Nutzung des Frameworks bedeutet, Unterklassen von den 

abstrakten Framework-Klassen abzuleiten 

Framework bestimmt Architektur der Anwendung (definiert 

Struktur der Klassen und Objekte, ihre Verantwortlichkeiten 

und ihr Zusammenspiel) und legt alle Entwurfsparameter 

fest 

immer spezifisch auf einen Anwendungsbereich ausgelegt 

Zweck: Entwurfs-Wiederverwendung 


Design Pattern vs. Frameworks 

Pattern Bridge 

Pattern sind abstrakter als Frameworks 

– werden nur beispielhaft durch Programmcode repräsentiert 

– sind immer mit einer neuen Implementierung verbunden 

Pattern sind kleiner als Frameworks 

– ein typisches Framework enthält mehrere Pattern 

Pattern sind weniger spezialisiert als Frameworks 

– nicht auf einen bestimmten Anwendungsbereich beschränkt 

Zweck: 

Entkopplung einer Abstraktion von ihrer 

Implementation 



2



Klient 

Abstraktion 

Operation() 

SpezialisierteAbstraktion 

imp 

Implementierer 

OperationsImp() 

imp.OperationsImp() 

KonkreterImplementiererA KonkreterImplementiererB 



Akteure: 

Abstraktion 

• verwaltet eine Referenz auf einen Implementierer und definiert 

Schnittstelle 

SpezialisierteAbstraktion 

• erweitert die durch Abstraktion definierte Schnittstelle 

Implementierer 

• definiert Schnittstelle für Implementierungsklassen 

KonkreterImplementierer 

• definiert konkrete Implementation 




Anwendungsbedingungen: 

dauerhafte Verbindung zwischen Abstraktion und 

ihrer Implementierung soll vermieden werden 

sowohl Abstraktion als auch Implementierungen 

sollen durch Unterklassenbildung erweiterbar sein 

Änderungen in der Implementierung der Abstraktion 

sollen keine Auswirkungen auf Klienten haben 

Implementierung der Abstraktion soll vollständig vor 

Klienten versteckt werden 

Implementierung soll von mehreren Objekten 

gemeinsam genutzt werden 


Vor- und Nachteile: 

+ Entkopplung von Abstraktion und Implementation 

+ Die Implementation kann dynamisch während der 

Laufzeit verändert werden 

+ Verbesserte Erweiterbarkeit 

+ Implementation kann in Abhängigkeit von einem 

Parameter in der Erzeugungsroutine (Konstruktor) 

gewählt werden 



Übungsaufgabe 

Implementieren Sie in Eiffel das Entwurfsmuster Bridge, um 

die Abstraktion PatternStack von ihrer Implementation zu 

trennen. 

Die Schnittstelle der Abstraktion PatternStack enthält die 

Operationen push, top und pop. 

Als Implementationen sind die vorcompilierten Eiffel-Klassen 

TWO_WAY_LIST und SORTED_TWO_WAY_LIST zu nutzen. 

Testen Sie die Funktionsweise Ihres Brückenmusters 

beispielhaft in einer Testklasse. 

Pattern Adapter 

Zweck: 

Anpassen der Schnittstellen inkompatibler 

Klassen 



3



Klassenadapter (verwendet Mehrfachvererbung) 

Objektadapter (verwendet Objektkomposition) 

Klient 

Ziel 

AdaptierteKlasse 

Klient 

Ziel 


Operation() 

SpezifischeOperation() 

Operation() 


adaptiertesObjekt 

(implementierung) 

Adapter 

Adapter 

Operation() 


Operation() 

adaptiertesObjekt.SpezifischeOperation() 





Akteure: 

Ziel 

• definiert anwendungsspezifische Schnittstelle 

Klient 

• arbeitet mit Objekten, die der Zielschnittstelle entsprechen 


• definiert existierende und anzupassende Schnittstelle 

Adapter 

• passt Schnittstelle der anzupassenden Klasse an die 

Zielschnittstelle an 


Wenn eine existierende Klasse verwendet werden 

soll, deren Schnittstelle nicht der benötigten 

Schnittstelle entspricht 

Wenn eine wiederverwendbare Klasse erstellt werden 

soll, die mit unabhängigen oder nicht vorhersehbaren 

Klassen zusammenarbeiten muss 





Klassenadapter 


+ passt die zu adaptierende Klasse an genau eine 

konkrete Zielklasse an 

- funktioniert nicht, wenn eine Klasse und alle ihre 

Unterklassen angepasst werden sollen 

+ Adapter kann Verhalten der adaptierten Klasse 

einfach überschreiben 

Objektadapter 


+ Adapter kann mit mehreren anzupassenden Klassen 

arbeiten (der Klasse selbst und allen ihren 

Unterklassen) 

- Überschreiben des Verhaltens der anzupassenden 

Klasse schwieriger (Unterklassenbildung nötig) 



4

Pattern Proxy 


Zweck: 

Kontrolle des Zugriffes auf ein Objekt mit Hilfe 

eines vorgelagerten Stellvertreterobjektes 

Klient 

Subjekt 

Operation() 

EchtesSubjekt 

Proxy 

Operation() 

echtes 

Subjekt 

Operation() 

echtesSubjekt.Operation() 





Akteure: 

Proxy 

– verwaltet Referenz auf EchtesSubjekt 

– bietet Schnittstelle, die mit der von Subjekt identisch ist 

– kontrolliert Zugriff auf EchtesSubjekt 

Subjekt 

– definiert gemeinsame Schnittstelle von EchtesSubjekt und 

Proxy 

EchtesSubjekt 

– definiert das eigentliche Objekt, das durch Proxy 

repräsentiert wird 

Arten des Proxy-Musters: 

Remote-Proxy 

– stellt einen lokalen Stellvertreter für ein Objekt in einem 

anderen Adressraum dar 

Virtuelles Proxy 

– erzeugt „teure“ Objekte auf Verlangen 

– Copy-On-Write (kopiert ein aufwändiges Objekt erst dann, 

wenn es wirklich verändert wurde) 

Schutzproxy 

– kontrolliert Zugriff auf das Originalobjekt 

– nützlich, wenn Objekte über unterschiedliche Zugriffsrechte 

verfügen sollen 



Pattern Visitor 

Besucher 

BesucheKonkretesElementA(KonkretesElementA) 

BesucheKonkretesElementB(KonkretesElementB) 

Zweck: 

Kapselung einer auf den Elementen einer 

Objektstruktur auszuführenden Operation 

als ein Objekt. 

Definition einer neuen Operation ohne 

Veränderung der Klassen der von ihr 

bearbeiteten Elemente. 

KonkreterBesucher1 



Klient 

ObjektStruktur 

KonkretesElementA 

NimmEntgegen(Besucher b) 

OperationA() 

KonkreterBesucher2 



Element 

NimmEntgegen(Besucher) 

KonkretesElementB 

NimmEntgegen(Besucher b) 

OperationB() 

b.BesucheKonkretesElementA(Current) 



5


Akteure: 

Besucher 

– deklariert Besuche-Operation für jede KonkretesElement- 

Klasse 

– Operationsname und Signatur benennen Klasse, welche 

Besuche-Operation des Besuchers aufruft 

– dies ermöglicht Besucher, konkrete Klasse des besuchten 

Elementes zu bestimmen 

KonkreterBesucher 

– implementiert jede von der Besucher-Klasse deklarierte 

Operation 


Akteure: 

Element 

– definiert NimmEntgegen-Operation, die einen Besucher als 

Argument empfangen kann 

KonkretesElement 

– implementiert NimmEntgegen-Operation 

Objektstruktur (Klient) 

– kann seine Elemente aufzählen 






auf Objekten einer Objektstruktur müssen viele 

unterschiedliche, nicht miteinander verwandte 

Operationen ausgeführt werden 

Klassen, die die Objektstruktur definieren, ändern sich 

nicht 

es werden aber häufig neue Operationen für die 

Struktur definiert 


+ einfaches Hinzufügen neuer Operationen durch 

Definieren eines neuen Besuchers 

+ Besucher vereinigt verwandte Operationen und trennt 

sie von Operationen, die nichts mit der Aufgabe des 

Besuchers zu tun haben 

+ Klassenhierarchieübergreifende Besucher möglich 

- Hinzufügen neuer KonkretesElement-Klassen 

schwierig 




Implementieren Sie in Eiffel das Entwurfsmuster Visitor, 

indem Sie über der Objektstruktur eines binären Baumes 

(Klasse BINARY_TREE), der Integer-Werte hält, drei 

Durchläufe mit je einem Besucher realisieren. 

Der erste Besucher gibt jeweils den Wert aus, der zweite 

Besucher verdoppelt ihn und der dritte Besucher 

summiert die Werte auf. 

Testen Sie die Funktionsweise Ihres Besuchermusters 


Pattern Observer 

Zweck: 

Definiert eine 1:n-Beziehung zwischen 

Objekten, so dass bei Änderung des 

Zustandes eines Objektes alle abhängigen 

Objekte benachrichtigt und automatisch 

aktualisiert werden. 



6



Akteure: 

Subjekt 

MeldeAn(Beobachter) 

MeldeAb(Beobachter) 

Benachrichtige() 

KonkretesSubjekt 

subjektZustand 

GibZustand() 

SetzeZustand() 

beobachter 

Für alle b in beobachter: 

b.Aktualisiere() 

Result:=subjektZustand 

beobachterZustand := 

subjekt.GibZustand() 

subjekt 

Beobachter 

Aktualisiere() 

KonkreterBeobachter 

beobachterZustand 

Aktualisiere() 

 

 

 

 

Subjekt 

– kennt Liste von Beobachtern (keine konkreten Beobachter) 

– bietet Schnittstelle zum An- und Abmelden von Beobachtern 

KonkretesSubjekt 

– speichert den für KonkreteBeobachter relevanten Zustand 

– benachrichtigt Beobachter, wenn sich sein Zustand ändert 

Beobachter 

– definiert Aktualisierungsschnittstelle für Objekte, die über 

Änderungen eines Subjektes benachrichtigt werden müssen 

KonkreterBeobachter 

– verwaltet Referenz auf ein KonkretesSubjekt 

– speichert den zu dem des Subjektes konsistenten Zustand 

– implementiert Aktualisierungsschnittstelle von Beobachter 






Wenn eine Abstraktion zwei Aspekte besitzt, von 

denen der eine vom anderen abhängt. 

Wenn die Änderung eines Objektes die Änderung 

anderer Objekte verlangt. 

Wenn ein Objekt andere Objekte benachrichtigen soll, 

ohne zu wissen, wer diese anderen Objekte sind. 


+ Subjekte und Beobachter können unabhängig 

voneinander variiert werden 

+ abstrakte und minimale Kopplung zwischen 

Subjekt und Beobachter 

+ Unterstützung der Broadcast-Kommunikation 

- unerwartete Aktualisierungen hohen Aufwandes 

möglich 




Implementieren Sie in Eiffel das Entwurfsmuster Observer 

für folgendes Szenario: 

Eine Klasse (Subjekt) hält die Datumsangaben Jahr, Monat, 

Tag und kann diese auch ändern. 

Zwei Beobachterklassen beobachten das Subjekt und 

stellen Änderungen des Subjektzustandes in 

unterschiedlicher Form dar 

(TT.MM.YYYY und MM/TT/YYYY). 

Testen Sie die Funktionsweise Ihres Beobachtermusters 


Pattern Strategy 

Zweck: 

Definiert eine Familie von Algorithmen, 

kapselt jeden einzelnen und macht ihn 

austauschbar. 

Algorithmen können unabhängig von den 

Klienten verändert werden. 



7



Klient 

Kontext 

strategie 

KontextSchnittstelle() 

KonkreteStrategieA 

AlgorithmusSchnittstelle() 

Strategie 


KonkreteStrategieB 


KonkreteStrategieC 


Akteure: 

Strategie 

– deklariert Schnittstelle, die von allen unterstützten 

Algorithmen angeboten wird 

KonkreteStrategie 

– implementiert Algorithmus unter Verwendung der 

Strategieschnittstelle 

Kontext 

– wird mit einem KonkreteStrategie-Objekt konfiguriert 

– verwaltet Referenz auf das Strategieobjekt 

– kann Schnittstelle definieren, die Strategieobjekten den 

Zugriff auf die Daten des Kontextes ermöglicht 






Wenn sich viele verwandte Klassen nur in ihrem 

Verhalten unterscheiden. 

Wenn unterschiedliche Varianten eines Algorithmus 

benötigt werden. 

Wenn eine Klasse unterschiedliche Verhaltensweisen 

definiert und diese als Mehrfachverzweigungen in 

ihren Operationen erscheinen. 

Wenn ein Algorithmus Daten verwendet, die Klienten 

nicht bekannt sein sollen. 


+ Familien von verwandten Algorithmen festgelegt 

+ Alternative zur Unterklassenbildung 

+ Strategien entfernen Mehrfachverzweigungen 

+ Auswahlmöglichkeit für Implementierungen 

- Klienten müssen unterschiedliche Strategien kennen 

- Kommunikationsaufwand zwischen Strategie und 

Kontext 

- erhöhte Anzahl von Objekten 



Pattern Mediator 


Zweck: 

Steuerung der Kommunikation zwischen 

Objekten. 

Objekte kommunizieren nicht direkt, sondern 

immer über den Vermittler. 

Die Einbeziehung neuer Objekte ist auf die 

Veränderung des Vermittlers beschränkt. 

Vermittler 

KonkreterVermittler 

vermittler 

KonkreterKollege1 

Kollege 

KonkreterKollege2 



8



Akteure: 

Vermittler 

– definiert Schnittstelle für Interaktion mit den Kollegen- 

Objekten 

KonkreterVermittler 

– implementiert das Gesamtverhalten durch Koordination der 

Kollegen-Objekte 

– kennt und verwaltet Kollegen-Objekte 

Kollegen-Klassen 

– jede Kollegen-Klasse kennt ihre Vermittler-Klasse 

– jedes Kollegen-Objekt kommuniziert mit dem Vermittler, 

wenn es normalerweise direkt mit einem anderen Objekt 

Kontakt aufnehmen würde 


Wenn eine Menge von Objekten in komplexer Weise 

zusammenarbeitet. 

Wenn die Wiederverwendung eines Objektes 

schwierig ist, weil es sich auf viele andere Objekte 

bezieht. 





+ Unterklassenbildung wird eingeschränkt 

(Änderung des Verhaltens erfordert lediglich 

Ableitung der Vermittler-Klasse) 

+ fördert lose Kopplung zwischen den Kollegen- 

Objekten 

+ vereinfacht das Protokoll des Objektes 

+ zentralisiert die Steuerung (Komplexität des 

Vermittlers beachten !) 


Implementieren Sie in Eiffel das Entwurfsmuster Mediator 

für folgendes Szenario: 

Die Kollegen-Klassen verfügen über die Methoden 

Meldung_absetzen(int_zahl) und Meldung_empfangen(int_zahl), die 

zur Kommunikation untereinander dienen. Die 

Kommunikation erfolgt nicht direkt, sondern über einen 

Vermittler. 

Der Vermittler verwaltet die angemeldeten Kollegen und 

implementiert folgende Operationen: Kollege_anmelden, 

Kollege_abmelden und Alle_informieren. 

Testen Sie die Funktionsweise Ihres Vermittlermusters 




Erzeugungsmuster 

Beispiel Mazegame 1 (original) 

Klassenmuster 

Objektmuster 

FactoryMethod 

(Verschieben der Objekterzeugung auf 

die Unterklasse) 

AbstractFactory 

(Erzeugung von „Gruppen“ von Objekten) 

Builder (Erzeugung komplexer Objekte) 

Prototype (Erzeugung eines Objektes als 

Kopie eines Prototype-Objektes) 

Singleton (Erzeugung von nur einer 

Instanz) 

class MAZEGAME 

feature 

CreateMaze: MAZE is 

local r1,r2: ROOM; d: DOOR; w: WALL; 

do 

!!Result; 

!!r1.make(1); !!r2.make(2); !!d.make(r1,r2); 

Result.AddRoom(r1); Result.AddRoom(r2); 

!!w; r1.SetSide("North",w); 

r1.SetSide("East",d); 

!!w; r1.SetSide("South",w); 

!!w; r1.SetSide("West",w); ............ 

end 

end 



9

Beispiel Mazegame 2 (original) 

Pattern Abstract Factory 

class CLIENT 

creation 

make 

feature 

make is 

local game: MAZEGAME; 

aMaze: MAZE; 

do 

!!game; 

aMaze := game.CreateMaze 

end 

end 

Zweck: 

stellt eine Schnittstelle bereit, um Familien von 

Objekten zur Laufzeit zu erzeugen, ohne deren 

konkrete Klassen festzulegen 





KonkreteFabrik1 

ErzeugeProduktA() 

ErzeugeProduktB() 

AbstrakteFabrik 



KonkreteFabrik2 



Klient 

AbstraktesProduktA 

ProduktA2 ProduktA1 

AbstraktesProduktB 

ProduktB2 ProduktB1 


Wenn ein System unabhängig von der Art der 

Erzeugung seiner Produkte (Objekte) arbeiten soll. 

Wenn ein System mit einer von mehreren 

Produktfamilien konfiguriert werden soll. 

Wenn eine Gruppe von Produkten erzeugt werden 

soll, um gemeinsam genutzt zu werden. 

Wenn in einer Klassenbibliothek nur die 

Schnittstellen von Produkten bereitgestellt werden 

sollen und nicht die Implementationen. 





+ Isolierung konkreter Klassen 

+ Austausch von Produktfamilien ist einfach 

+ Produktnutzung nur eines Produktes aus einer 

Gruppe wird gesichert 

- neue Produktarten sind schwer einfügbar 

Verwendung: 

Benutzungsschnittstellen mit unterschiedlichem 

„Look and Feel“ 

Mazegame mit Abstract Factory (1) 

deferred class MAZE_FACTORY 

feature 

end 

MakeMaze:MAZE is deferred end; 

MakeRoom (no:INTEGER) : ROOM is deferred end; 

MakeDoor (r1,r2:ROOM) : DOOR is deferred end; 

MakeWall: WALL is deferred end; 



10


class ENCHANTED_MAZE_FACTORY 

inherit MAZE_FACTORY 

feature 

MakeRoom (no:INTEGER) : ENCHANTED_ROOM is 

do !!Result.make(no); end 

MakeWall: WALL is 

do !!Result; end 

MakeDoor (r1,r2:ROOM) :LOCKED_DOOR is 

do !!Result.make(r1,r2); end 

MakeMaze: MAZE is 

do !!Result; end 

end 


class GAME_WITH_ABSTRACT_FACTORY 

feature 

CreateMaze (fac:MAZE_FACTORY): MAZE is 

local r1,r2: ROOM; d: DOOR; 

do r1 := fac.MakeRoom (1); r2 := fac.MakeRoom (2); 

d :=fac.MakeDoor (r1,r2); 

Result := fac.MakeMaze; Result.AddRoom (r1); 

Result.AddRoom (r2); 

r1.SetSide ("North",fac.MakeWall); 

r1.SetSide ("East",d); 

r1.SetSide ("South",fac.MakeWall); 

r1.SetSide ("West",fac.MakeWall); .... 

end 

end 




Pattern Builder 

class CLIENT 

creation 

make 

feature 

make is 

local game: GAME_WITH_ABSTRACT_FACTORY 

fac: ENCHANTED_MAZE_FACTORY; 

aMaze: MAZE; 

do 

!!game; !!fac; 

aMaze := game.CreateMaze (fac); 

end 

end 

Zweck: 

Trennung der Konstruktion komplexer Objekte von ihrer 

Repräsentation. 

Dadurch kann der gleiche Prozess verschiedene 

Repräsentationen erzeugen. 





Klient 

Direktor 

Erbauer 


Konstruiere() 

für alle Objekte in der Struktur: 

erbauer.BaueTeil() 

BaueTeil() 

KonkreterErbauer 

BaueTeil() 

GibErgebnis() 

Produkt 

Wenn die Erzeugung eines komplexen Objektes 

unabhängig von der Erzeugung seiner Bestandteile 

und ihrer Komposition sein soll. 

Wenn verschiedene Repräsentationen des 

komplexen Objektes erlaubt sein sollen. 



11


Akteure: 

Erbauer 

– spezifiziert eine abstrakte Schnittstelle zur Erzeugung 

von Teilen eines Produktes 

konkreterErbauer 

– liefert Implementation zur Schnittstelle 

– definiert und verwaltet die von ihm erzeugte Repräsentation 

– bietet Schnittstelle zum Zurückgeben des Produktes 

Direktor 

– konstruiert ein Objekt entsprechend Erbauerschnittstelle 

Produkt 

– repräsentiert das gerade konstruierte komplexe Objekt 

Vorteile: 

+ isoliert Code für Konstruktion und Repräsentation 

+ Änderung der Repräsentation durch neue konkrete 

Erbauer-Klasse 

Verwendung: 


Konvertierungs-Applikationen 



Mazegame mit Builder (1) 

deferred class MAZE_BUILDER 

feature 

maze: MAZE is deferred end 

BuildMaze is do end 

BuildRoom (no:INTEGER) is do end 

BuildDoor (r1,r2:INTEGER) is do end 

end 



class STANDARD_MAZE_BUILDER 

inherit MAZE_BUILDER 

redefine BuildMaze, BuildRoom, BuildDooor 

end 

feature 

maze: MAZE 

BuildMaze is do !!maze; end 

BuildRoom (no:INTEGER) is 

local r: ROOM; w: WALL; 

do 

!!r.make (no); maze.AddRoom (r); 

!!w; r.SetSide ("North",w); 

!!w; r.SetSide ("East",w); 

!!w; r.SetSide ("South",w); 

!!w; r.SetSide ("West",w); 

end 



BuildDoor (r1, r2:INTEGER) is 


do 

r1 := maze.room (rno1); r2 := maze.room (rno2); 

!!d.make(r1,r2); 

r1.SetSide („East“, d); 

r2.SetSide („West“, d); 

end 

end 


class MAZEGAME 

feature 

CreateMaze (builder:MAZE_BUILDER):MAZE is 

do 

builder.BuildMaze; 

builder.BuildRoom(1); 

builder.BuildRoom(2); 

builder.BuildDoor(1,2); 

Result := builder.maze; 

end 

end 



12


class CLIENT 

creation make 

feature 

make is 

local 

game: MAZEGAME; 

aMaze: MAZE; 

aBuilder: MAZE_BUILDER; 

do !!game; 

!STANDARD_MAZE_BUILDER!aBuilder; 

aMaze := game.CreateMaze (aBuilder); 

end 

end 

Pattern Prototype 

Zweck: 

Prototypische Objekte werden zur Erzeugung 

weiterer Objekte genutzt. 

Neue Objekte werden durch Kopieren des 

Prototypen erzeugt. 





Klient 

Operation() 

p := Clone(prototyp) 

Prototyp 

Clone() 

KonkreterPrototyp1 

Clone() 

KonkreterPrototyp2 

Clone() 


Wenn die zu instanzierenden Klassen erst zur 

Laufzeit spezifiziert werden. 

Wenn vermieden werden soll, dass eine Hierarchie 

von Fabriken parallel zu einer Hierarchie von 

Produkten verläuft. 

Wenn die Objekte einer Klasse nur wenige 

unterschiedliche Zustandskombinationen haben 

können. 





+ neue Produktklassen können zur Laufzeit 

eingebunden werden 

+ neue Objekte können durch Variation der Struktur 

spezifiziert werden 

+ verringerte Unterklassenbildung (keine Erzeuger- 

Klassenhierarchie) 

- jede Prototype-Unterklasse muss Clone-Operation 

implementieren (flache vs. tiefe Kopie) 

- gewünschte Initialisierungen des geklonten Objektes 

müssen separat erfolgen 


class PROTOTYPE_FACTORY 

feature 

proto_instance: Prototype; 

... 

new_instance: Prototype is 

do 

Result := deep_clone (proto_instance); 

end; 

... 

end 



13

Pattern Prototype (1) 

class MAZE_PROTOTYPE_FACTORY 

inherit MAZE_FACTORY 

creation make 

feature 

make (m: MAZE; w: WALL; r: ROOM; d:DOOR) is 

do prototype_maze := m; prototype_wall := w; 

prototype_room :=r; prototype_door := d; 

end 


do Result := clone (prototype_maze) end 

..... 

feature {NONE} 

prototype_maze: MAZE; prototype_wall: WALL; 

prototype_room: ROOM; prototype_door: DOOR 

end 


Pattern Prototype (2) 

class GAME_WITH_PROTOTYPE 

inherit GAME_WITH_ABSTRACT_FACTORY 

creation make 

feature 

make is 

local ...... 

do !!maze; !!wall; !!room.make (0); !!door.make (Void, Void); 

!!maze_prototype_factory.make (maze, wall, room, door); 

aMaze := CreateMaze (maze_prototype_factory); 

!ENCHANTED_ROOM!room.make (0); 

!LOCKED_DOOR!door.make (Void,Void); 

!!maze_prototype_factory.make (maze, wall, room, door); 

aMaze := CreateMaze (maze_prototype_factory); 

end 

end 


Pattern Factory Method 


Zweck: 

Erzeuger 

Definiert eine Schnittstelle zur Erzeugung eines 

Objektes, wobei die Unterklassen entscheiden, von 

welcher Klasse das zu erzeugende Objekt ist 

(virtueller Konstruktor). 

Produkt 

KonkretesProdukt 

erzeugt 

Fabrikmethode() 

EineOperation() 

KonkreterErzeuger 

produkt = Fabrikmethode() 

Fabrikmethode() 

Result := !!konkretesProdukt 





Wenn eine Klasse die von ihr zu erzeugenden 

Objekte, nicht im voraus kennen kann. 

Wenn eine Klasse benötigt wird, deren Unterklassen 

selber festlegen, welche Objekte sie erzeugen. 



+ Spezialisierungsmöglichkeiten für Unterklassen 

(flexibler als direktes Erzeugen der Objekte) 

+ Verbindung paralleler Klassenhierarchien möglich 

- Probleme, wenn Fabrikmethode keine Default- 

Implementierung besitzt Zwang zur 

Unterklassenbildung 

Verwendung: 

Toolkits und Frameworks 



14

Mazegame mit Factory Method (1) 

class GAME_WITH_FACTORY_METHOD 

feature -- Factory Methods 

CreateMaze: MAZE is 


do Result := MakeMaze; 

r1 := MakeRoom (1); r2 := MakeRoom (2); 

d := MakeDoor (r1,r2); 

Result.AddRoom (r1); Result.AddRoom (r2); 

r1.SetSide ("North",MakeWall); 

r1.SetSide ("East",d); 

r1.SetSide ("South",MakeWall); 

r1.SetSide ("West",MakeWall); .... 

end 

Mazegame mit Factory Method (2) 

end 


do !!Result end 

MakeRoom (no:INTEGER) : ROOM is 

do !!Result.make(no) end 

MakeWall: WALL is 

do !!Result end 

MakeDoor (r1,r2:ROOM) :DOOR is 

do !!Result.make(r1,r2); end 



Pattern Singleton 


Zweck: 

stellt sicher, dass eine Klasse genau ein 

Objekt besitzt und ermöglicht einen 

globalen Zugriff auf dieses Objekt. 

Singleton 

einzigesExemplar 

singletonDaten 

Exemplar() 

SingletonOperation() 

GibSingletonDaten() 

Result:=einzigesExemplar 






Wenn es genau ein Objekt einer Klasse geben und 

ein einfacher Zugriff darauf bestehen soll. 

Wenn das einzige Exemplar durch Spezialisierung 

mittels Unterklassen erweitert wird. 


+ Zugriffskontrolle auf das Exemplar durch 

Singleton-Klasse 

+ Singleton-Klasse kann durch Unterklassen 

spezialisiert werden 

+ Werden später mehrere Exemplare benötigt, 

kann diese Änderung leicht durchgeführt werden 



15

Pattern Singleton (1) 


class SINGLETON 


the_singleton: SINGLETON is 

once 

Result := Current; 

end 

invariant 

only_one_instance: Current = the_singleton 

end 

deferred class SINGLETON_ACCESS 


singleton: SINGLETON is deferred end 

is_real_singleton: BOOLEAN is 

do 

Result := singleton=singleton 

end 

end 




class MAZE_FACTORY_ACCESS 

inherit SINGLETON_ACCESS 

redefine singleton 

end 

feature 

singleton: MAZE_FACTORY is -- Klasse MAZE_FACTORY 

once !!Result 

-- muss von SINGLETON erben 

end 

new_maze: MAZE is 

do Result := singleton.MakeMaze end 

new_room (no:INTEGER): ROOM is 

do Result := singleton.MakeRoom end ....... 

end 



class GAME_WITH_SINGLETON_FACTORY 

creation make 

feature {NONE} aMaze: MAZE; 

feature 

make is 

local maze_fac: MAZE_FACTORY_ACCESS 

do !!maze_fac; aMaze := CreateMaze (maze_fac); end 

CreateMaze (fac: MAZE_FACTORY_ACCESS): MAZE is 

local r1, r2: ROOM; d: DOOR; 

do Result := fac.new_maze; 

r1 := fac.new_room(1); r2 := fac.new_room(2); 

door := fac.new_door(r1,r2); 

Result.AddRoom(r1); Result.AddRoom(r2); ..... 

-- set up r1 and r2 

end 

end 


16

Entwurfsmuster - Design Pattern Entwurfsmuster - Design Pattern ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?