Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

transcript

Design Pattern SS 10

Prof. Albert Zündorf

Fachgebiet für Software EngineeringWilhelmshöher Allee 73

34121 Kassel(Raum 1339)

Organisatorisches

Umfang: 4 SWS teils Vorlesungen teils Übungen

Übungsbetreuung: Johannes Spohr, Sebastian Schulz

Ort und Zeit: Vorlesung: Dienstags 16:00 - 19:00 Raum 2104

(Erste Vorlesung: 13.04.10)Übung:? In obigem Zeitraum

Prüfung: Pflichtübungsaufgaben (korrigiert, bepunktet)

Folienskript / Screen Videos: http://www.se.eecs.uni-kassel.de.

Literatur

Grundlegend:

E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns (Elements of Reusable Object-Oriented Software); Addison Wesley, Bonn, ISBN 0-201-63361-2 (1994)

Patterns Home Page: st-www.cs.uiuc.edu/users/patterns/patterns.html

Unified Modeling Language:

Martin Hitz, Gerti Kappel: UML @ Work, dpunkt.verlag (ziemlich gut)

Hintergrund:

Frederick P.\ Brooks: The Mythical Man Month, Addison Wesley 1975 (ist nur kurz aber ziemlich witzig, unbedingt mal lesen)

Gliederung

1. Einführung

2. Design Grundprinzipien

3. Grundlegende Pattern

4. Weitere Pattern

5. Zusammenfassung

1. Einführung

Ziele der Veranstaltung:

Design Know How für große Programme > 100 000 LOC

Grundprinzipien der Wartbarkeit und Erweiterbarkeit

sicherer Umgang mit Vererbung und Delegation

Grundkenntnis der wichtigsten Design Pattern

neue UML 2.0 features

Beispiel Composite Pattern

Realisierung hierarchischer Datenstrukturen

kommt in praktisch allen Software-Anwendungen vor

naiver Ansatz verursacht dramatische Wartungsprobleme

Gute Lösung ist Ausgangspunkt für viele weitere Pattern

Gliederung

1. Einführung

4. Weitere Pattern

5. Zusammenfassung

Wartbarkeit

Erweiterbarkeit

ein Ort eine Design Entscheidung / eine Funktionalität lokale Änderungen

nur lokale Auswirkungen lokaler Änderung (Module/Klassen, Interfaces, Sichtbarkeiten)

"wenig" Vererbung

Vererbung

Substitutionsprinzip:Söhne müssen halten was die Väter versprechen

anstelle eines Vaterklassenobjektes kann man auch immer ein Unterklassenobjekt verwenden

EnterpriseEmployee

work (t : Task) : Product

Manager

work (t : Task) : Productmanage ( proj : Project ) : Presentation

Project

Presentation

Product

createddoes

Beispielsituationen

EnterpriseEmployee

Manager

Project

Presentation

Product

createddoes

…prod = e.work (t);…

Struktur

Verhalten Daten :Employee

:Employee

:Manager

:Product

:Presentation :Project

Beispielsituationen

EnterpriseEmployee

Manager

Project

Presentation

Product

createddoes

Struktur

:Employee

:Manager

:Product

Beispielsituationen

EnterpriseEmployee

Manager

Project

Presentation

Product

createddoes

Struktur

:Employee

:Manager

:Product

Beispielsituationen

EnterpriseEmployee

Manager

Project

Presentation

Product

createddoes

Struktur

:Employee

:Manager

:Product

Co- und Contravariante Redefinitionen:

wegen Substituierbarkeit:

input Parameter (Lesen) in Unterklassen nur verallgemeinern(Contravariante Redefinition)

output Parametern (Schreiben in Unterklassen nur spezialisieren(Covariante Redefinition)

Delegation:

run ()alarm ()

FlashLight

alarm()

Sirene

alarm()MailAlarm

alarm()

alarmDevice

Struktur

Verhalten Daten

…this.alarm();… :House

:FlashLight

:Sirene

:MailAlarm

AlarmDevice

alarm ()

Hausaufgabe 1:

Implementiert das Klassendiagramm zur Delegation

Implementiert die alarm () Methoden der AlarmDevice -Unterklassen mit unterschiedlichen System.out Ausgaben

Schreibt ein Testprogramm dass: ein House erzeugt, das House nacheinander mit verschieden AlarmDevice

verbindet jeweils einen alarm() auslöst

Abgabe:

Eclipse Workspace mit Projekt mit JUnit Test

start mit einem Click

Eclipse Projekte inklusive Quellcode

Gliederung

1. Einführung

4. Weitere Pattern

5. Zusammenfassung

1. Referenzarchitektur interaktive System

Repository

Data Model

GUI(Commands)

Generators / Interpreters

QVT(Control)

Import/ Export

GUI(Unparsing)

Datenmodell mit Composite Pattern: naiv

Struktur

Verhalten Daten

Datenmodell mit Composite Pattern: besser

Struktur

Verhalten Daten

Datenmodell mit Composite Pattern: gut

Struktur

Verhalten Daten

Hausaufgabe 2:

Implementiert ein Datenmodell für ein Filesystem mit dem Composite Pattern

Lest eine Teilbaum eueres Computers ein

es sollte eine Jar Datei enthalten sein.

zählt die Anzahl der Files inklusive der Files in den Jar Dateien

summiert die Dateigrößen aller .java Dateien auf

macht euch für weitere Anforderungen bereit

Composite Pattern Problem:

Struktur

Verhalten Daten

Naiver Ansatz:

Struktur

Verhalten Daten

Visitor Pattern

rekursiver Durchlauf durch Composite Struktur

durchreichen eines Visitor Objekts

uniformerer Umgang mit Rekursionsparametern

Trennung von Durchlauf und Aktion

Visitor Pattern

Struktur

Verhalten Daten

Visitor Pattern

Struktur

Verhalten Daten

Visitor Pattern

Struktur

Verhalten Daten

Visitor Pattern Zusammenfassung

Ziemlich viele accept und visit Methoden

Double Dispatch möglich

Seperation of concern

Zustandsobjekt in der Rekursion

Hausaufgabe 3:

stellt das Composite Pattern für Files vom letzten Mal auf ein Visitor pattern um.

Baut einen Visitor zur Summierung der Dateigrößen aller .java Dateien auf

Baut einen Visitor der alle Dateien zählt, auf deren Namen ein mitgelieferter regulärer Ausdruck matcht

Strategy Pattern

ersetze if-then-else-if Ketten

If-then-else-if Kette:

Struktur

Verhalten Datenpublic void ring () {

if (mode == SIRENE){ …}else if (mode == FLASH){ …}else if (mode == MAIL){ …}…

run ()ring ()

mode : int

MailAlarm

ring ()

Strategy Pattern:

run ()ring ()

ring ()

Sirene

ring ()

alarm 0..1

Struktur

Verhalten Daten

class House {

public void ring (){

alarm.ring ();}

:House :FlashLight

:Sirene

:MailAlarm

FlashLight

ring ()

Strategy Pattern

Struktur

Verhalten Daten

Hook Pattern (nicht im Gof-Buch)

zusätzliches Verhalten nachträglich einbauen

Hook Pattern:

run ()ring ()

ring ()

FlashLight

ring ()

Sirene

ring ()MailAlarm

ring ()

externAlarms

Struktur

Verhalten Daten

public void ring (){

storeProtocol ();

for (alarm in externAlarms){

alarm.ring ();}

:House :FlashLight

:Sirene

:MailAlarm

Chain of Responsibility

im wesentlichen Hook

aber Abbruch wenn erfolgreich bearbeitet

< next

Chain of Responsibility, original

run ()ring ()

ring ()

FlashLight

ring ()

Sirene

ring ()MailAlarm

ring ()

Struktur

Verhalten Daten

class Alarm {public boolean ring () {

if (next != null){

return next.ring();}return false;

:House :FlashLight

:Sirene

:MailAlarm

Chain of Responsibility, original :

run ()ring ()

ring ()

FlashLight

ring ()

Sirene

ring ()MailAlarm

ring ()

Struktur

Verhalten Datenclass FlashLight {

public boolean ring () {// try itif (bulb.isReady ()) {

bulb.activate ();return true;

}else {

super.ring ();} } }

:House :FlashLight

:Sirene

:MailAlarm

< next

Chain of Responsibility, besser debugbar:

run ()ring ()

ring ()

FlashLight

ring ()

Sirene

ring ()MailAlarm

ring ()

alarms n

Struktur

Verhalten Datenclass House {

public boolean ring () {boolean success = false;for (a in alarms) {

success = a.ring();if (success)

return true;}return false;

:House :FlashLight

:Sirene

:MailAlarm

{ordered}

alarms[1]

alarms[2]

alarms[3]

Chain of Responsibility, besser debugbar:

Struktur

Verhalten Datenclass FlashLight {

public boolean ring () {// try itif (bulb.isReady ()) {

bulb.activate ();return true;

}else {

return false;} } }

:House :FlashLight

:Sirene

:MailAlarm

run ()ring ()

ring ()

FlashLight

ring ()

Sirene

ring ()MailAlarm

ring ()

alarms n{ordered}

Beobachtungen

typische Kombinationen von Assoc und Vererbung

Unterklassen haben KEINE neue Methoden

Unterklassen redefinieren geerbte Methoden

Beobachtungen

Hausaufgabe 4:

Baut euer Hausbeispiel aus der ersten Hausaufgabe in eine Chain of Responsibility um.

Sinnvolle Tests

im wesentlichen Strategy

aber systematische Strategy-Änderung nach Benutzung

meist Implementierung von Statecharts

State:

Struktur

Verhalten Daten

TraficLight

state :Integer

transferCar(car)

class TrafficLigth {void transferCar (Car car) {

if (state == GREEN) {car.setPos (…);state = YELLOW;

}else if (state == YELLOW) {

car.stop();state == RED; }

else if (state == RED)car.stop()state = GREEN;

yellow

transferCar(car) / car.setPos(…)

transferCar(car) / car.stop()

State:

Struktur

Verhalten Daten

TLState

Yellow

currentTraficLight

transferCar(car)

:TrafficLight

:Yellow

:Green

namestates

states["red"]

states["yellow"]

states["green"]

class Red {void transferCar (Car car) {

car.stop()owner.current = owner.states["green"];

class Green {void transferCar (Car car) {

car.setPos(…)owner.current = owner.states["yellow"];

Listener/Observer/Model-View-Controler/Mediator

im wesentlichen Hook

aber Einsatz zur Überwachung von Änderungen

Listener/Observer/Model-View-Controler

Struktur

Verhalten Daten

usedSpace :Integer

propertyChange (obj, attrName, oldVal, newVal)

size :Integer

write(bytes[])

:Drive

usedSpace = 112

write ("aaaa")

class File {void write (bytes[]) {

…this.setSize (size+bytes.length());

void setSize (newVal) {if (this.size != newVal) {

int oldVal = size;size = newVal;firePropertyChange ("size", oldVal, newVal);

} }…

size = 23

size = 42

listeners >

Struktur

Verhalten Daten

usedSpace :Integer

size :Integer

write(bytes[])

:Drive

usedSpace = 112

write ("aaaa")

class File {…void firePropertyChange (attrName, oldVal, newVal){

for (l in listeners){

l.propertyChange (this,attrName,oldVal,newVal);

} }…

size = 23

size = 42

listeners >

Struktur

Verhalten Daten

usedSpace :Integer

size :Integer

write(bytes[])

:Drive

usedSpace = 112

write ("aaaa")

class Drive {…void propertyChange (obj,attrName,oldVal,newVal){

usedSpace += newVal – oldVal;} }…

size = 23

size = 42

listeners >

Struktur

Verhalten Daten

usedSpace :IntegerFile

size :Integer

write(bytes[])

:Drive

usedSpace = 112

write ("aaaa")

class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal){

for (t : targets) {t.usedSpace += newVal – oldVal;

} } }…

size = 23

size = 42

listeners >

SpaceUpdater

propertyChange (obj,attrName,oldVal,newVal)

targets >n

:SpaceUpdater

Model-View-Controler/Mediator

Struktur

Verhalten Daten

usedSpace :IntegerFile

size :Integer

write(bytes[])

:Drive

usedSpace = 112

write ("aaaa")class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal){

for (t : targets) {t.usedSpace += newVal – oldVal;

} } }…

size = 23

size = 42

listeners >

SpaceUpdater

propertyChange (obj,attrName,oldVal,newVal)

targets >n

:SpaceUpdater

:Computer

usedSpace = 1012

Computer

Hausaufgabe 5?:

Baut ein GUI für ein Auto

es soll nur die Geschwindigkeit modelliert werden

die Geschwindigkeit soll auf zwei Wegen visualisiert werden: Zahldarstellung (JSpinner) Schieberegler

die Geschwindigkeit soll in beiden Views editiert werden können und von einem Testprogramm verstellt werden

macht eine Tabelle für mehrere Autos

Listener Concept for Car Example

Struktur

Verhalten Daten

Struktur

Verhalten Daten

Template Method

Motivation ähnlich wie Hook

aber feste Vorgabe von abstrakten Template-Methoden

alle Template-Methoden müssen überschrieben werden

Template Method:

run ()ring ()

+ ring ()~ start ()~ stop ()alarm

Struktur

Verhalten Daten

class Alarm {void ring () {

start ();…stop ();…

:House :FlashLight

:Sirene

:MailAlarm

MailAlarm

ring ()

Sirene

ring ()

FlashLight

~ start ()~ stop ()

Template Method:

run ()ring ()

+ ring ()~ start ()~ stop ()alarm

Struktur

Verhalten Daten

class FlashLigth {void start () {

powerOn ();}

void stop () {powerOff ()

:House :FlashLight

:Sirene

:MailAlarm

MailAlarm

ring ()

Sirene

ring ()

FlashLight

~ start ()~ stop ()

Decorator

ähnlich wie Composite mit nur einem Kind

ähnlich wie Chain-of-Responsibility

erweitere eine Strategy um zusätzliche Aktionen

Decorator:

Struktur

Verhalten Daten

class MailAlarm {ring () {

sendMail();orig.ring();

:House

:Sirene

:MailAlarm

MailAlarm

ring ()

run ()ring ()

ring ()

Sirene

ring ()

alarm 0..1

FlashLight

ring ()

0..1 orig

ähnlich wie Decorator

aber kein Zusatzeffekt

sondern remote, lazy oder cache Effekte

Proxy:

Struktur

Verhalten Daten

? :House

:Sirene

:MailAlarm

Adapter

ähnlich wie Decorator

aber Schnittstellenanpassung

Adapter:

Struktur

Verhalten Daten

? :House

:Sirene

:MailAlarm

Hausaufgabe:

Baut das Hausbeispiel mit einem (Objekt) Adapter für einen Mail-Alarm

Flyweight

Struktur

Verhalten Daten

Flyweight

Struktur

Verhalten Daten

Struktur

Verhalten Daten

Command

Struktur

Verhalten Daten

Command

Struktur

Verhalten Daten

Hausaufgabe: Command

Erstellt eine einfache GUI mit einem Fußball Icon auf einer Malfläche

Darunter 4 Knöpfe um den Ball jeweils 1 cm in jede Himmelsrichtung zu bewegen

Darunter ein Undo und ein Redo Knopf

Mit Command Pattern implementieren

Test: 10 mal bewegen, 5 Undo wieder an Pos 5, 2 Redo wieder an Pos 7, 7 Undo wieder an Pos 1

Sonderpunkte für Dragging

Factory Method:

Struktur

Verhalten Daten

Prototype:

Struktur

Verhalten Daten

Komplexer Prototyp

Abstract Factory:

Struktur

Verhalten Daten

Hausaufgabe:

Abstrakte Fabrik für Autos und Garagen

Konfiguration für rote Spielzeugautos und Minigaragen

Konfiguration für blaue Nutzfahrzeuge und Flugzeughallen

vielleicht mal Spielzeugauto mit LKW-Motor und Hundehütte

Facade:

Struktur

Verhalten Daten

Import Umkehrung:

Struktur

Verhalten Daten

Import Umkehrung:

Struktur

Verhalten Daten

Plugins:

Struktur

Verhalten Daten

Daten Plugin:

Struktur

Verhalten Daten

Hausaufgabe:

Baut ein Rahmenwerk, das einfach ein Fenster aufmacht

Baut ein Plugin, das in das Rahmenwerkfenster einen Button und ein Label einhängt, bei jedem Button Click soll das Label eins hoch gezählt werden.

Das Rahmenwerk bekommt eine Liste der zu ladenden Plugins als Aufrufparameter.

Achtung: das Rahmenwerk darf KEINE Compilezeitabhängigkeiten zu den Plugins haben

Reuse Architekturen:

Bibliotheken

Frameworks

Product Line Architecture

Components & Connectors Architekturen

Wiederverwendung von "Komponenten"

"Konnektoren" zur Verknüpfung und Anpassung von Komponenten

Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

Documents