Varför designmönster?

2D1362: 2003 Designmönster 

previous 

next 

Innehåll 

Återanvändning 

Designmönster 

Problem 

Bakgrund 

Lösning 

Exempel 

Projektkursen 2003 


Sammanfattning och slutsatser 

Å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 

1


... 

• 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 

• 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 


2



... 

• 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... 



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? 


3


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 


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. 


4



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 



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. 


5


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 


Historik 

• 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) 


6


... Alexander ... 


– 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 



... 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 

M 

Presenterar Interagerar 

V C 

Applikationslogiken 


7


... 


• 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 


… 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. 


8



Exempel-1 Alexander: 136 A Couple's Realm* 


… 



9


... 



Exempel-2 Alexander: 21 Four-Story Limit** 

• Ett mönster som författarna klassar högt och därmed 

allmänngiltigt 

• Dvs bygg inte hus högre än fyra våningar höga 

• Varför..... osv 



10



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. 


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) 


11


... 


"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) 



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. 


12


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. 


... 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 


13



Exempel: The Null Object Pattern (med anpassad mall) 

Namn 

Ett 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? 


... 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 

if(thisCall.callingParty != null) för detta fall 

thisCall.callingParty.close(); 

Vi måste alltså i koden testa 

(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(); 

} 


14


...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...) 


... 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 


15


... forts 

Implementation 

– Typiskt med gemensam 

abstrakt superklass 

Null Object 

AbstractPhone 

NullPhone Phone 

AbstractInfo 

MissingInformation Information 

– Kan också implementeras mha mönstren State eller Strategy 



... 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 


16



En not om designmönstren i denna beskrivning 

• Av nödvändighet så är beskrivningarna och exemplen som 

följer på oh-bilderna 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. 


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. 


17


... 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() 

return methodX() + methodY(); 

return α; 

return β; 



... 

Exempel 

• Används i OO frameworks som Smalltalk-80 och Jawa AWT/Swing 

• 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. 


18


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 


… Composite 

Exempel 

Component 

Leaf1 Leaf2 

Shape 

Rectangle Ellipse 

Graphic 

Line Rect Text 

* 

Picture 

* 

Composite 

Group 



1..* 

Command 

Macro 

1..* 

19



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. 

1:m 2:m' 

:klient :adapter :server 

4:r 

3:r' 

Exempel 

I Java bla Boolean och Integer som anpassar boolean och int. I GUI för 

att koppla grafiska komponenter till modeller. 



...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 

StrategyA StrategyB StrategyC 

Exempel 

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. 


20



...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 



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 


21



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. 



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. 


22


... 

Subject 

attach(Observer) 

detach(Observer) 

notify() 

observers 

for all o in observers 

{ 

o.update(); 

} 



* 

Observer 

update() 

…ett sekvensdiagram som visar ett typiskt 

scenario 


:subject o1 :observer o2 :observer o3 :observer :object 

attach(o1) attach(o2) attach(o3) notify() 

update() 

update() 

update() 

notify() 

update() 

update() 

detach(o 3) 


23



Lägg till 

observer 

Ta bort 

observer 

…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); 

} 

… 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);} 

} 


public synchronized void deleteObserver(Observer o) { 

obs.removeElement(o); 

} 


24


Metoder för 

att meddela 

att objektet 

ändrats 

Meddelandet 

update(…) 

skickas till 

alla observers 

… Observable forts... 


public void notifyObservers() {notifyObservers(null);} 

public void notifyObservers(Object arg) { 

int size=0; 

} 

synchronized (this) { 

if (!hasChanged()) return; 

size = obs.size(); 

if (size > arr.length) { 

arr = new Observer[size]; 

} 

obs.copyInto(arr); 

clearChanged(); 

} 

for (int i = size -1; i>=0; i--) { 

if (arr[i] != null) { 

arr[i].update(this, arg); 

} 

} 

Om vi inte anger 

argument så läggs null 

på som argument 

Från vem 

Argument till 

uppdateringen 


Sätt eller ta bort 

changed-flagga 


… klassen Observable forts ... 

} 

public synchronized void deleteObservers() { 

obs.removeAllElements(); 

} 

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(); 

} 


25


… observer ... 

Exempel: MessageBoard och beroende studenter 

import java.util.*; 

class MessageBoard extends Observable { 

private String message; 

} 

public String getMessage(){ 

return message; 

} 

public void changeMessage(String aMessage){ 

} 

message = aMessage; 

this.setChanged(); 

this.notifyObservers(message); 



I update(…) 

definierar vi vad 

som skall göras 

då objektet 

får reda på att ett 

objekt som det är 

beroende av 

ändrats 

… observer: exempel ... 

import DB.*; 

import java.util.*; 

Subklassa Observable 

Vi sparar undan argumentet 

(om tex något beroende 

objekt vill läsa av det) 

Vi meddelar beroende objekt, 

med message som argument 

Implementera gränssnittet 

Observer 

Vi indikerar att 

objektet ändrats 


class Student extends DB.Student implements Observer { 

public void update(Observable o , Object arg){ 

System.out.println(this.christianName() + 

" tar emot meddelande: " + arg); 

} 

public Student(String christianName, 

String familyName, String pnr, 

String programme, String email) { 

super(christianName, familyName, 

pnr, programme, email); 

} 

} 


26




public class TestObserver { 

public static void main(String [] args) 

{ 

MessageBoard board = new MessageBoard(); 

Student pers1 = new Student("Kalle", "Person", "133", 

"D99", "d99-xxx@nada.kth.se"); 

pers1.addCourse("OOMPA00"); 

pers1.addCourse(“FOOD00"); 

Gör pers1 beroende av board 

board.addObserver(pers1); 

board.changeMessage("Ny person: " + 

pers1.christianName()); 

Meddela att board ändrats 

/* Utskriften blir 

Kalle tar emot meddelande: Ny person: Kalle 

*/ 




Student pers2 = new Student("Olle", "Olsson", "113", 

"D96", "olle@hagalund.se"); 


pers2.addCourse("ENGLISH-1"); Gör pers2 beroende av board 




Meddela att board ändrats 


Olle tar emot meddelande: Ny person: Olle 

Kalle tar emot meddelande: Ny person: Olle 

*/ 


27


… observer: exempel 

} 

Student pers3 = new Student("Lotta", "Ason", 

"123", "F98", "ff@home.se"); 


pers3.addCourse("GRIP2001"); 





Lotta tar emot meddelande: Ny person: Lotta 

Olle tar emot meddelande: Ny person: Lotta 

Kalle tar emot meddelande: Ny person: Lotta 

*/ 

} 



… observer-exemplet i Smalltalk 

DB.Student subclass: #Student 

update: anAspectSymbol with: with: arg arg 

Transcript 

show: show: self self christianName, 

' tar tar emot emot meddelande: ', ', 

arg arg 


Object Object subclass: subclass: #MessageBoard 

#MessageBoard 

instanceVariableNames: 'message' 

'message' 

getMessage 

getMessage 

^message ^message 

changeMessage: changeMessage: msg msg 

message message := := msg. msg. 

self self changed: changed: #newMessage 

#newMessage 

with: with: message message 

board board := := MessageBoard MessageBoard new. new. 

pers1 pers1 := := Student Student chName: chName: 'Kalle’ 'Kalle’ fname: fname: 'Person’ 'Person’ socNo: socNo: '133’ '133’ 

status: status: 'd00’ 'd00’ email: email: 'd00-kpe@nada.kth.se'. 

board board addDependent: addDependent: pers1. pers1. 

board board changeMessage: changeMessage: 'Ny 'Ny person: person: ', ', pers1 pers1 christianName 

christianName 

“OSV…” 

“OSV…” 


28


... Observerexemplet i UML 

I UML skulle exemplet se ut något i stil med 

MessageBoard 

Student 

Subject 

Observer 

Subject 

Observer 

Observer 



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 

ConcreteFactory1 ConcreteFactory2 

AbstractProductB 

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. 


29


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 

request() 

state.handle() 

state 

ConcreteStateA 

handle() 

State 

handle() 

ConcreteStateB 

handle() 


En lista med några kända mönster (ur [GOF]) 

• Abstract 

Factory 

• Adapter 

• Bridge 

• Builder 

• Command 

• Composite 

• Chain of 

Responsibility 

• Factory 

Method 

• Flyweight 

• Glue 

• Interpreter 

• Iterator 

• Mediator 

• Memento 

• Observer 

• Prototype 


• Proxy 

• Singleton 

• State 

• Strategy 

• Template Method 

• Visitor 

• Wrapper 


30


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 



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 



31



... man kan också dela in designpatterns på följande sätt 

Class 

Object 

Creational 

Purpose 

Structural Behavioural 

Factory Method Adapter Interpreter 

Template Method 

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 



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) 


32


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 


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://hillside.net/patterns/writing/patternwritingpaper.htm 

Design Patterns ”hemsida” 

http://hillside.net/patterns 

med länkar till massor av information 


33

Varför designmönster?

Create successful ePaper yourself

Delete template?

Save as template?