Design Patterns - mønstre

Transkript

1 Design Patterns - mønstre Om mønstre i design Kirsten Ribu

2 I dag Om estimeringseksperimentet Mønstre Patterns 2

3 Estimeringsksperimentet 22 deltakere 11 fikk oppgitt 50 timer 11 fikk oppgitt 400 timer Hvordan gikk det.? 3

4 Resultat: Lavt anker - 50 timer: Svar: 30,50,60,60,70,70,75,80,100, 100,150 Gjennomsnitt: 76,8 timer 50 Høyt anker timer: Svar: 100,150,190,200,200, 250,300,350, 400,400,400+ Gjennomsnitt: 267,3 timer 400 4

5 Designmønstre = oppskrifter 5

6 Opprinnelsen til begrepet mønstre Ideene bak design patterns stammer fra arkitektfaget, hvor Christopher Alexander utviklet et stort antall designmønstre Professor i arkitektur ved University of California, Berkeley Har skrevet en rekke bøker, som viser 'en ny vei' til bedre design Tar et oppgjør med det tradisjonelle designparadigmet, som er basert på en faseoppdelt framgangsmåte: Analyse leder til spesifikasjon, som er grunnlag for konstruksjon (fossefall) 6

7 Sitat Model, process, context and artifact are intertwined aspects of the same system 7

8 8

9 Hva er et designmønster (pattern)? Et mønster (pattern) er en formalisering av et problem med løsning. Bruken av mønstre i en systemdesign kontekst er relativt ny Mesteparten av arbeidet på dette området er gjort etter Et mønster skisser et par (problem + løsning) Brukes til å ta en beslutning om designet. Et mønster kan være nyttig for mange slags problemstillinger som har grunnleggende likhetstrekk 9

10 Mer. Designmønstre er uformelle verbale beskrivelser av et problem og hvordan vi generelt løser problemet. Sammen med mønsteret følger det et konkret eksempel på bruk av mønsteret. Et designmønster er et navngitt 'gullkorn' av instruktiv informasjon som fanger vesentlige strukturer og innsikt om utprøvede løsninger på tilbakevendende problemer i en bestemt kontekst. Brad Appleton: 10

11 Delprosesser i en utviklingsprosess Pilene viser delaktiviteter der mønstre hjelper utviklingen. 11

12 Patterns - gjenbruk av kunnskap om utforming (design). Historikk Standardalgoritmer (1971 Knuth) Abstrakte datatyper- trær, stakk, lister (1987 Booch) Utformingsmønstre (1995) fra Christopher Alexander(1977) mønstre i bygningsutforming Mønster beskriver et problem og dets generelle løsning ikke detaljert basert på erfaring 12

13 Hvorfor bruke mønstre (patterns) for informasjonssystemer? Mye av vårt daglige virke består i å lete etter strukturer (mønstre) i omgivelsene Mønstre er vanlige løsninger på vanlige problemer Det samme gjelder utvikling av informasjonssystemer Mange systemer har grunnleggende fellestrekk Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie 13

14 Produksjon og konsumpsjon Påstand: Mennesker er: Produsenter av varer og tjenester Konsumenter av varer og tjenester Mange av våre aktiviteter er former for kjøp/salg og produksjon Informasjonssytemer gjenspeiler og styrer våre aktiviteter Vi kan derfor (grovt) betrakte informasjonssystemer som varianter av kjøp/salg/produksjons-systemer 14

15 Tilbake til use case modell for Ordrebehandlingssystem 15

16 Fellestrekk ved informasjonssystemer Kan et kjøp/salg/produksjon system kan danne et grunnlag mønster for andre informasjonssystemer? I et hvilket som helst system, hva er det som tilsvarer Ordrene Varene Regnskap Leverandøren Kunden etc. 16

17 Gjenkjennelige trekk Vi finner igjen salgssituasjonen i mange sammenhenger Det er ofte nok til å komme i gang med en use case modell Og deretter et klassediagram. Vanlige klasser i et slikt system kan f.eks være: Ordre Lager Leverandør Kunde Produkt Faktura 17

18 Use casemodell for Kjøp/salgsystem 18

19 Mønster for klassediagram 19

20 Problem/løsning - par Kritiske designspørsmål: Hvordan allokere ansvar til klasser? Hvordan skal objekter samarbeide? Hvilke klasser skal gjøre hva? Noen utprøvde løsninger på designproblemer = best-practice prinsipper (mønstre) = patterns: eksemplifiserte kodeløsninger på design-prinsipper 20

21 Gjenbruk av løsninger Hensikt: å omsette eksisterende design kunnskap til et kodeskjelett Man trenger ikke finne opp hjulet på nytt hver gang. Å navngi mønstrene letter kommunikasjonen mellom utviklerne 21

22 Fire essensielle deler Meningsfullt navn på mønsteret. En beskrivelse av problemet mønsteret kan brukes på. En løsningsbeskrivelse. Ikke konkret Ofte grafisk framstilt Beskrivelse av konsekvensene resultater kompromisser 22

23 Hva har vi sett på før: GRASP - General Responsibility Assignment Software Patterns. Information Expert (Eksperprinsippet) Creator (skaperprinsippet) Controller (kontrollprinsippet) Høy kohesjon Lav kobling 23

24 Objektdesign Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den Kontrollobjektprinsippet: To typer kontrollere: Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite system) Use case kontroller: Styrer ett use case (brukes i større systemer. Et kontrollobjekt for hvert use case). Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet 24

25 Information Expert Tildel ansvar til den klassen som har tilgang til den nødvendige informasjonen for å gjøre jobben Eksempel: I et salgssystem: Metoden hentkundenummer() legges i klassen som har variabelen kundenr. Fordel: Ulemper: Oppnår på denne måten lav kobling og høy kohesjon Kan få for store klasser ved at for mye ansvar puttes inn i en klasse. Løsning: Fordel ansvaret på to klasser 25

26 Creator Problem: Hvilken klasse er ansvarlig for å opprette nye objekter? Løsning: La det objektet som må vite om de nye objektene lage dem Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant: B inneholder A-objekter B bruker A-objekter B har data som sendes til A-objektet når det opprettes Eksempel: KlasseB objekta = new KLasseB() Ulempe: Klasse A og B har høy kobling 26

27 Controller Hvilken klasse skal behandle en systemhendelse/melding? Kontrolleren ligger gjerne på klienten Kontrolleren har bare metoder, få eller ingen variabler. Kontrolleren gjør ikke jobben selv, men mottar og fordeler oppgaver er en slags administrator Delegerer oppgaver og styrer use case. Er et bindeledd mellom brukergrensesnittet og applikasjonslaget 27

28 Controller eksempel GUI Controller Kunde fasade kundedatabase Fordel: Lett å bytte ut klassene over og under kontrollklassen, spesielt grnesesnitt Styrer hendelsesforløpet i et use case 28

29 Controller forts. Ulemper: Mange metodekall sinker systemet Mye koding Flere klasser Kontrollere får for mye ansvar = mangel på kohesjon: Kontrolleren har for mange jobber å gjøre. Ansvaret og attributtene skulle vært distribuert 29

30 Mer.. Bruk av patterns blir stadig mer populært GoF patterns (Gang of Four) -> Creator, Factory, Singleton 30

31 Gang of Four (GoF) Erich Gamma Richard Helm Ralph Johnson John Vlissides forfatterne av boka Design Patterns, Elements of Reusable Object-oriented Software ble kjent som Gang of Four. Navnet var for langt til å brukes i , derfor firerbanden. Deres mønstre er kjent som GoF patterns. 31

32 GOF (Gang of Four) 23 Mønstre Creational Patterns (5) Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural Patterns (7) Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Behavioural Patterns (11) Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor Bok: Design Patterns av Erich Gamma (Author), Richard Helm (Author), Ralph Johnson (Author), John Vlissides (Author), Publisher: Addison-Wesley Pub Co; 1st edition (January 15, 1995) ISBN:

33 GoF Patterns Behavioral Oppførsel Creational Skaper Structural - Struktur 33

34 Behavioral patterns Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor 34

35 Creational patterns Abstract factory Builder Factory method Prototype Singleton 35

36 Structural patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy 36

37 Neste gang Arkitektur 37