Projektkursen Designmönster. Sammanfattning och slutsatser. Till stora delar lär vi genom att härma och efterlikna

Transkript

1 2D1362: 2003 Projektkursen 2003 Innehåll Återanvändning Problem Bakgrund Lösning Exempel Sammanfattning och slutsatser previous next Å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

2 2D1362: 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... 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 2

3 2D1362: 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 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 3

4 2D1362: 2003 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 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 4

5 2D1362: 2003 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 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 5

6 2D1362: 2003 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 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 6

7 2D1362: 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 previous next 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 Presenterar M Interagerar V C previous next 14 7

8 2D1362: 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 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 8

9 2D1362: 2003 Exempel-1 Alexander: 136 A Couple's Realm* previous next 17 previous next 18 9

10 2D1362: previous next 19 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 previous next 20 10

11 2D1362: 2003 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 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 11

12 2D1362: "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 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 12

13 2D1362: 2003 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 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 13

14 2D1362: 2003 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? previous next 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(); previous next 28 14

15 2D1362: 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 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 15

16 2D1362: forts Implementation Typiskt med gemensam abstrakt superklass AbstractPhone NullPhone Phone Null Object AbstractInfo MissingInformation Information Kan också implementeras mha mönstren State eller Strategy previous next 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 16

17 2D1362: 2003 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. previous next 33 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 17

18 2D1362: 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() return methodx() + methody(); Subklass return α; methodx() methody() return β; previous next 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. previous next 36 18

19 2D1362: 2003 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 Leaf2 Composite previous next 37 Composite Exempel Shape 1..* Rectangle Ellipse Group Graphic * Command 1..* Line Rect Text Picture Macro previous next 38 19

20 2D1362: 2003 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. previous next 39...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. previous next 40 20

21 2D1362: 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 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 21

22 2D1362: 2003 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 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 22

23 2D1362: Subject observers * Observer attach(observer) detach(observer) notify() for all o in observers { o.update(); update() previous next 45 ett sekvensdiagram som visar ett typiskt scenario :subject o 1 :observer o 2 :observer o 3 :observer :object attach(o 1 ) attach(o 2 ) attach(o 3 ) notify() update() update() update() notify() update() update() detach(o 3 ) previous next 46 23

24 2D1362: 2003 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 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(); Lägg till observer Ta bort observer public synchronized void addobserver(observer o) { if (!obs.contains(o)) {obs.addelement(o); public synchronized void deleteobserver(observer o) { obs.removeelement(o); previous next 48 24

25 2D1362: 2003 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 previous next 49 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 25

26 2D1362: 2003 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; this.setchanged(); this.notifyobservers(message); Vi meddelar beroende objekt, med message som argument Vi indikerar att objektet ändrats previous next 51 observer: exempel... import DB.*; Implementera gränssnittet Observer import java.util.*; class Student extends DB.Student implements Observer { 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 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 ) { super(christianname, familyname, pnr, programme, ); previous next 52 26

27 2D1362: 2003 observer: exempel... 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 */ previous next 53 observer: exempel... Student pers2 = new Student("Olle", "Olsson", "113", "D96", "olle@hagalund.se"); pers2.addcourse("oompa00"); pers2.addcourse("english-1"); Gör pers2 beroende av board 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 27

28 2D1362: 2003 observer: exempel Student pers3 = new Student("Lotta", "Ason", "123", "F98", "ff@home.se"); 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 observer-exemplet i Smalltalk DB.Student subclass: #Student Object Object subclass: subclass: #MessageBoard #MessageBoard instancevariablenames: 'message' 'message' update: anaspectsymbol with: with: arg arg getmessage getmessage Transcript ^message ^message show: show: self self christianname, changemessage: ' tar tar emot emot meddelande: ', changemessage: msg msg ', message arg message := := msg. msg. arg 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 'd '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 previous next 56 28

29 2D1362: Observerexemplet i UML I UML skulle exemplet se ut något i stil med MessageBoard Subject Subject Observer Observer Student Observer previous next 57 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. previous next 58 29

30 2D1362: 2003 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 State handle() state.handle() ConcreteStateA handle() ConcreteStateB handle() previous next 59 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 previous next 60 30

31 2D1362: 2003 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 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 31

32 2D1362: man kan också dela in designpatterns på följande sätt Purpose 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 previous next 63 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 32

33 2D1362: 2003 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 Referenser [Al64] Alexander, C. Notes on the Synthesis of Form, Cambridge: Harvard University Press, [Al77] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., and Angel, S. A Pattern Language, Oxford University Press, [Al79] Alexander, C. The Timeless Way of Building, Oxford University Press, [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 [Mes] Meszaros & Doble A Pattern Language for Pattern Writing Design Patterns hemsida med länkar till massor av information previous next 66 33