Einführung in die Informatik I Kapitel 13: Entwurfsmuster

Einführung in die Informatik I
Prof. Bernd Brügge, Ph.D
Technische Universität München
Wintersemester 2003/2004
Kapitel 13: Entwurfsmuster
2
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 1

Überblick über dieses Kapitel
Entwurfsmuster
– Ziele von Entwurfsmustern
– Kategorien von Entwurfsmustern
Entwurfsmuster in diesem Kapitel
¸Brückenmuster: Unterstützung von Altsystem und visionärem System
– Strategiemuster: Zugriff auf eine Familie von Algorithmen
– Adaptermuster: Verbindung zweier inkompatibler Schnittstellen
(Verbindung zu einem Altsystem)
– Beobachtermuster: Trennung zwischen Modell und verschiedenen Sichten
vom Modell
– Modell-Sicht-Steuerung (Model-View-Controlller, MVC): Trennung vom
Modell, verschiedenen Sichten und der Programmsteuerung
Objekte im MVC Muster heissen auch “business objects”
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 2

Entwicklung eines Interaktiven Spiels
In einem rechtwinkliges Feld fahren viele Autos. Einige sind
schnell, einige sind langsamer. (Die Anzahl der Autos ist beliebig,
aber ist zur Compilationszeit festgelegt).
Der Spieler kontrolliert ein bestimmtes Auto mit der Maus.
Die Anfangsrichtung der Autos ist zufällig gewählt.
Die Autos können miteinander und mit dem Spielrand kollidieren.
w Bei einer Kollision zwischen Autos gibt es einen Gewinner und
ei-nen Verlierer. Der Verlierer bleibt stehen und fällt aus.
w Wenn ein Auto mit dem Spielfeldrand kollidiert, wird es
abhängig von seiner Geschwindigkeit und Richtung wieder auf
das Spielfeld zurückgeworfen.
Das Ziel: Werfen Sie als Spieler mit ihrem Auto soviele Autos wie
möglich aus dem Rennen, bevor Ihr Auto aus dem Rennen geworfen
wird.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 3

Objektentwurf von GameBoard, Referee und Car
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 7

Ein Spiel mit 1 gegnerischen Auto
In Gameboard.java (bumpers:cars:GameBoard.java) bestimmen Sie
die Anzahl der schnellen und langsamen Autos
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 9

Klassifizierung der Autos
Car
FastCar
SlowCar
UserCar
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 11

Klasse Rectangle
Diese Klasse ist im Packet java.awt definiert.
Sie definiert ein Recheck durch die x,y
Koordinaten der oberen linken Ecke und die
Breite (width) und Höhe (height).
getSize() berechnet den Umfang des
Rechtecks
intersects() prüft, ob ein gegebenes
Rechteck das Rechteck schneidet
growth() erweitert den Umfang des
Rechtecks um eine gegebene Höhe und Weite
translate() bewegt die obere linke
Ecke des Rechtecks
+ x: int
+ y: int
+ height: int
+ width: int
Rectangle
+Dimension getSize()
+boolean intersects(Rectangle r)
+grow(int h, int v)
+translate(int x, int y)
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 13

(0,0)
Kollisionen: Vorüberlegungen (3)
Jedes Auto repräsentieren wir durch ein um-fangendes
Rechteck (bounding rectangle).
h
(x,y)
Damit bezeichnen wir das kleinste Rechteck, das alle
Pixels des entsprechenden Bildes vom Auto noch
einschliesst.
w Wir bekommen das umfangende Rechteck durch
getSize() durch getPosition().
Eine liegt Kollision dann vor, wenn zwei gegebene
umfangende Rechtecke mindestens ein Pixel gemeinsam
haben (intersects()).
w Das einzige Problem damit ist, dass das Bild eines Autos
irregulär ist, und das umfangende Rechteck nicht ganz
ausfüllt.
Um dafür zu kompensieren, reduzieren wir das umfangende
Rechteck auf 3/4 der originalen Größe (mit growth()), und
platzieren sein Zentrum leicht nach links unten (mit
translate()).
Noch ein „kleines“ Problem: Wer ist der Gewinner der
Kollision?
w
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 14

Prüfen von Kollisionen
Referee
Car
public void moveCars() {
// First each car makes a move
// Then we check for collisions
for (int i = 0; i < cars.length; i++) {
}
}
if (cars[i].isCrunched( )) {continue;}
Car crashedCar =
collisionStrategy.detectCollision(
drivenCar, cars[i]);
if(crashedCar != null){
BANG.play();
crashedCar.setCrunched();
if(drivenCar.isCrunched()){
stopGame();
}else{
}
// check if player won
+startGame()
+ stopGame()
+ moveCars()
+boolean isCrunched()
+ Point getPosition()
+ Dimension getSize()
+ setCrunched()
public Car detectCollision(Car car1, Car car2){
Point p1 = car1.getPosition( );
Dimension d1 = car1.getSize( );
Rectangle r1 = new Rectangle(p1, d1);
r1.translate(p1.x / 8, p1.y / 8);
r1.grow(-1 * d1.width / 4, -1 * d1.height / 4);
Point p2 = car2.getPosition( );
Dimension d2 = car2.getSize( );
Rectangle r2 = new Rectangle(p2, d2);
r2.translate(p2.x / 8, p2.y / 8);
r2.grow(-1 * d2.width / 4, -1 * d2.height / 4);
if (r1.intersects(r2)) {
if (p1.y > p2.y){return car2; }else{return car1;}
}
return null;
}
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 15
*

Beziehung zwischen Referee und Kollisionen
Referee
CollisionStrategy
initGame()
startGame()
stopGame()
moveCars()
setCollisionStrategy(strategy:CollisionStrategy)
getCollisionStrategy():CollisionStrategy
detectCollision(car1:Car, car2:Car):Car
getName():String
YourCollision
RandomCollision
DefaultCollision
detectCollision(car1:Car, car2:Car):Car
getName():String
detectCollision(car1:Car, car2:Car):Car
getName():String
detectCollision(car1:Car, car2:Car):Car
getName():String
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 16

Aufgabe: Entwickeln Sie YourCollision!
Laden Sie die Bumpers Version von der Info I Portalseite
w http://wwwbruegge.in.tum.de/projects/lehrstuhl/twiki/bin/view/Lehrstuhl/Informatik1WiSe2003/
w Kompilieren und spielen Sie das Spiel:-)
w Schreiben Sie Ihre neue Kollisionsfunktion
w Klassenname muss personifiziert sein (z.B. CollisionBerndBruegge)
w Schicken Sie den Quellcode Ihrer neuen Klasse per e-mail an
timo.wolf@in.tum.de (mit Attachment, aber ohne Wurm:-)
t Betreff: “Bumpers Info”
t Achtung: e-mail wird gefiltert, die Betreffzeile muss exakt sein
w Letzte Möglichkeit: Vorlesung am Dienstag (via Chat)
w Aus allen funktionierenden Beiträgen wird ein Gewinner ausgelost.
Am Dienstag wird die Entwicklungsumgebung CodeGuide benutzt
w Läuft auf allen Plattformen (Linux, MacOS X, Windows)
w Runterladbare Version (30 Tage Probe): http://www.omnicore.com
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 17

Ideen für Kollionsfunktionen
Das Auto muss von links getroffen werden
Das Auto muss von rechts getroffen werden
Das Auto muss von oben rechts kommen
Das gegnerische Auto muss zweimal getroffen werden
w Achtung: Gegnerisches Auto muss erst bestimmt werden
Das gegnerische Auto muss in einer bestimmten Richtung fahren
usw….
?
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 18

Stand des “Bumpers++” Projektes
Insgesamt 35 Einreichungen bisher
Die ersten 11 Einreichungen in meiner Liste
w Sebastian Wegener
w Jochen Mehlhorn
w Maria Sterr
w Martin Lehner
w Andreas Spurny
w Jörg Selbach und Samuel Kerschbaumer
w Robert Isele
w Ivo Bonev & Aleksandar Kanchev
w Stefan Puchner
w Christian Schröder
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 19

Weiteres Vorgehen
Heute: Vorführung dieser 11 Einreichungen
wJeder Student/Studentin führt die Lösung selbst vor
Wer heute während der Vorlesung noch einreicht wird noch
begutachtet.
wEinreichung per Chat bis 13:30!
Preise (gestiftet von der Firma Apple)
w1. Preis: Gutschein für einen iPod mini
w2. Preis: Gutschein für einen iPod mini
Preisverleihung am nächsten Dienstag!
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 20

Vorführungen
Wenn Sie Ihren Namen hier sehen, bitte nach vorne kommen (es
sei denn, Sie in der Arcisstrasse:-)
w Sebastian Wegener
w Jochen Mehlhorn
w Maria Sterr
w Martin Lehner
w Andreas Spurny
w Jörg Selbach / Samuel Kerschbaumer
w Robert Isele
w Ivo Bonev & Aleksandar Kanchev
w Stefan Puchner
w Christian Schröder
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 21

Für die wagemutigen “just in time” Entwickler
Es stehen zur Verfügung: 7 iBooks mit CodeGuide und Bumpers
Holen Sie sich ein iBook (nicht per eBay:-)
w First come, first served
iBooks bei
w Timo Wolf, Patrick Renner
w Oliver Creighton, Michael Nagel
w Sie stehen auch für Fragen stehen zur Verfügung
Öffnen Sie das Bumpers Projekt
Finden Sie die Klasse “CollisionStrategy”.
Legen Sie los!
Einsenden der Lösung aus dem Hörsaal
w Über Rendezvous an Bumpers
Einsenden der Lösung aus der Arcisstrasse
w Über AIM und Buddylist: Bernd Bruegge
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 22

Senden der Lösung per iChat
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 23

Senden der Lösung per iChat
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 24

Senden der Lösung per iChat
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 25

Öffnen des Bumper Projektes in CodeGuide
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 26

Auswählen des “bumpers.cpr” Projektes
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 27

Das geöffnete Projekt
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 28

Übersetzen und Starten von Bumpers
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 29

Das gestartete Spiel Bumpers
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 30

Auswahl des benutzer-definierten Java Packets control
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 31

Erzeugen einer neuen Klasse
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 32

Wähle Sie “Class” aus
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 33

Wählen Sie einen Namen für Ihre Klasse
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 34

Die neue Klasse ist erzeugt
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 35

Kopieren Sie den Quellcode von “DefaultCollision.java” and ändern Sie den
Rumpf der Methode detectCollision
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 36

Sebastian Wegener
Spielerauto gewinnt die Kollision, wenn es mit höherer
Geschwindigkeit von oben kommt. Sonst verliert es.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 37

Jochen Mehlhorn
Der Spieler gewinnt, wenn sein Auto 4 Geschwindigkeitseinheiten
langsamer als das andere Auto ist.
Gewinnt der Spieler eine Kollision, erhöht sich seine
Geschwindigkeit.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 38

Maria Sterr
Spieler gewinnt, wenn sein Auto von oben links, oder von unten
rechts kommt. Ansonsten verliert er.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 39

Martin Lehner
Die Kollisionsbereiche der Autos werden in vordere, hintere und
seitliche Trefferbereiche aufgeteilt.
Je nach Trefferbereich und einer Zufallszahl gewinnt oder verliert
ein Auto.
Die drei Trefferbereiche werden durch die Klasse Rectangle
dargestellt.
Es wird jeder einzelne Bereich auf eine Kollision überprüft und
somit die Position der Kollision berechnet.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 40

Andreas Spurny
Der Spieler kann 5 Kollisionen verlieren, bevor er das Spiel verliert.
Das Spielerauto gewinnt eine Kollision von rechts unten. Ansonsten
verliert es die Kollision.
Verliert der Spieler eine Kollision gegen ein Auto mit einer
Geschwindigkeit größer als 5, so ist das Spiel bei der nächsten
verlorenen Kollision verloren.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 41

Jörg Selbach / Samuel Kerschbaumer
Das obere Auto gewinnt die Kollision.
Das höhere Auto wird nicht mit einem umgebenden Rechteck,
sondern Pixel-basiert berechnet.
Dazu müssen die Farbwerte des Image gelesen werden.
Dazu werden Klasse PixelGrabber aus dem
java.awt.image API verwendet.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 42

Robert Isele
Das schnellere Auto ist immer Gewinner einer Kollision.
Der Kollisionsgewinner verliert aber erheblich an Geschwindigkeit.
Das Spielerauto wird automatisch schneller.
Pixelgenaue Kollisionsabfrage
Um defekte Autos erkennen zu können, liegen sie auf dem Dach
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 43

Ivo Bonev & Aleksandar Kanchev
Der Spieler hat 5 Minuten Zeit zu gewinnen.
Ein Auto ist zerstört, wenn es von dem Spielerauto innerhalb von 5
Sekunden zweimal getroffen wird.
Trifft der Spieler unterschiedliche Autos, wird ein Zähler erhöht, der
zur Niederlage führt.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 44

Stefan Puchner
Wird das Spielerauto von unten oder oben angefahren, verliert es die
Kollision.
Ein Auto verliert an Geschwindigkeit, wenn es von vorne angefahren
wird.
Ein Auto verliert die Kollision, wenn es bei minimaler
Geschwindigkeit von vorne angefahren wird.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 45

Christian Schröder
Der Spieler wird um eine Feuerwaffe bereichert.
Gegner können nicht nur durch einen Unfall, sondern auch durch die
Waffe zerstört werden.
Neben der Kollisionsklasse wurden noch weitere Klassen verändert
und neue Bilder eingefügt.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 46

Ein Spiel: Erreiche-15
Wir starten mit den neun Zahlen 1,2,3,4, 5, 6, 7, 8 and 9.
Sie und Ihr Gegner wählen abwechselnd eine Zahl
Jede Zahl kann nur einmal genommen werden: Wenn Ihr Gegner eine
Zahl gewählt hat, können Sie diese Zahl nicht mehr wählen.
Die erste Person, die 3 Zahlen gewählt hat, die zusammen 15
ergeben, hat gewonnen.
Beispiel:
Sie:
Ihr Gegner:
1 5 3 8
6 9 7 2
Gegner
Gewinnt!
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 47

Neues Spiel
Ich: 7 4 1 9
Andy: 3 5 2 8
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 48

Characteristika von Erreiche-15
Schwierig zu spielen
Das Spiel ist besonders schwierig, wenn es nicht erlaubt ist, sich
irgend etwas aufzuschreiben.
Warum?
w Alle Zahlen müssen überprüft werden, um zu sehen, ob man
gewonnen oder verloren hat. (Was sagt das über die
Laufzeitkomplexität aus?)
w It is hard to see what the opponent will take if you take a certain
number
w The choice of the number depends on all the previous numbers
w Not easy to devise an simple strategy
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 49

Ein anderes Spiel: Tic-Tac-Toe
Quelle: http://boulter.com/ttt/index.cgi
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 50

Eine Patt Sitation
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 51

Strategie zur Ermittlung einer Gewinnsituation
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 52

Gewinn-Situationen für Tic-Tac-Toe
Gewinnmuster
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 53

Tic-Tac-Toe ist “leicht”
Warum? Reduktion der Komplexität durch Muster und Symmetrie
Muster: Wenn der Spieler die folgenden 3 Muster kennt, kann er
jeden Zug des Gegners neutralisieren.
• Symmetrie:
♦ Man braucht sich nur diese 3 Muster zu merken und kann
mit 8 völlig verschiedenen Spielsituationen fertig werden.
♦Weiterhin muss man sich nur 3 Eröffnungszüge und die
Antworten des Gegners darauf merken.
♦Dann kann man Tic-Tac-Toe nicht mehr verlieren.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 54

Erreiche-15 und Tic-Tac-Toe sind identische Probleme
Jedes Tupel von 3 Zahlen, mit der man das Erreiche-15 Spiel
gewinnt, ist auch eine Gewinnsituation für Tic-Tac-Toe.
Jede Tic-Tac-Toe Lösung ist eine Lösung für das Erreiche-15 Spiel.
Um die Beziehung zwischen beiden Spielen zu sehen, positionieren
wir die 9 Zahlen in folgendem Arrangement:
8 1 6
3 5 7
4 9 2
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 55

Sie:
Gegner:
1 5 3 8
6 9 7 2
8 1 6
3 5 7
4 9 2
8 1 6
3 5 7
4 9 2
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 56

Entwurfsmuster
Hauptziel:
w Wiederverwenden von existierendem Entwurfswissen
w Wiederverwenden von bereits existierender Funktionalität.
Definition: Ein Entwurfsmuster beschreibt ein Problem, das immer
wieder in unserer Umgebung auftaucht, und es beschreibt den Kern
der Lösung zu diesem Problem, und zwar in solcher Weise, dass man
die Lösung wiederverwenden kann, ohne den Lösungsweg
wiederholen zu müssen.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 57

Was ist ein gutes Muster?
Gute Muster adressieren unsere mentalen Grenzen:
w Unser Kurzgedächtnis hat nur eine limitierte Kapazität (7+-2).
Gute Muster sind intellektuell “langweilig”.
w Ein “natürliches Modell” überwindet psychologische Grenzen
besser als eine schlechte Repräsentation.
Gute Muster reduzieren die Komplexität des Systems
w Durch die Wahl des Modells werden komplexe Tätigkeiten
einfach.
w Benutzung von Symmetrien
Gute Muster lassen sich leicht kommunizieren.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 58

Einschub: Delegation
Bei der Delegation teilen sich zwei Klassen die Ausführung einer
Operation
w Die Empfängerklasse empfängt den Operationsaufruf und
delegiert ihn an die Delegationsklasse.
w Der Klassenentwickler muss sicherstellen, dass die Klasse
Benutzer die Delegate Klasse nicht missbrauchen kann.
Ruft auf
Delegiert zu
Benutzer Empfänger Delegate
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 59

Wiederverwendung von existierendem Code:
Delegation oder Implementationsvererbung?
Beispiel:
w Wir müssen eine Klasse Keller implementieren.
w Es existiert schon die Implementation einer Klasse Liste und
wollen sie wiederverwenden.
Delegation: Klasse A fängt die Operation ab und sendet sie an eine
andere Klasse B, die die existierende Funktionalität enthält.
Implementationsvererbung: Die existierende Funktionalität ist in
der Oberklasse A, die neue Funktionalität ist in der Unterklasse B.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 60

Beispiel: Implementation eines Kellers (mit existierender Liste)
Implementationsvererbung
Delegation
Liste
Liste ist verborgen !
+Add()
+Remove()
Benutzer
Keller
Liste
Benutzer
Keller
+Push()
+Pop()
+Top()
+Push()
+Pop()
+Top()
Remove()
Add()
L Die Unterklasse kennt die Details der Oberklasse.
L Änderung in der Oberklasse erfordert Recompilation der Unterklasse.
L Operationen Add() und Remove() sind öffentlich für Benutzer.
L Gefahr des Missbrauchs der Kellergesetze!
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 61

Die “Zutaten” von Entwurfsmustern
Komposition (auch Schwarzer Kasten Wiederverwendung)
w Das neue Objekt mit neuer Funktionalität ist eine Aggregation
von existierenden Komponenten
w Wichtiges Konzept: Delegation
Vererbung (Weißer Kasten Wiederverwendung)
w Neue Funktionalität wird durch Vererbung erreicht.
w Wichtige Konzepte: Implementationsvererbung und
Spezifikationsvererbung
Jedes Entwurfsmuster ist eine Kombination von
Delegation und Vererbung von Klassen
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 62

Zur Wiederholung: Das Brückenmuster
Delegation
Implementation
Benutzer
Abstraktion
+Operation1()
+Operation2()
+Operation3()
+Operation4()
Vererbung
+Operation1Impl()
+Operation2Impl()
+Operation3Impl()
+Operation4Impl()
Entkoppelung
des Benutzers
von der
Implementation
Konkrete
ImplementationA
+Operation1Impl()
+Operation2Impl()
Konkrete
ImplementationB
+Operation1Impl()
+Operation2Impl()
Polymorphe
Implementationen
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 63

Anwendungsmöglichkeiten für das Brückenmuster
Flexibilität: Wenn man ein permanente Bindung zwischen der
Schnittstelle und seiner Implementation verhindern will.
w Wenn die Implementation zur Laufzeit selektiert werden solll
w Wenn zwischen mehreren Implementationen zur Laufzeit hin-und
hergewechselt werden soll.
w Änderungen in der Implementation sollen nicht vom Benutzer
bemerkt werden, d.h. der Benutzercode muss nicht recompiliert
werden.
Erweiterbarkeit:
w Die Schnittstelle soll mit einer bestimmten Implementation
geliefert werden.
w Später soll eine neue Implementation ohne große Änderungen im
Benutzercode hinzugefügt werden.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 64

Ein weiteres Muster: Strategiemuster
Motivation:
w In Bumpers gibt jetzt viele Kollisionsfunktionen alle mit derselben
Schnittstelle
w Für unterschiedliche Situationen ist die eine oder die andere Variante
wünschenswert
t Für den Anfänger möchte man eine einfache Funktion bereitstellen
t Einen Fortgeschrittenen Spieler möchte man komplizierteren
Funktionen herausfordern.
Die unterschiedliche Situation nennen wir Kontext
Die gemeinsame Schnittstelle nennen wir Strategie
Kontext hieß früher auch Politik und Strategie nannte man
Mechanismus
w Das Strategiemuster erlaubt eine Trennung zwischen der Politik und
den Mechanismen zur Implementierung der Politik
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 65

UML Klassendiagramm für Bumpers
Benutzer
Bumpers
Kontext
Strategie
Referee
CollisionStrategy
initGame()
startGame()
stopGame()
moveCars()
setCollisionStrategy(strategy:CollisionStrategy)
getCollisionStrategy():CollisionStrategy
detectCollision(car1:Car, car2:Car):Car
getName():String
YourCollision
RandomCollision
DefaultCollision
detectCollision(car1:Car, car2:Car):Car
getName():String
detectCollision(car1:Car, car2:Car):Car
getName():String
detectCollision(car1:Car, car2:Car):Car
getName():String
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 66

Allgemeines Strategiemuster
Benutzer
Kontext
Strategie
+KontextSchnittstelle()
+ AlgorithmusSchnittstelle()
Algorithmus1
Algorithmus2
Algorithmus3
AlgorithmusSchnittstelle()
AlgorithmusSchnittstelle()
AlgorithmusSchnittstelle()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 67

Strategiemuster vs Brückenmuster
Ähnlich wie beim Brückenmuster können eine Unterklasse durch
eine andere Unterklasse zur Laufzeit ersetzt werden.
Beim Brückenmuster wird die Ersetzung gewöhnlich zur Startzeit
gemacht (im Konstruktor der Klasse Abstraktion)
Beim Strategiemuster wird eine Kontextschnittstelle in der Klasse
Kontext angeboten, die vom Benutzer zur Laufzeit benutzt werden
kann, um die gewünschte Unterklasse auszuwählen
w Anfänger vs. Experte
w Laufzeitkomplexität vs Speicherkomplexität
w Niveau des Spiels
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 68

Strategiemuster
Auswahl des Algorithmus in
der Klasse Benutzer
Benutzer
Kontext
Strategie
+KontextSchnittstelle()
+ AlgorithmusSchnittstelle()
Algorithmus1
Algorithmus2
Algorithmus3
AlgorithmusSchnittstelle()
AlgorithmusSchnittstelle()
AlgorithmusSchnittstelle()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 69

Brückenmuster
Auswahl der Unterklasse im
Konstruktor
Benutzer
Abstraktion
+Operation1()
+Operation2()
+Operation3()
+Operation4()
Implementation
+Operation1Impl()
+Operation2Impl()
+Operation3Impl()
+Operation4Impl()
Konkrete
ImplementationA
Konkrete
ImplementationB
+Operation1Impl()
+Operation2Impl()
+Operation1Impl()
+Operation2Impl()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 70

Bumpers Programmieraufgabe
Insgesamt 40 Einsendungen!
Kern der Aufgabe war es, eine Unterklasse zu schreiben und den
Quellcode dieser neuen Klasse an den Aufgabensteller zu schicken.
t “Offshore-Programmierungs” Modell
Viele originelle Einsendungen
Einige Einsendungen gingen weit über das hinaus, was gefragt
wurde.
w Allerdings nicht als Unterklasse der Klasse CollisionStrategy,
sondern durch eine Anzahl von Änderungen im gesamten
Bumpers Code
Nach langem Überlegen haben wir uns entschlossen, alle
Einsendungen zu berücksichtigen und die beiden Preise durch eine
Verlosung zu bestimmen!
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 71

Einsendungen
1 Aleksandar Kanchev
2 Alex Duliu
3 Andreas Meinl
4 Andreas Pfadler
5 Andreas Spurny
6 Andreas Würfl
7 Benjamin Frank
8 Christian Kern
9 Christian Schröder & Johannes Stamme
10 Christian Stöger
11 Cornelia Kuckein
12 Dennis Titze
13 Deyan Peev
14 Dominik Grusemann
15 Florian Hamel
16 Florian Reichl
17 Ivo Bonev
18 Jakob Vogel & Sebastian Hagen
19 Jan Birke
20 Jochen Mehlhorn
21 Johannes Pichlers
22 Jörg Selbach
23 Julia Braun
24 Leon v. Tippelskirch
25 Lukas Mai
26 Maria Sterr
27 Mario Gemoll
28 Martin Lehner
29 Nick Heuser
30 Nicolas Heuser
31 Peter Pichlmaier
32 Ralf Stauder
33 Rene Treffer
34 Robert Isele
35 Samuel Kerschbaumer
36 Sebastian Wegener
37 Stefan Kiendl
38 Stefan Puchner
39 Thomas Endres
40 Thomas Müller
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 72

Verlosung
Gutschein für einen iPod mini
wName: Dominik Grusemann
Gutschein für einen iPod mini
wName: Nicolas Heuser
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 73

Und weiter geht es in der Vorlesung
Adaptermuster
Proxymuster
Beobachtermuster
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 74

Zusammenarbeit von inkompatiblen Systemen
Apollo 13: “Houston we have a problem”
Nach der Explosion mussten die Astronauten vom Command
Module in den Lunar Module umziehen
w Lunar Module
t Entwurfsparameter: 2 Leute leben darin für 2 Tage
t Jetzt: 3 Leute müssen für 4 Tage darin leben
w Im Lunar Module System gab es 4 Kanister zum Speichern von
Kohlendioxid mit runden Öffnungen
t Nach 1.5 Tagen waren die Kanister gefüllt, und der Anteil
vom Kohlendioxid im Lunar Module wurde lebensgefährlich
t Entfernung des Kohlendioxids wurde zum großen Problem
Im Command Module gab es Lithiumhydroxid Kanister, die
Kohlendioxid entfernen konnten, aber sie hatten eine quadratische
Öffnung!
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 75

Kohlendioxidspeicher-
Schnittstelle im
Lunar Module System
Kohlendioxidspeicher-
Schnittstelle im
Command Module System
Astronaut
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 76

Adaptermuster
Konvertiert die Schnittstelle einer existierenden Klasse in
eine andere Schnittstelle, die vom Benutzer erwartet wird.
Ein Adapter lässt Funktionen und Klassen
zusammenarbeiten, die ursprünglich nicht für die
Zusammenarbeit entworfen worden sind.
Wird oft benutzt um eine alte Softwarekomponente -
manchmal Legacy System genannt - in einem neuen
System wieder zu verwenden.
Anderer Name: Wrapper
Es gibt 2 Arten von Adaptermustern:
w Klassen-Adapter : Benutzt Mehrfachvererbung
w Objekt-Adapter: Benutzt Einfachvererbung und
Delegation
Objekt-Adapter gibt es häufiger als Klassen-Adapter. Wir
werden hier nur Objekt-Adapter besprechen.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 77

Adaptermuster
Benutzer
Zielschnittstelle
Request()
Adaptee
ExistingRequest()
Vererbung
adaptee
Adapter
Delegation
Request()
Adaptee ist das Altsystem. Oft ist es nicht einmal eine Klasse.
Zielschnittstelle ist die neue moderne Spezifikation!
Adapter ist das Verbindungsglied zwischen Zielschnittstelle und
Adaptee.
w Vererbung wird benutzt, um die Schnittstelle der abstrakten Klasse
Zielschnittstelle zu implementieren.
w Delegation wird benutzt um den Adaptee an den Adapter zu binden.
w Zielschnittstelle wird in Java als Schnittstelle realisiert.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 78

Adapter vs Brückenmuster
Ähnlichkeit:
w Beide Muster verstecken die Details einer existierenden
Implementation
Unterschied:
w Das Adaptermuster ist dazu da, um völlig unabhängig voneinander
entworfene Komponenten zusammenarbeiten zu lassen.
t Es wird auf Systeme angewandt, nachdem sie implementiert
worden sind.
w Das Brückenmuster wird bereits während des Entwurfs benutzt, um
Abstraktionen und Implementationen unabhängig voneinander
entwickeln zu lassen.
t Entwicklung eines erweiterbaren Systems.
t Hinzufügen neuer Abstraktionen, selbst wenn sie während der
Analyse noch nicht bekannt waren.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 79

Beobachtermuster: Motivation
Subjekt
Sichten
DaimlerChrysler
Aktie
Wert der Aktie
Zeitlicher Verlauf des Aktienkurses
Anteil an meinem Portfolio
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 80

Beobachtermuster
Das Beobachtermuster definiert eine “eins-zu-viele”
Abhängigkeit zwischen 2 Arten von Objekten:
– Subjekt
– Beobachter
Wenn sich der Zustand des Subjektes ändert, dann werden
alle Beobachter benachrichtigt
– Jeder Beobachter ist dann selbst dafür verantwortlich, den neuesten
Zustand zu zeigen.
Anderer Name:
– Verleger-Abonnent (Publisher-Subscriber)
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 81

Ein weiteres Beispiel: Sichten einer Vorlesung. Es gibt 3
Möglichkeiten den Dateinamen zu ändern. Was passiert jeweils?
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 82

Sichten eines Dateinamen
+subscribeView()
+unsubscribeView()
+notifyView()
File
*
+updateFilename()
View
InfoView
ListView
SlideView
+updateFilename()
+updateFilename()
+updateFilename()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 83

Das allgemeine Beobachtermuster
Subject
addObserver(observer)
deleteObserver(observer)
notifyObservers()
observers *
Observer
update()
ConcreteSubject
subjectState
getState()
setState(newState)
subject
ConcreteObserver
observerState
update()
Subject repräsentiert das zu observierende Objekt
– ConcreteSubject repräsentiert den aktuellen Zustand eines Objektes
Die Klasse Observer repräsentiert eine Sicht (“view”) des Zustandes
– ConcreteObserver enthält den Zustand der Sicht
Observer kann man als Java interface implementieren. Subject nicht,
denn es muss die Liste aller Beobachter speichern.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 84

Beobachtermuster in Bumpers: Car und Instrument
Subject
Observer
DrivenCar
+subscribeInstrument()
+unsubscribeInstrument()
+notifyInstrument()
*
Instrument
+updateInstrument()
Concrete
Observer
Rotations
PerSecond
Speedometer
GPS
Body
+updateInstrument()
+updateInstrument()
+updateInstrument()
+updateInstrument()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 85

Beobachtermuster in Bumpers
Car
Lesen Sie den
Code in Bumpers!
+initiate()
DrivenCar
public class DrivenCar extends Car {
private ArrayList instruments = new ArrayList();
*
Instrument
+initiate()
+subscribeInstrument()
+unsubscribeInstrument()
+notifyInstrument()
+notifyInstruments()
public void initiate(int max_x, int max_y) {
//..Setting up the car
notifyInstruments();
}
public void notifyInstruments(){
Iterator iter = instruments.iterator();
while (iter.hasNext()) {
Instrument C = (Instrument)iter.next();
C.updateIntrument();
}
}
+updateInstrument()
public void subscribeInstrument(Instrument I){
if(I != null && !this.instruments.contains(I)){
this.instruments.add(I);
}
}
public void unsubscribeInstrument(Instrument I){
if(I != null && this.instruments.contains(I)){
this.instruments.remove(I);
}
}
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 86

Modell-View-Controller (Modell-Sicht-Steuerung
Muster)
Steuerung
Controller
View
initiator repository
*
1
subscriber
*
Model
1
notifier
Observer
(GUI, Graphische Benutzer
Schnittstelle)
Subject
(“Business Objects”,
Datenbank)
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 87

Programmierpraktikum Application Server
Sommersemester 2004
Für Info I Interessierte:
Vorbesprechung im Anschluss an diese Vorlesung
Volker Hafner
Ort: 01:07:014
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 88

Proxy Muster: Motivation
Es ist 13:30.
Ich sitze mit meinem drahtlosen Laptop in der Vorlesung
Ich muss heute noch unbedingt Bruegge’s Buch bei amazon.com
kaufen.
Ich kriege 1 kb/sec
Was kann ich tun?
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 89

Proxy Muster
Problem: Wenn das Objekt komplex ist, dann ist Objekt-
Instantiierung “teuer”
Lösung:
– Verzögere die Instantiierung bis zu der Zeit, wo das Objekt tatsächlich
benutzt wird
– Wenn es nie benutzt wird, fallen die Kosten für die Objekt Instantiierung
also nicht an!
Problem: Wenn das Objekt auf einem anderen Rechner ist, dann ist
sogar der Objekt-Zugriff “teuer”
Lösung:
– Instantiiere und initialisiere ein “kleineres” lokales Objekt, das als
Stellvertreter (“proxy”) für das richtige Objekt agiert.
– Greife vorwiegend auf dieses lokale Objekt zu
– Greife auf das entfernte (richtige) Objekt nur zu, wenn der Benutzer es
möchte.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 90

Proxymuster Klassendiagramm
Benutzer
Subjekt
Request()
Vererbung
Proxy
Request()
Delegation
RealesSubjekt
Request()
Das Proxymuster ist auch eine Kombination
von Vererbung und Delegation
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 91

Proxymuster im Detail
Benutzer
Subjekt
Request()
Vererbung
Proxy
Request()
Delegation
RealesSubjekt
Request()
Wir benutzen Spezifikationsvererbung für die Klasse Subjekt
– In Java kann man Subjekt als Schnittstelle (interface) implementieren.
– Proxy ist Unterklasse der abstrakten Klasse Subjekt.
Der Benutzer ruft immer Request() in Proxy auf.
– Die Implementation von Request() in der Klasse Proxy benutzt dann Delegation,
um auf Request() in RealesSubjekt zuzugreifen.
– RealesSubjekt ist ebenfalls Unterklasse der abstrakten Klasse Subjekt.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 92

Anwendungen fürs Proxymuster
Verteilte Programmierung:
– Reduzierung der Kosten von Zugriffen auf entfernte Objekte
– Virtuelle Objekte
Authentifizierung:
– Überprüfung der Zugriffsrechte eines Aufrufers
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 93

Virtuelles Proxy Beispiel
Image
boundingBox()
draw()
ProxyImage
boundingBox()
draw()
realSubject
RealImage
boundingBox()
draw()
Images werden separat vom Text gespeichert und gezeigt.
Der Benutzer kann nicht sagen, ob er es mit ProxyImage anstatt
von RealImage zu tun hat.
Das Zeigen kann im Proxy anders implementiert sein also in
RealImage
– ProxyImage kann beispielsweise ein leeres Rechteck anstelle des Bildes
zeigen
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 94

Beispiel:
Webseitenzugriff
via RealImage
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 95

Aktivierung der Proxy Klasse
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 96

Beispiel:
Webseitenzugriff
via Proxy
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 97

Image
boundingBox()
draw()
ProxyImage
boundingBox()
draw()
realSubject
RealImage
boundingBox()
draw()
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 98

TUM
Mit Proxy
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 99

TUM
Ohne Proxy
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 100

Taxonomie von Entwurfsmustern
EntwurfsMuster
Strukturelle
Muster
Verhaltens
Muster
Erzeugungs
Pattern
Kommando
Beobachter
Strategie
Abstrakte
Fabrik
Builder
Muster
Adapter Brücke Kompositum
Proxy
Mehr Muster
In Info II
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 101

Weiterführende Literatur über Muster
E. Gamma, R. Helm, R.Johnson, J. Vlissides
– Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley,
1995
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal
– Pattern-Oriented Software Architecture: A System of Patterns. Wiley, 1996.
M. Fowler
– Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.
T. J. Mowbray & R. C. Malveau
– CORBA Design Patterns. Wiley, 1997.
S. W. Ambler
– Process Patterns: Building Large-Scale Systems Using Object Technology.
Cambridge University Press, 1998.
W. J. Brown, H. W. McCormick, & S. W. Thomas
– AntiPatterns and Patterns in Software Configuration Management. Wiley, 1999.
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 102

Gedanken zur Vorlesung (Anstatt einer Evaluierung)
Viele Experimente. Zuviele?
– Vorlesung als Broadcast vs Vorlesung als Interaktion
Die Internetverbindung zur Arcisstrasse
– Können wir auch im Sommersemester anbieten
– Immer noch am Experimentieren
– Videofilme
– Audio
Vorlesungsfolien
– Zeitiges Posten auf dem Portal
– Genauigkeit vs. Anzahl der Änderungen
– “Filme” der Vorlesungsfolien
– Alternative Darstellung der Folien? MultiFrameViewer
Interaktive Vorlesung
– Programmieraufgaben während der Vorlesung
Zentralübung
– Zusätzliche interaktive Programmieraufgaben (Bumpers)
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 103

Was kommt jetzt?
Am Donnerstag (12.Februar) keine Vorlesung
Klausur:
– 14. Februar 2004, 9:00 in verschiedenen Hörsälen
– Bitte achten Sie auf die Platzverlosung
– Lesen Sie noch einmal das Merkblatt und schauen sie auf die Info I-
Portalseite
Einführung in die Informatik II, Sommersemester 2004
– Dienstag 12:15- 13:45
– Donnerstag 8:30 - 10:00
– Zentralübung Dienstag nachmittag: Timo Wolf
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 104

Vielen Dank!
Auf Wiedersehen in Info II
Copyright 2004 Bernd Brügge, Christian Herzog Einführung in die Informatik I TUM Wintersemester 2003/2004 Kapitel 13, Folie 105