Kein Folientitel

Motivation Entwurfsmuster
• Entwurf wiederverwendbarer objektorientierter
Software schwer
• gute Entwürfe entstehen durch Wiederverwendung erfolgreicher Lösungen (Entwurfsmuster)
– somit in oo Systemen oft wiederkehrende Muster
von Klassen und kommunizierenden Objekten
– Entwickler kann Muster auf vorliegende Probleme
anwenden, ohne Lösung erneut zu suchen
– Muster lösen spezifische Entwurfsprobleme
– Muster machen Entwürfe flexibler, eleganter,
wiederverwendbar
Design Pattern
1
Entwurfsmuster
• Entwurfserfahrungen als Entwurfsmuster
aufgezeichnet (Musterkatalog)
– durch verständliche Darstellung gut nutzbar
– erleichtern Wahl von Entwurfsalternativen
– können Dokumentation + Wartung existierender
Systeme erleichtern
– ermöglichen Entwurf schneller „richtig“ zu machen
• Entwurfsmuster (C. Alexander):
– beschreibt beständig wiederkehrendes Problem
– erläutert Kern der Lösung für Problem
– somit: Lösung beliebig oft, aber nicht jedesmal
gleich, ausführbar
Design Pattern
2
Entwurfsmuster
• Entwurfmuster sind Muster bestimmter Abstraktionsebene
– Zusammenarbeit Objekte + Klassen zur Lösung
von Entwurfsproblemen in bestimmtem Kontext
• Benennen, Abstrahieren, Identifizieren relevanter
Aspekte einer allgemeinen Entwurfsstruktur
– Klassen, Objekte, ihre Rollen + Aufgaben +
Interaktionen zwischen Rollen identifiziert
– Entwurfsmuster für je ein bestimmtes Entwurfsproblem: wann einsetzbar + Konsequenzen
Design Pattern
3
Beschreibung von Mustern (I)
(Musterbeschreibung nach Gamma)
• Mustername:
– kurzes Stichwort, um Problem + Lösung zu
erläutern
– hilft bei Kommunikation im Team + Dokumentation
• Problemabschnitt
– beschreibt, wann Muster anzuwenden ist (Zweck,
Motivation, Anwendbarkeit)
Design Pattern
4
Beschreibung von Mustern (II)
• Lösungsabschnitt
– Elemente des Entwurfs, Beziehungen, Zuständigkeiten + Interaktionen (Struktur, Teilnehmer,
Interaktionen)
– kein bestimmter Entwurf, keine konkrete Implementierung, sondern auf viele Situationen
anwendbare Schablone (Elemente z.B. Klassen +
Objekte)
• Konsequenzabschnitt
– Konsequenzen der Musteranwendung (Vor- und
Nachteile) + bekannte Verwendungen
Design Pattern
5
MVC (Name, Problem)
• Name
– MVC: Model View Controller
• Motivation
– Erleichtert Entwurf und Wartung grafischer
Benutzerschnittstellen durch Modularisierung
– Model: Daten + Kernfunktionalität
– View: Präsentation Model
– Controller: Kontrollfluss (welche Aktion, welche
Logik, welche View)
Design Pattern
6
MVC (Problem)
– Views nicht zu verändern bei verändertem
Controller
– Model unabhängig von Veränderungen in View
und Controller
• Anwendbarkeit
– für grosse Anwendungen
– wenn klare Rollenverteilung nötig (Designer,
Programmierer)
– wenn starke Wiederverwendung angestrebt
Design Pattern
7
V
MVC (Lösung I)
M
C
Struktur:
View
Änderungen
Status erfragen
Model
Benutzeraktionen
Status ändern
View-Auswahl
Controller
Methodenaufrufe
Ereignisse
Design Pattern
8
MVC (Lösung II)
• Teilnehmer:
– Model, View, Controller
• Interaktionen
– Views leiten Benutzeraktionen an Controller
– Controller legt fest, wie Eingaben zu verarbeiten
(Befehle an Model schicken und View selektieren)
– Views können geänderte Werte des Models
abfragen
Design Pattern
9
MVC (Konsequenzen I)
• Konsequenzen
+ Gute Wiederverwendbarkeit
+ Mehrere Ansichten des selben Models möglich
+ Sichten und Controller sind austauschbar
+ Bessere Lesbarkeit  gute Rollenverteilung
+ Designer, Programmierer
+ Gute Skalierbarkeit und Erweiterbarkeit
– Erhöhte Komplexität
– Längere Planung
– Mehr Aufwand bei Implementierung
Design Pattern
10
MVC (Konsequenzen II)
• Bekannte Verwendungen
–
–
–
–
Smalltalk mit Benutzerschnittstellen Framework
MFC - Microsoft Foundation Classes
Swing
Web-Frameworks (Struts, Velocity, Tapestry)
Design Pattern
11
Beispiel im JSP-Umfeld
Bitte ausfüllen!
Login
muster
Passwort
******
Benutzeraktion: OK
Instanziieren der
Bean
Status ändern
prüfeEingabe()
C
Controller.java
View-Wahl Eingabe NOK
Passwort falsch!
Login
M
Instanziieren +
Status ändern
(setLogin(...)...)
OK
View1.jsp
V
View-Wahl Eingabe OK
Comicanwendung
login
passwort
setLogin(...)
...
View2.jsp
Bean.java
muster
Passwort
OK
View1.jsp
Status abfragen (getLogin())
Design Pattern
12
Quellen
• Wille, S., Go To Java Server Pages, Addison-Wesley,
München, 2001
• Gamma, E., Helm, R., Jonson, R., Vlissides, J.,
Entwurfsmuster, Addison-Wesley, Bonn, 1996
• Siemers, S.: MVC meets XML, Javamagazin, 03/2002,
S.24
• Turau, V. Saleck, K., Schmidt, M.: Java Server Pages und
J2EE: Unternehmensweite Web-Basierte Anwendungen,
dpunkt.verlag, Heidelberg 2001
• http://www.fhwedel.de/~si/seminare/ws97/Ausarbeitung/3.Krutscher/arc
hmu3.htm
Design Pattern
13