DAIMIIntroducerende objektorienteret programmering4C.1 Systemdesign Design med flere klasser, En kaffeautomat.

Præsentationer af emnet: "DAIMIIntroducerende objektorienteret programmering4C.1 Systemdesign Design med flere klasser, En kaffeautomat."— Præsentationens transcript:

1 DAIMIIntroducerende objektorienteret programmering4C.1 Systemdesign Design med flere klasser, En kaffeautomat

2 DAIMIIntroducerende objektorienteret programmering4C.2 Relation til kapitel 4  Arnow & Weiss’ angiver i kapitel 4 deres 4+1 proces for design af en enkelt klasse.  Kapitel 5 udvidere denne proces til design af et system/program bestående af flere klasser som samarbejder om at realisere et mere komplekst system.

3 DAIMIIntroducerende objektorienteret programmering4C.3 Et par bemærkninger  Hvorfor flere klasser? Kunne vi ikke lave én klasse med hele den komplekse funktionalitet?  Jo, og det er (tilnærmelsesvis) tilgangsvinklen i ‘klassiske’ sprog som Pascal og C. Disse sprog tilbyder kun metoder, ikke klasser, så deres ‘programmeringsmodel’ kan opfattes som ét objekt med (alt for) mange metoder.  Styrken ved objekt-orienterede sprog er at forskellige kompetancer/modelelementer kan beskrives hver for sig.

4 DAIMIIntroducerende objektorienteret programmering4C.4 Systemdesign  Processen har flg. hovedelementer Problembeskrivelse (kravspecifikation) Beskrivelse af typisk (brugs-)scenarie Finde primære objekter/begreber Beskrive ønskede opførsel for hvert objekt/klasse For hver klasse gennemføres en (tilnærmet) 4+1 klassedesign process: –Definition af interface –Realisation af implementation  Husk: Det er ofte nødvendigt at gentage dele af processen flere gange: Iterativ design

5 DAIMIIntroducerende objektorienteret programmering4C.5 Eksempel: En kaffeautomat  Problembeskrivelse:  Der skal laves en kaffeautomat. Automaten kan lave en kop kaffe, prisen er 3 kr. Automaten accepterer et DanMønt/kantinekort som det debiterer for hver kop kaffe, men kun hvis der er dækning på kortet. Automaten viser hele tiden hvor mange penge der er på kortet.  Automaten kan oplyse, hvor meget den har solgt til et givet tidspunkt.

6 DAIMIIntroducerende objektorienteret programmering4C.6 Brugsscenarie  Kurt har et nyt kantinekort på 100 kr. Han indsætter kortet i automaten, ser at der er 100kr tilbage på det, og trykker på ‘bryg’ knappen. Derefter får han en kop kaffe, og displayet viser 97kr tilbage. Han brygger endnu en kop kaffe inden han tager kortet ud igen.  Ejeren kommer forbi senere og får oplyst at automaten har solgt for ialt 6kr kaffe.

7 DAIMIIntroducerende objektorienteret programmering4C.7 Finde primære objekter  Navneord i problembeskrivelsen er ofte gode kandidater til klasser  Der skal laves en kaffeautomat. Automaten kan lave en kop kaffe, prisen er 3 kr. Automaten accepterer et DanMønt/kantinekort som det debiterer for hver kop kaffe, men kun hvis der er dækning på kortet. Automaten viser hele tiden hvor mange penge der er på kortet.  Automaten kan oplyse, hvor meget den har solgt til et givet tidspunkt.  Hvilke er så mest ‘vigtige’?

8 DAIMIIntroducerende objektorienteret programmering4C.8 Designperspektiv  Enhver model er bygget ud fra et ganske bestemt perspektiv. Perspektivet fortæller os hvilke elementer i modellen det er vigtigt at modellere, og hvilke vi kan se bort fra.  Eks: Den vigtigste funktion for arkitektens papmodel af et hus er at give et helhedsindtryk, derfor ignoreres detaljer og materialevalg, styrke, osv.

9 DAIMIIntroducerende objektorienteret programmering4C.9 Perspektiv: Automat  Vores designperspektiv (krav til funktionalitet) er dikteret ud fra automatens synsvinkel: “Der skal laves en kaffeautomat”.  Derfor er det denne synsvinkel der dikterer, hvilke elementer vi vil se bort fra i vores program, og hvilke der er vigtige.  Centrale objekter: Kaffeautomat Betalingskort Ydelsen - en kop kaffe

10 DAIMIIntroducerende objektorienteret programmering4C.10 Basale opførsel  Næste skridt er at definere den basale opførsel for ens klasser. Arnow og Weiss deler dette op for hver klasse. Dette er mindre heldigt, da man let overser det vigtigste: Samspillet mellem klasserne.  Vi foreslår at man skitserer et/flere brugsscenarier i form af små testprogrammer. Med disse kan man afgøre, hvilken opførsel man ønsker og hvorledes objekterne spiller sammen.  Se “TestCoffeeVendingMachine” i us4-projektet.

11 DAIMIIntroducerende objektorienteret programmering4C.11 Klassedesign  Her kan Arnow og Weiss’s 4+1 designproces bruges for hver klasse: Definere opførsel Definere interface (metodeprototyper) Definere testprogram Definere klasseskelet Implementere metodekroppe, definere instans variable  For små systemer kan man ofte springe over testprogrammet; men er klassen i sig selv kompliceret er dette skridt vigtigt.

12 DAIMIIntroducerende objektorienteret programmering4C.12 Kaffeautomat systemet  Det anbefales at studere kaffeautomatsystemet grundigt.  De næste slides forklarer nogle detaljer og valg i mere deltalje.

13 DAIMIIntroducerende objektorienteret programmering4C.13 Java’s toString()  Java kan automatisk konvertere grundlæggende datatyper til strenge:  int x=7; System.out.println( “x=“+x );  Java tilbyder det samme for klasser, hvis man definerer en metode med prototypen:  public String toString()  toString() vil blive kaldt alle steder hvor et objekt evalueres og Java forventer en String-værdi

14 DAIMIIntroducerende objektorienteret programmering4C.14 Brug af ‘null’  Metoden i CoffeeVendingMachine, som sælger en kop kaffe, returnerer en instans af CoffeeCup. Men - hvad hvis der ikke er penge nok på kortet?  Værdien ‘null’ betyder: “Referencen refererer ikke til noget objekt” og dette er derfor en naturlig værdi at returnerer: Kunden får jo vitterlig ingen kaffe.

15 DAIMIIntroducerende objektorienteret programmering4C.15 Test for fejlmuligheder  Metoden buyCoffee() i CoffeeVendingMachine bruger if-sætninger til at teste fejlmuligheder inden der brygges kaffe: if ( chargeFrom == null ) { System.out.println( "Der er ikke indsat noget kreditkort." ); return null; } if ( chargeFrom.balance() < priceForCoffee ) { System.out.println( "Fejl: Der er ikke penge nok på kortet: "+ chargeFrom ); return null; } System.out.println( "Der brygges..." ); chargeFrom.withdraw( priceForCoffee ); soldFor += priceForCoffee; System.out.println( chargeFrom ); return new CoffeeCup(); Bemærk: Ved at bruge return inde i if’erne kan man her helt undgå at bruge ‘else’.

16 DAIMIIntroducerende objektorienteret programmering4C.16 Konstanter  Prisen for en kop kaffe er 3 kroner. Men vi kan forvente dette ikke varer evigt. Hvis prisen ændrer sig, skal vi rundt og rette alle steder, hvor der forekommer et tretal i javakoden –  Eller næsten alle steder - hvad hvis der er andre sammenhænge hvor 3 indgår: F.eks. antal gram sukker i en sødet kop kaffe?  Løsningen: Brug en konstant istedet:  private static final int priceForCoffee = 3;

17 DAIMIIntroducerende objektorienteret programmering4C.17 ‘Halvtomme’ klasser  Klassen CoffeeCup er stort set en ‘tom’ klasse. Men dens eksistens er vigtig, da den jo netop repræsenterer et vigtig element i vores model: At kunden får en kop kaffe i hånden.  Og hvis senere krav opstår, kan vi let udvide klassen; en kop kaffe med fløde, sukker, osv…

18 DAIMIIntroducerende objektorienteret programmering4C.18 Test af programmer  Vores testprogram tjekker kun at vores klasser virker i de korrekte tilfælde.  Det er naturligvis vigtig at man også forsøger de mulige ‘forkerte’ situationer: For lidt penge på kortet, kortet ikke indsat, osv., for at godtgøre at vores klasser er korrekt implementeret.