Del 3 : Patterns (Kap 16 – kap 20, Craig Larman) Arne Maus Inst. for informatikk, UiO.

Presentasjon om: "Del 3 : Patterns (Kap 16 – kap 20, Craig Larman) Arne Maus Inst. for informatikk, UiO."— Utskrift av presentasjonen:

1 del 3 : Patterns (Kap 16 – kap 20, Craig Larman) Arne Maus Inst. for informatikk, UiO

2 2 Standard løsninger – Patterns – kap 16  Hvordan gi metoder til Klasser – hvem gjør hva  Eks: Hvilken klasse lager en ny ordrelinge  Hvilken klasse skriver ut vitnemål i et studentregister  Ansvar og metoder:  Hva man gjør:  Lage ett objekt  initiere handling i andre objekter  kontrollere og koordinere aktiviteter i andre objekter  Hva ett objekt vet  Private data  Andre objekter det har peker til  Hva det kan finne ut indirekte via andre objekter

3 3 Patterns / mønstre  Et pattern er et navngitt par av problem & løsning som kan anvendes i en ny sammenheng. Inkludert er råd og drøftinger hvordan man bruker mønsteret og diskusjon om ulemper og fordeler.  Kom opprinnelig fra standardløsninger i arkitekturen (Christopher Alexander)  Er gamle løsninger i generalisert form  Patterns har et beskrivende navn  Fordeler ved patterns:  Utviklingstiden kortere  Kjente fordeler/ulemper med ett pattern  Vedlikehold enklere fordi vi skiller bedre mellom ulike funksjoner (gode og klare begreper)

4 4 GRASP: Patterns for å tilordne ansvar til klasser i Desigmodellen I. Informasjons ekspert II. Skaper III. Høy (indre) sammenheng IV. Lav (ytre) kobling V. Kontrollør

5 5 I. Informasjons ekspert Løsning: Gi ansvar til den som vet det som er nødvendig for å utføre handlingen Problem: Det mest generelle prinsippet for å fordele funksjonaliteten til klasser Eksempel: Bankkonti og ’giSaldo’, Salg og ’giTotalsum’.

6 6 Problem: Hvordan skrive ut totalprisen på et salg?  Vi har følgende klasser:  Salg: skal vite totalsum av et salg  SalgsLinje: Skal vite prisen på ett kjøp ev en vare (en faktura-linje)  VareBeskrivelse: Vet prisen på ett eks av en bestemt Vare  Løsning ?  a) La Salg beregne alt  sentralisert beregning  b) La hver klasse beregne det som det vet  Desentralisert beregning

7 7 La Salg beregne alt  Salg inneholder en løkke:  Via assosiasjon (peker) til SalgsLinje og videre- assosiasjon (peker) til VareBeskrivelse, enkelt summerer og multipliserer samman antall fra SalgsLinje og (enhets) pris fra VareBeskrivelse.  Fordeler ? Ulemper ?

8 8 Hver klasse beregner hva den vet

9 9 II. Skaper (eier, sjef) Løsning: La den klasse B lage et nytt objekt av en annen klasse A hvis:  B oppsummerer (er summen av) A objekter  B inneholder A objekter  B bruker ofte A objekter  B har de data som skal til for å initialisere B objekter Problem: Hvem skal lage ett nytt A objekt ? Eksempel: Et salg oppsummerer mange salgslinjer – hvem lager objekter av klassen SalgsLinje?

10 10 Forholdet Salg, SalgsLinje,

11 11 Hvem lager ny Salgslinje, Varebeskrivelse

12 12 III. Lav (ytre) kobling Kobling er hvor mange andre klasser og dets egenskaper og metoder, en klasse A behøver å vite om. Jo mindre desto bedre = enklere vedlikehold.  Endringer i klasser A vet om, medfører endringer i A  A er vanskeligere å forstå lokalt  Vanskeligere å gjenbruke  Må alltid veies opp mot andre krav & egenskaper vi ønsker

13 13 Betaling, Register, Salg – hvem vet om hvem når vi skal generere en Betaling for et Salg?  Det starter med et metodekall til Register Register Betaling Salg :Register utførBetaling ()

14 14 Løsning 1 ; Register vet om ’alle’ :Register b: Betaling :Salg utførBetaling () 1. lag() 2. adderBetaling (b)

15 15 Løsning 2: Register vet om Salg, som vet om Betaling :Register :Salg utførBetaling () 1. adderBetaling () Betaling 1.1. lag()

16 16 Vurdering av Lav Kobling Vi vurderer lav kobling alltid. Vi har kobling mellom to objekter A og B når:  A har en peker til B  A kaller tjenester (metoder) i B  A har en metode som referer B eller lager en refranse til B  A er en subklasse av B  B er et grensesnitt som A implementerer  Lav kobling er ikke eneste kriterium – klassene i systemet vårt skal tross alt henge sammen !  Enkelt å koble seg til kjente klasser – som Java- biblioteket fordi de er stabile (heller ikke vedlikeholdt av oss)

17 17 IV. Høy (indre) sammenheng Løsning: Gi ansvar for metoder slik at indre sammenheng blir størst mulig (mye metode-kall innad i klassen), få (færrest) kall til metoder i andre klasser. Klassen har ’bare’ ansvar for ett ’område’ – ikke masse ulikt. Problem: Begrense kompleksiteten og få best mulig vedlikeholdbarhet i systemet. Mindre sårbar mot endinger i de andre klassene. Eksempel: Må registeret lage en ny betalig eller la Salg gjøre det :Register :Salg utførBetaling ()1. adderBetaling () Betaling 1.1. lag()

18 18 Lav kobling og høy indre sammenheng kan kombineres  Kalles modulær design  En klasse har en oppgave/rolle  Problem/drøfting:  For finkornet struktur (for mange klasser)  - Mye kode  - Langsomt  + Bedre gjenbrukbar  + Bedre vedlikeholdbar

19 19 V. Kontrollør Løsning: Motta alle I/O meldinger (inndata fra GUI-brukergrensesnittet) for hele systemet, eller for noen/ett Use Case. Videresender kallene til aktuelle metoder i de andre klassene (delegere ansvar). N.B. Foran en kontroller ligger selve GUI-grensesnittet som mottar selve kallet fra operativ-systemet, pakker ut tekst, og foretar kallet til Kontrolløren, som så finner ut hvilket. Problem: Hvem skal styre gangen i bruker-interaksjonen ( kontrollere /koordinere det hele). Eksempel: Alle typer systemer med brukergrensesnitt. Bruker ofte mønsteret: Modell - Kontroll – Fremvisning (Model – Control – View,) (en klasse for hver funksjon)

20

21 21 Lage Design ut fra Use Case og GRASP Patterns – kap 17  Lage en design om samarbeidende objekter med metoder ut fra Use Case’ne.  (samarbeid med objektet B = kalle en metode i B)  Sentralt står i hvilken klasse funksjonaliteten ligger  Enda viktigere: Oppdage og lage design og kode for tilfellet når vi har mange objekter av en klasse (Mengder/collections).  Her bruker vi containere som: arrayer, ArrayList og ofte: HashMap.  Containere er egne klasser og objekter i systemet vårt  Må skille mellom når vi spør mot mengden og når vi kaller metode i ett bestemt objekt.

22 22 Eksempler fra KassaApparatet  Skille en mengde fra ett bestemt objekt (viktig)  Hvem skal ’eie’ / ha ansvaret for en slik mengde ?  Bruk informasjonsekspert mønsteret (ny klasse ProduktKatalog)  Produktspesifikasjoner:  lese inn og lage Produktspesifikasjoner (en per vareslag)  å finne riktig produktspesifikasjon til et bestemt salg (en salgslinje på regningen)  Salgslinjer  Etter hvert som de registreres, skal de lages og oppbevares i en datastruktur  Denne samlingen av salgslinjer kan brukes til å finne total sum på regningen  Eies av Salg (er temporær, lages og brukes i løpet av ett Salg)

23

24 24 Bestemme utsyn (private, public) i Designmodellen – kap 18  For at objekt A skal kunne kalle en metode i objekt B, må A kunne ’se’ B  Men desto mer som er skjult for A, desto bedre (mindre kaos)  Attributt synlighet – B er et attributt i A  Parameter synlighet – B er parameter til A  Lokal synlighet – B er et lokalt objekt i en metode A  Global synlighet – B er globalt synlig

25 25 Lage Klassediagram i Designmodellen – kap. 19  Lages ofte sammen med interaksjons- diagrammene  Viser detaljer (data, metoder og unntak) i klassene, men også  Hvilke grensesnitt som implementeres  Assosiasjoner til andre klasser  Navigasjonsretninger på assosiasjonene  Avhengigheter (vet om andre klasser indirekte)  Type-informasjon på parametre

26 Samarbeidsdiagram for å lese inn produktkatalog og initiere Registeret

27 Deler av Design-modellen for KassaApparatet

28 28 Lage kode av design– kap 20  I en 2 ukers iterasjon, bruk minst en halv dag å modellere i UML – før man starter å programmere !?  Programmering er følgelig hovedaktiviteten !  Bruk enkle redskaper til å tegne diagrammene –  blyant & papir  tavle, whiteboard (+ elektronisk kamera)  PowerPoint, Visio,  CASE-verktøy som RRose  Best til ’reverse engineering’ – lage Klassediagram fra kode  Alternativt : Designdrevet utvikling

29 29 Hvordan lage kode  Ta tak i interaksjonsdiagrammene (= sekvens- eller samarbeids-diagrammene) og DesignKlasseDiagrammet  der står det metodekall m. parametre – implementer disse  Assosiasjoner med retninger  blir pekere  Containere (multi-objekt klasser)  arrayer (av pekere)  ArrayList  HashMap (med nøkkel og søkemuliget)

30 30 Skriv test-kode først  Lage enhetstest (må gjøres)  Lages best når man har konseptet klart i hodet  En test dokumenterer koden (i tillegg til for og etter- betingelser)  Nyttig ved endringer i koden