Transcript OOMPA 2000 Föreläsning 7 Designmönster Innehåll Återanvändning Designmönster Problem Bakgrund Lösning Exempel Sammanfattning och slutsatser previous next Designmönster Återanvändning • I alla tider har man försökt att återanvända och applicera känd kunskap och metoder på nya.

OOMPA 2000
Föreläsning 7
Designmönster
Innehåll
Återanvändning
Designmönster
Problem
Bakgrund
Lösning
Exempel
Sammanfattning och slutsatser
previous
next
Designmönster
Återanvändning
• I alla tider har man försökt att återanvända och applicera
känd kunskap och metoder på nya domäner
– Till stora delar lär vi genom att härma och efterlikna
• Vad kan återanvändas och hur?
• Varför återanvända?
• Varför är det svårt att återanvända?
previous
next
2
Designmönster
...
• Vad kan återanvändas och hur?
– Arkitektur, tex frameworks
– Kod, tex komponenter
– Design, tex lösningstekniker
– Dokumentation, tex delar av manualer
– Test, bla vissa standardtester
– Metodiker, tex arbetssätt och organisation
previous
next
3
Designmönster
...
• Varför återanvända?
– Vi spar tid
– Mer tillförlitliga och uttestade produkter
– Kortare tid från idé till produkt
– Utvecklare kan koncentrera sig mer på modulär design, vilket
förenklar underhåll och liknande
– Utvecklare behöver spendera mindre tid på rutinarbete och
kan fundera mer på övergripande design, kundkrav, osv
previous
next
4
Designmönster
...
• Varför är det svårt att återanvända?
– Svårt att hitta i allt större bibliotek av komponenter
(/lösningar) samt förstå hur en viss komponent skall kunna
användas
– Inte alltid helt klart vad en viss komponent eller modul gör
– Inte säkert att en viss komponent (eller lösning) direkt går att
applicera i den aktuella situationen. Smärre ändringar kan
krävas
– NIH-syndromet (Not Invented Here). Kan vi lita på någon
annans komponent (/lösning). Ska vi inte göra det själva...
previous
next
5
Designmönster
Design Patterns: Problem
• Hur kan vi dokumentera designlösningar på ett så lättillgängligt
och överskådligt sätt som möjligt?
• Hur kan vi återanvända tidigare gjorda lösningar och
konstruktioner?
• Hur kan experter dokumentera sina kunskaper på en form som är
tillgänglig även för folk utanför deras "kunskapsdomän"?
• Hur kan vi beskriva principer för en lösning istället för detaljer,
så att den blir så oberoende av den aktuella kontexten som
möjligt?
• Hur kan vi skapa en kraftfull vokabulär för våra designlösningar?
previous
next
6
Designmönster
Bakgrund och omgivning
• Som många andra komplexa strukturer skapas bra mjukvara ofta
genom att imitera program som löser liknande problem på ett bra
sätt (se tex [Ker] Kernighan, B. and Plauger, P.J. The Elements of
Programming Style)
• Vi behöver bra mekanismer att beskriva design- och
mjukvarulösningar
– Det går inte att beskriva övergripande, generella, lösningar på ett
formalistiskt sätt
• Det finns också ett behov av att sätta namn på konstruktioner så
att vi får ett kraftfullare språk då vi diskuterar design
previous
next
7
Designmönster
Krafter
• Vi önskar ett begripligt och lättillgängligt språk som är enkelt att
lära sig.
• Vi önskar namnge designlösningar så att vi får ett kraftfullt språk
att diskutera olika möjligheter och konstruktioner.
• Beskrivningarna måste vara så pass kraftfulla att vi kan uttrycka
det vi vill.
• Vi önskar lösningar som går att applicera på olika situationer.
• Det skall vara möjligt att läsa delar av en beskrivning för att
snabbt avgöra om den är av intresse i den aktuella situationen.
• Vi vill ge den som beskriver en design frihet att anpassa
beskrivningen till dom aktuella (specifika) behoven.
• Det skall vara roligt att både läsa och skriva beskrivningar.
previous
next
8
Designmönster
Lösning
• Beskriv en lösning på en standardiserad form
• Utgå från en mall med följande rubriker:
Namn
ett så förklarande namn som möjligt
Problem
formulering av det problem som mönstret avser att lösa
Kontext
den omgivning med påverkande krafter i vilken mönstret skall verka
Lösning
en beskrivning av den design som löser problemet
• Fler rubriker kan användas vid behov
• Detta gör beskrivningen lättillgänglig och standardiserad (samt
igenkännbar)
• Den som läser kan läsa en delbeskrivning för att snabbt undersöka
den aktuella designens avsikt och tillämpbarhet
previous
next
9
Designmönster
Exempel (kort-kort för att få plats på en sida)
Namn
Konstruera ett stort datorsystem (enligt traditionell metodik a la RUP)
Problem
Hur bör vi gå tillväga då vi konstruerar ett stort datorsystem med många
inblandade utvecklare?
Kontext
Överensstämmelse med krav. Oberoende av nyckelpersoner. Spårbarhet.
Anpassat för förändring. Dokumentation som kan valideras mot kund.
Lösning
1. Börja med att utgående från kravspecifikationen identifiera aktörer, upprätta
användningsfall samt beskriva dem i textuell form (scenarier)
2. Analysera systemet. Återgå vid behov till 1 och komplettera användningsfallen.
3. Designa systemet. Återgå vid behov till 2 (och därmed kanske till 1).
4. Konstruera systemet.
5. Testa systemet. Iterera 1-5 tills systemet är klart.
previous
next
10
Designmönster
Konsekvenser
 Vi kan dokumentera designlösningar på ett lättillgängligt och överskådligt sätt.
 Vi kan återanvända tidigare gjorda lösningar och konstruktioner.
 Experter kan dokumentera sina kunskaper på en form som är tillgänglig även
för folk utanför deras "kunskapsdomän”.
 Vi beskriver principer för en lösning istället för detaljer.
 Vi skapar en kraftfull vokabulär så att vi enkelt kan diskutera olika lösningar.
 Risk att vi inte kritiskt granskar alla delar i en design, utan litar på att allt är
frid och fröjd bara ett designmönster används.
 Att många olika beskrivningar av egentligen synonyma mönster börjar florera
(vilket kan skapa förvirring).
 Friheten att justera mönsterbeskrivningarna efter aktuella behov gör dom
anpassningsbara. Men samtidigt ökar risken att många format florerar, viken
kan göra det en aning svårare att tränga in i en viss beskrivning
previous
next
11
Historik
Designmönster
• Bakgrund
– Under 60-talet utvecklades automatiserad och datoriserad
konstruktion av byggnader
• arkitekter försökte rationalisera
• man försökte separera design från produktion
• detta hade stora fördelar gentemot traditionell "omedveten" design
• Christopher Alexander (idag professor i Arkitektur på Berkely)
– Ändå noterade många att traditionellt konstruerade "saker" var
bättre i fråga om kvalitet, användbarhet och anpassbarhet
• Arkitekten Christopher Alexander försökte fånga varför och vad som var
mer tilltalande i vissa byggnader än andra
• han fann vissa återkommande teman
• han konstruerade ett systematiskt sätt att dokumentera dessa mönster:
designmönster (eng. design patterns)
previous
next
12
... Alexander ...
Designmönster
– Som Alexander utrycker det i boken "A Pattern Language" (som består av 253
mönster som beskriver allt ifrån hur gatunätet i städer bör utformas till hur
rum bör inredas för att bli trivsamma, plus mycket mycket mer)
"Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that
problem, in such a way that you can use this solution a million times over,
without ever doing it the same twice"
Christopher Alexander 1977
• Beck & Cunningham (samma par som också ligger bakom CRC-kort)
– Började i mitten av 80-talet använda designmönster för att lära ut
objektorientering och Smalltalkprogrammering
• Även andra forskare inom datalogi diskuterade designmönster och
relaterade till Alexander redan på 80-talet
previous
next
13
Designmönster
... MVC (Model-View-Controller) ...
• En av dom största inspirationskällorna och ett exempel på
ett mycket framgångsrikt mönster är MVC
– Idén är att separera applikationslogik (model) från
visualiseringen (view) och interaktionen (controller) med
densamma
– Konstruerades under andra hälften av 70-talet då en
interaktionsmodell och ett framework för konstruktion av
interaktiva användargränssnitt i Smalltalk skapades
Applikationslogiken
M
Presenterar
V
previous
next
Interagerar
C
14
Designmönster
...
• MVC är i sig själv en design som (tidigt) använde många
idag mer eller mindre omistliga designmönster som:
– Template method, Observer och Factory method
Men också lite mer indirekt mönster som:
– Strategy, Composite och Decorator
• MVC:s framgång, både i Smalltalk och på andra håll, har
inspirerat många till att tränga djupare in i och utforska
framgångsrika designlösningar
previous
next
15
Designmönster
… Historik ...
• Gang of Four
– Fyra erkända forskare inom datalogi och objektorientering.
– Skrev den klassiska "Design Patterns Elements of Reusable Software".
• Konferenser och liknande
– Mängder av årliga konferenser, workshops, diskussionsgrupper och
elektroniska möten.
– Vanligt med rapporter som antingen behandlar designmönster eller är skriven
på en "designmönsterform" även på konferenser som inte explicit är
dedicerade för ämnet.
• UML
– UML har tagit upp designmönster som en del av modelleringen.
– Designmönstren har å sin sida länge använt notationer liknande UML för att i
mer detalj beskriva lösningar.
previous
next
16
Designmönster
Exempel-1 Alexander: 136 A Couple's Realm*
previous
next
17
Designmönster
…
previous
next
18
Designmönster
...
previous
next
19
Designmönster
Exempel-2 Alexander: 21 Four-Story Limit**
• Separata OH-bilder
previous
next
20
Designmönster
Från Arkitektur till Programvara
• Mjukvarukonstruktörer har under framförallt 90-talet
funnit likheter mellan Alexanders mönster i
arkitektursammanhang och mönster i mjukvara.
• Problemet med att återanvända konstruktioner och
komponenter har länge diskuterats och eftersträvats i
mjukvaruindustrin.
– Man har tex diskuterat legometaforen
– Trott att objektorientering per automatik skulle vara lösningen
– osv, osv
• Ett centralt problem inom datalogin är att fånga
övergripande designlösningar och inte "bara" beskriva
algoritmer för vissa specifika problem.
previous
next
21
Designmönster
Varför designmönster?
1. Dom erbjuder expertkunskap
2. Dom ger oss en kraftfull vokabulär
3. Vi förstår programsystem snabbare om dom är dokumenterade
med designmönster
4. Dom förenklar omstrukturering av system (underhåll)
previous
next
22
Designmönster
...
"A design pattern simply captures the salient characteristics of a
solution to a problem that has been observed to occur repeatedly in
many different problem domains"
(Budd 1997)
"A design pattern provides a scheme for refining the subsystems or
components of a software system, or the relationships between
them. It describes a commonly recurring structure of
communicating components that solves a general design problem
within a particular context"
(Gamma & co 1995)
previous
next
23
Designmönster
När kan designmönster användas?
• Analysera design
– Ett schema för att göra olika typer av analyser av en viss lösning
• Dokumentera
– På olika nivåer och med olika metoder samtidigt
• Kommunicera
– Kraftfullt språk
– Tekniker och lösningar kan kommuniceras på en hög nivå
• Generalisera och jämföra
– Hitta kärnan i problemen och ge en allmän beskrivning
• Kunskapsbas
– Samlingar med designmönster är en förträfflig lättåtkomlig bas av olika
tekniker. Varje utvecklare bör ha åtminstone en översiktlig kännedom om
dom grundläggande mönstren.
previous
next
24
Designmönster
Formen för ett designmönster
• Det finns flera olika mallar för att skriva designmönster:
– En välkänd är Gang of Four:s
• Denna mall anses idag vara lite utkänt och för omfattande
• Idag försöker man skriva designmönster utgående från följande
delar:
– Titel
Ett förklarande namn, som anger vem mönstret är.
– Problem
Vad mönstret avser att lösa.
– Kontext
Krafter och begränsande faktorer som demonstrerar varför problemet är
svårt att lösa.
– Lösning
Hur löser man problemet i den givna kontexten.
previous
next
25
Designmönster
... mall forts
• En utmärkt beskrivning av hur s.k. Pattern Languages, dvs system av
sammanhängande mönster, skrivs finns i "A Pattern Language for
Pattern Writing" [Mes]
– Där diskuteras hur man i olika situationer och för olika syften kan använda
olika rubriker med vidhängande beskrivningar
– Beroende av den aktuella situationen behöver inte alla delar i mallen ha en
lika framträdande roll, eller överhuvudtaget diskuteras i beskrivningen.
– Som framgår av namnet på beskrivningen behandlar den Pattern Languages,
dvs sätt att bryta ner ett större problem på mindre relaterade designmönster
previous
next
26
Designmönster
Exempel: The Null Object Pattern (med anpassad mall)
Namn
Ett minimalt konkret exempel
Null Object (mönstret delvis efter Bruce Anderson, IBM Essex England)
Avsikt
Eliminera villkorsatser då ett objekt inte har något värde (Tex
om
ett objekt är null i Java eller nil i Smalltalk)
Problem
– ibland behöver vi testa om ett objekt antar ett värde innan vi
skickar ett meddelande till det
– detta ger ofta ful och oflexibel kod
– Hur kan vi eliminera tester i klientkoden och därmed få mer
flexibel kod och mindre beroende mellan olika kodavsnitt?
previous
next
27
Designmönster
... forts
Exempel
Ex-a) i ett telefonsamtal som började som ett trepartssamtal kan
den uppringande redan ha kopplat ner då dom andra kopplar
ner
Vi måste alltså i koden testa
för detta fall
if(thisCall.callingParty != null)
thisCall.callingParty.close(); (kanske på massor av ställen)
Ex-b) i ett system för löneutbetalning har vi ingen information
om en viss persons lön en viss dag
Float salaryOn(Date aDate){
PersonInfo info = this.infoOn(aDate);
return (info == null) ? null : info.salary();
}
previous
next
28
Designmönster
...Lösning...
– Konstruera ett objekt som motsvarar ett null-värde i den
aktuella kontexten, dvs med lämpligt protokoll och som
"eliminerar" beteendet för metoder där "inget" skall ske
Ex-a) konstruera klassen NullPhone med metoden
void close(){/* do nothing */}
Vid nedkoppling ersätts en Phone med en NullPhone
medför att vi direkt kan utföra
thisCall.callingParty.close();
dvs vi eliminerar testet!
(samtidigt som det blir enkelt att ändra beteendet genom att tex byta klass.
Kanske vill vi ha en tracutskrift eller liknande...)
previous
next
29
Designmönster
... lösning forts ...
Ex-b) konstruera klassen MissingInformation med följande
beskrivning av metoden salary
Float salary(){return null;}
medför att vi direkt kan utföra
Float salaryOn(Date aDate)
{return this.infoOn(aDate).salary;}
– Så länge som vi inte har information om lön så skall en instans av
MissingInformation returneras.
• Antingen genom att varje person initieras med denna klass eller att
inspektorn för lönen returnerar en sådan instans om inte informationen
existerar
previous
next
30
Designmönster
... forts
Implementation
– Typiskt med gemensam
abstrakt superklass
AbstractPhone
NullPhone
Null Object
Phone
AbstractInfo
MissingInformation
Information
– Kan också implementeras mha mönstren State eller Strategy
previous
next
31
Designmönster
... Exempel forts
Konsekvenser
•
•
•
•
Ger flexibel struktur. Mer objektorienterad lösning än med villkor.
Inkapslingen ökar och beroendet mellan komponenter minskar.
Bra vid avlusning.
Vi flyttar bort ansvar från "klienter" till "servrar"
Relaterade mönster
– Mönstren State och Strategy , se [GOF]
Känd användning
– I Model-View-Controller använder en passiv vy (utan interaktion) en
instans av NoController med följande metod som anger om objektet
vill "ta över"
boolean isControlWanted(){return false;}
– I VisualAge Smalltalk används mönstret i asNullDragMode och
NullInputManager
previous
next
32
Designmönster
En not om designmönstren i denna beskrivning
• Av nödvändighet så är beskrivningarna och exemplen som
följer i denna beskrivning kraftigt förkortade i förhållande
till fullständiga designmönsterbeskrivningar.
• Den som är intresserad av fullständiga beskrivningar kan
gärna konsultera någon av referenserna som du hittar i
slutet av dessa anteckningar.
previous
next
33
Designmönster
Exempel: Template Method
Kontext
Vi har en mogen och komplex objektorienterad omgivning till vilken
programmerare kan lägga till egna klasser.
Problem
Hur kan vi beskriva så mycket som möjligt av en algoritm i en superklass och
endast spara konkreta detaljer till subklasser?
Krafter
– Enkelhet, det skall vara enkelt att använda och förändra detaljer i dom
konkreta klasserna.
– Effektivitet, koden skall vara effektiv och det skall vara enkelt att optimera
detaljer
– Koppling och kohesion, beroendet mellan olika programdelar skall vara litet
och sammanhållningen inom en programdel skall vara stor.
– Sammansättningar skall kunna kan ändras under exekveringen.
previous
next
34
Designmönster
... template method
Lösning
Konstruera klasser som beskriver abstrakt beteende. Det skall finnas tydliga
punkter i vilket konkreta klasser kan beskriva konkret beteende.
Superklass
templateMethod()
methodX()
methodY()
Subklass
methodX()
methodY()
previous
next
return methodX() + methodY();
return 
return 
35
Designmönster
...
Exempel
• Används i OO frameworks som Smalltalk-80 och Jawa AWT
• Model-View-Controller i vilken konkreta användarklasser skriver över
detaljer definierade i existerande superklasser
Konsekvenser
+ Effektiv och snabb implementation
+ Enkelt och rättfram
– Koppling som beror av arv som ger ett beroende mellan super och
subklasser
– Jo-jo-problemet
Relaterade mönster
– Factory Method implementeras ofta med Template Method.
– Strategy: Template Method använder arv för att variera en del av en
algoritm medan Strategy använder delegering för att byta ut en hel
algoritm.
previous
next
36
Designmönster
Exempel: Composite
Problem
Hur kan vi skapa komplexa objekt som består av andra objekt
men ändå behandla dem uniformt?
Krafter
– Sammansatta objekt skall se ut och bete sig som icke sammansatta objekt.
– Objekt skall kunna nästlas på godtyckligt sätt i varandra.
Lösning
Component
Leaf1
previous
next
Leaf2
*
Composite
37
Designmönster
… Composite
Exempel
Shape
Rectangle
Graphic
Line
previous
Rect
next
Text
Ellipse
*
Picture
1..*
Group
Command 1..*
Macro
38
Designmönster
Kort-korta exempel
Namn: Adapter
Problem
Hur kan vi använda ett objekt (server) som erbjuder lämplig
funktionalitet men har ett annat gränssnitt än vad vi önskar?
Kontext
Vi kan inte ändra serverobjektet och av olika skäl måste det objekt som
vi själva konstruerar ha ett visst gränssnitt.
Lösning
Konstruera en adapter-klass som översätter metoder hos ett server-objekt
så att det passar klient-objektet.
:klient
1:m
4:r
:adapter
2:m'
3:r'
:server
Exempel
I Java bla Boolean och Integer som anpassar boolean och int. I GUI för
att koppla grafiska komponenter till modeller.
previous
next
39
Designmönster
...kort-korta exempel...
Namn: Strategy
Problem
Hur kan vi göra en algoritm som löser ett visst problem utbytbar så att den enkelt
och dynamiskt kan ersättas av en annan?
Kontext
Vi vill undvika att göra flera parallella komplexa algoritmer i ett visst objekt.
Lösning
Objektifiera algoritmerna genom att definiera dem mha en grupp av klasser med
gemensamt gränssnitt. Varje klass definierar en speciell strategi för att lösa det
aktuella problemet.
Context strategy
AbstractStrategy
Exempel
StrategyA
StrategyB
StrategyC
I Java används olika layoutmanagers,
implementerade som olika strategier. I gränssnitt kan inmatning i inmatningsfält
hanteras genom olika strategier för olika typer av data.
previous
next
40
Designmönster
...kommandotolk i meddelandesystem (ett exempel till)
• Jag har med fördel använt Strategy i bla distribuerade system och system för att
generera komponenter av olika format
• Nyligen designade jag ett meddelandesystem baserat på TCP/IP och socketar
där jag använde Strategy
– Jag konstruerade en kommandohanterare som beroende av första ordet i
överskickat data (kommandot) valde "strategi", dvs aktiverade ett objekt som tog
över resten av tolkningen av indata och sedermera eventuell exekvering på servern
• Var kommandot ej igenkännbart så använde jag först ett NullObject, vilket vid behov
(enkelt) ersattes med ett mer sofistikerat felhanteringsobjekt.
• Dess lösningar har givit mycket objektorienterad, flexibel och lättunderhållen
struktur (med avseende på tex förändringsbarhet för att möta nya eller ändrade
krav)
• Vidare har det varit enkelt att bygga systemen baserat på kunskapen att
Strategy är ett bra mönster i dom givna situationerna
previous
next
41
Designmönster
Hur hittas eller används mönster?
• Via konventionell analys
• Sök efter dokumenterade mönster
• Sök efter mönster som med små modifieringar skulle lösa
problemet
• Försök att kombinera olika mönster
• som sista utväg: konstruera nya mönster
previous
next
42
Designmönster
Hur omfattande är ett designmönster?
• Typiskt är ett designmönster ca 10 sidor långt
• Idag är trenden att mer komplicerade beskrivningar görs
med Pattern Languages som består av ett flertal
sammanhängande designmönster plus en inledande
beskrivning samt en avslutande sammanfattning
– I dessa fall är varje enskilt mönster typiskt beskrivet med 1-2
sidor text med inledning och sammanfattning av samma
omfattning
• I både den enskilda designmönsterbeskrivningen och
pattern language beskrivningen är en av poängerna att
man ofta bara behöver läsa en eller par underrubriker för
att förstå vad det går ut på och inte förrän man behöver
alla detaljer behöver läsa resten.
previous
next
43
Designmönster
Exempel: Observer
Problem
Hur kan vi konstruera en mekanism som tillåter att
vissa objekt meddelas om någon vital del förändras i
andra objekt utan att objekten görs starkt knutna till
varandra?
Kontext
– Vi vill undvika stark koppling och beroende mellan objekten
– Intresserade objekt skall informeras om något förändras.
Lösning
Upprätthåll en lista av objekt som är beroende av ett visst objekt.
Om objektet förändras skall dom beroende objekten meddelas.
Dom beroende objekten skall vart och en själva avgöra hur dom
skall reagera på förändringen.
previous
next
44
Designmönster
...
Subject
attach(Observer)
detach(Observer)
notify()
previous
next
observers
for all o in observers
{
o.update();
}
*
Observer
update()
45
…ett sekvensdiagram som visar ett typiskt
scenario
:subject
o1:observer
o2:observer
o3:observer
Designmönster
:object
attach(o1)
attach(o2)
attach(o3)
notify()
update()
update()
update()
detach(o3)
notify()
update()
update()
previous
next
46
Designmönster
…Javalösning: observer...
Javalösning med Observer och Observable.
I Java kan ett objekt som vill vara beroende av ett annat objekt implementera
gränssnittet Observer medan det objekt som observeras görs till subklass
till klassen Observable (eller möjligen använder ett fält som är subklass till
denna typ).
• Gränssnittet Observer:
package java.util;
public interface Observer {
void update(Observable o, Object arg);
}
previous
next
47
Designmönster
… klassen Observable ...
package java.util;
public class Observable {
private boolean changed = false;
private Vector obs;
private Observer[] arr = new Observer[2];
public Observable() {obs = new Vector();}
public synchronized void addObserver(Observer o) {
if (!obs.contains(o)) {obs.addElement(o);}
}
Lägg till
observer
public synchronized void deleteObserver(Observer o) {
obs.removeElement(o);
}
Ta bort
observer
previous
next
48
Designmönster
… Observable forts...
public void notifyObservers() {notifyObservers(null);}
Metoder för
att meddela
att objektet
ändrats
Meddelandet
update(…)
skickas till
alla observers
previous
next
public void notifyObservers(Object arg) {
int size=0;
Om vi inte anger
synchronized (this) {
argument så läggs null
if (!hasChanged()) return;
på som argument
size = obs.size();
if (size > arr.length) {
arr = new Observer[size];
}
obs.copyInto(arr);
clearChanged();
}
Från vem
for (int i = size -1; i>=0; i--) {
if (arr[i] != null) {
Argument till
arr[i].update(this, arg);
uppdateringen
}
}
}
49
Designmönster
… klassen Observable forts ...
public synchronized void deleteObservers() {
obs.removeAllElements();
}
Sätt eller ta bort
changed-flagga
protected synchronized void setChanged(){
changed = true;
}
protected synchronized void clearChanged(){
changed = false;
}
public synchronized boolean hasChanged() {
return changed;
}
public synchronized int countObservers(){
return obs.size();
}
}
previous
next
50
Designmönster
… observer ...
Exempel: MessageBoard och beroende studenter
Subklassa Observable
import java.util.*;
class MessageBoard extends Observable {
private String message;
public String getMessage(){
return message;
}
Vi sparar undan argumentet
(om tex något beroende
objekt vill läsa av det)
public void changeMessage(String aMessage){
message = aMessage;
Vi indikerar att
this.setChanged();
objektet ändrats
this.notifyObservers(message);
}
Vi meddelar beroende objekt,
}
previous
next
med message som argument
51
Designmönster
… observer: exempel ...
Implementera gränssnittet
import DB.*;
Observer
import java.util.*;
class Student extends DB.Student implements Observer {
public void update(Observable o , Object arg){
System.out.println(this.christianName() +
" tar emot meddelande: " + arg);
}
I update(…)
definierar vi vad
som skall göras
då objektet
får reda på att ett
objekt som det är
beroende av
ändrats
public Student(String christianName,
String familyName, String pnr,
String programme, String email) {
super(christianName, familyName,
pnr, programme, email);
}
}
previous
next
52
Designmönster
… observer: exempel ...
public class TestObserver {
public static void main(String [] args)
{
MessageBoard board = new MessageBoard();
Student pers1 = new Student("Kalle", "Person", "133",
"D99", "[email protected]");
pers1.addCourse("OOMPA00");
Gör pers1 beroende av board
pers1.addCourse("COOKING00");
board.addObserver(pers1);
board.changeMessage("Ny person: " +
pers1.christianName());
Meddela att board ändrats
/* Utskriften blir
Kalle tar emot meddelande: Ny person: Kalle
*/
previous
next
53
Designmönster
… observer: exempel ...
Student pers2 = new Student("Olle", "Olsson", "113",
"D96", "[email protected]");
pers2.addCourse("OOMPA00");
Gör pers2 beroende av board
pers2.addCourse("ENGLISH-1");
board.addObserver(pers2);
board.changeMessage("Ny person: " +
pers2.christianName());
Meddela att board ändrats
/* Utskriften blir
Olle tar emot meddelande: Ny person: Olle
Kalle tar emot meddelande: Ny person: Olle
*/
previous
next
54
Designmönster
… observer: exempel
Student pers3 = new Student("Lotta", "Ason",
"123", "F98", "[email protected]");
pers3.addCourse("OOMPA00");
pers3.addCourse("GRIP2001");
board.addObserver(pers3);
board.changeMessage("Ny person: " +
pers3.christianName());
/* Utskriften blir
Lotta tar emot meddelande: Ny person: Lotta
Olle tar emot meddelande: Ny person: Lotta
Kalle tar emot meddelande: Ny person: Lotta
*/
}
}
previous
next
55
Designmönster
… observer-exemplet i Smalltalk
DB.Student subclass: #Student
Object subclass: #MessageBoard
instanceVariableNames: 'message'
update: anAspectSymbol with: arg
Transcript
show: self christianName,
' tar emot meddelande: ',
arg
getMessage
^message
changeMessage: msg
message := msg.
self changed: #newMessage
with: message
board := MessageBoard new.
pers1 := Student chName: 'Kalle’ fname: 'Person’ socNo: '133’
status: 'd00’ email: '[email protected]'.
board addDependent: pers1.
board changeMessage: 'Ny person: ', pers1 christianName
“OSV…”
previous
next
56
Designmönster
... Observerexemplet i UML
I UML skulle exemplet se ut något i stil med
MessageBoard
Subject
Subject
Observer
Observer
Student
previous
next
Observer
57
Designmönster
Kort-korta exempel: Abstract Factory
Problem
Hur kan vi erbjuda mekanismer för att skapa familjer av relaterade objekt utan
specificera deras konkreta klasser?
Lösning
Konstruera en abstrakt fabrik som ansvarar för att returnera en konkret fabrik som
beror av kontext. Den konkreta fabriken konstruerar
sedan konkreta produkter i aktuell kontext.
Client
AbstractProductA
AbstractFactory
ProductA2
ProductA1
AbstractProductB
ConcreteFactory1 ConcreteFactory2
ProductB2
ProductB1
Exempel
I InterViews, ET++ och VisualWorks används tekniken för att anpassa systemet
till aktuell plattform genom att en speciell gränssnittsfabrik används per
plattformstyp.
previous
next
58
Designmönster
Exempel: State
Problem
Hur kan vi låta ett objekt ändra beteende beroende av sitt interna tillstånd så
att det verkar som om det ändrar klass?
Kontext
Vi vill isolera beskrivningar av beteende. Vi vill göra övergångar explicita.
Vi vill kunna dela på ”state”-objekt.
Lösning
Använd ett associerat objekt som implementerar aktuellt beteende.
Context
state
State
request()
handle()
state.handle()
ConcreteStateA
handle()
previous
next
ConcreteStateB
handle()
59
Designmönster
En lista med några kända mönster (ur [GOF])
• Abstract
Factory
• Flyweight
• Proxy
• Glue
• Singleton
• Adapter
• Interpreter
• State
• Bridge
• Iterator
• Strategy
• Builder
• Mediator
• Template Method
• Command
• Memento
• Visitor
• Composite
• Observer
• Wrapper
• Chain of
Responsibility
• Prototype
• Factory
Method
previous
next
60
Designmönster
Till vad används designmönster?
• Arkitektur
• Beskriva metoder och designlösningar i mjukvara
(framförallt i samband med objektorientering)
• Processer
–
–
–
–
Hur skriver jag en rapport?
Hur genomförs en Writer's Workshop?
Hur leder jag projekt?
osv
• Analys och design
• Systemdesign
previous
next
61
Designmönster
Organisation av mönster
• Man kan dela in mönster efter typ som
–
–
–
–
–
Design Patterns
Pattern Language
Catalogue
Idiom
Architectural
• I UML skiljer man på
– Mechanisms
• ett annat ord för design patterns
– Frameworks
• ett arkitektoriskt mönster
previous
next
62
Designmönster
... man kan också dela in designpatterns på följande sätt
Purpose
previous
Creational
Structural
Behavioural
Class
Factory Method
Adapter
Interpreter
Template Method
Object
Abstract Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Glue
Proxy
Chain of responsibility
Command
Iterator
Mediator
Memento
Publisher-Subscriber
State
Strategy
Visitor
next
63
Designmönster
Vart är mönstren på väg?
• Används i allt fler projekt, både akademiska och industriella.
• Det finns många designmönstergrupper över hela världen, bla en
på KTH.
• Klassbibliotek utformas med influenser från designmönster.
• Många konferenser, massor av böcker och flera tidskrifter.
• Någon har tom sagt att design patterns är svaret på vad som
kommer efter objektorientering. Men …
• Alexander jobbar vidare och utvecklar nya idéer (fast det är inte
säkert att detta påverkar grenen som sysslar med mjukvara)
previous
next
64
Designmönster
Slutsatser
Hjälper design patterns någon?
Ja, dom
1. fångar expertkunskap på ett lättillgängligt sätt
2. ger oss namn på designlösningar, vilket ger oss en kraftfull
vokabulär då vi diskuterar design och implementation
3. hjälper oss att förstå system snabbare
4. förenklar omstrukturering av system.
Vidare har dom medfört att lättillgängliga kataloger med
designlösningar skapats
previous
next
65
Designmönster
Referenser
[Al64] Alexander, C. Notes on the Synthesis of Form, Cambridge: Harvard University
Press, 1964.
[Al77] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I.,
and Angel, S. A Pattern Language, Oxford University Press, 1977.
[Al79] Alexander, C. The Timeless Way of Building, Oxford University Press, 1979.
[GOF] Gamma et al Design Patterns Elements of Reusable Software 1995
[Ker] Kernighan, B. and Plauger, P.J. The Elements of Programming Style, 2nd
edition, McGraw-Hill, 1978
[Kra] Krasner, G.E. and Pope, S.T. Cookbook for using the Model-View-Controller
User Interface Paradigm, JOOP, August 1988, pp. 26-49.
[Mes] Meszaros & Doble A Pattern Language for Pattern Writing
http://st-www.cs.uiuc.edu/users/patterns/Writing/pattern_index.html
Design Patterns hemsida
http://st-www.cs.uiuc.edu/users/patterns/
med länkar till massor av information
previous
next
66