Kapittel 6

1. Kapittel 6 Objektorientert design

2. 6.1 Programvareutvikling • Skriving av kode ein liten del av arbeidet med å lage programvare • Fire hovudaktivitetar • Kravspesifikasjon • Design • Implementasjon • Testing • Inf160 fokuserer mest på implementasjon • For større system blir dei andre delene viktigare

3. 6.2 Klasser og objekt • Viktig del av objektorientert design å bestemme kva klasser vi treng • Vi kan finne potensielle klasser ved å leite etter substantiv i kravspec’en • Det er ikkje slik at alle substantiv vi finn skal vere klasser i systemet! • Gi klassene gode namn • Primitiv type eller klasse? • Gjenbruk – klassebibliotek • Tildeling av ansvar – kva skal dei ulike klassene utføre

4. 6.3 Statiske klassemedlemmer • Både variable og metoder kan vere static • Statiske klassemedlemmer blir kalt gjennom namnet på klassen, ikkje gjennom eit objekt av klassen • Math.sqrt(27) – her bruker vi Math klassen sin statiske metode sqrt() som returnerer kvadratrot • Statiske klassemedlemmer er felles for heile klassen, i motsetning til instansvariable og –metoder • Om vi ikkje har bruk for å ta vare på tilstand, kan statiske metoder vere OK • Vi kan ikkje referere til instansvariable eller –metoder i ein statisk metode

5. 6.4 Forhold mellom klasser • Avhengigheit • Ein klasse bruker andre klasser • Aggregering • Objekt av ein klasse inneheld objekt av ein annan klasse • Arv • Meir om arv i kap 8

6. Forhold mellom klasser • Dersom klasse A bruker klasse B: • Ein eller fleire av klasse A sine metoder kaller ein eller fleire av klasse B sine metoder • Viss ein statisk metode blir kalt bruker A berre namnet til B • Elles må A ha ein referanse til eit objekt av klasse B • Fleire måtar å få tilgang på • A kan ha objekt av klasse B som instansvariabel • Metode i A kan opprette og bruke objekt av B • Referanse til B kan sendast inn som parameter • Generelt: minimere bindingar mellom klasser

7. Forhold mellom klasser • Objekt av ein klasse bruker ofte andre objekt av same klasse • Samanlikningar (compareTo(), equals()) • Lage nye objekt (concat()) • Aggregering – objekt kan vere laga av andre objekt • Vi definerer alle objekt med referanser til andre objekt som instansdata, som aggregerte objekt • “has-a” forhold

8. Forhold mellom klasser • this-referansen • Reservert ord som blir brukt når eit objekt refererer til seg sjølv • Blir ofte brukt til å skille mellom parameter til ein konstruktør og instansvariable med same namn

9. 6.5 interface • Interface (grensesnitt) blir brukt i fleire samanhengar • Kontaktflate mellom brukar og system, gjerne i form av eit skjermbilde • Tilgjengelege metodar for å bruke eit objekt blir gjerne omtalt som klassen sitt grensesnitt • Eit interface i Java er ei formalisering av det siste

10. interface • Ei samling av konstantar og abstrakte metoder • Ein abstrakt metode har ingen implementasjon (ingen kode) • Spesifiserer returtype, namn og parameterliste • Vi kan ikkje opprette instanser (objekt) av eit interface • Ein klasse som implementerer eit interface må ha alle metodene som er med i interfacet • Bruk av det reserverte ordet implements

11. interface • interface i UML • Comparable-interfacet • Blir brukt for å samanlikne to objekt • Kun ein metode: compareTo() • Tar eit objekt som parameter • int res = obj1.compareTo(obj2); • Returnerer int • res < 0: obj1 < obj2 • res = 0: obj1 = obj2 • res > 0: obj1 > obj2 • Kva vil det seie at eit objekt er størst?

12. 6.6 Enumererte typer • Introdusert i kap 3 • Spesiell type klasse, der alle verdier er objekt/instanser av klassen • Verdiane er lagra som public static variable i klassen • Vi kan også legge til instansvariable og –metoder • Vi ser litt på Seasons-eksemplet

13. 6.7 Design av metoder • Ei algoritme er ein stegvis prosess for å løyse eit problem • Kan samanliknast med ei oppskrift • Alle metoder innheld ei algoritme som løyser oppgåva metoden skal utføre • Vi bruker ofte pseudokode for å beskrive algoritmer • Det er ofte nødvendig/lurt å dele opp metoder • Få oversikt – splitt og hersk! • Private hjelpemetoder som får ansvar for mindre deler av problemet

14. Design av metoder • Parameter til metoder • Alle parameter i Java blir sendt by value • Kva betyr det? • Det betyr ulike ting, avhengig av om parameteren er ein primitiv type eller eit objekt • Primitive typer: verdien av den faktiske parameteren i metodekallet blir kopiert til den formelle parameteren i metode-headeren • I klartekst betyr det at vi opererer på ein kopi i metoden • Eventuelle endringar er ikkje synlege etterpå

15. Design av metoder • Objekt som parameter: objekt er referanser/adresser, vi sender altså over ein kopi av referansen • Det betyr at metoden har den same referansen, og difor opererer på det originale objektet • Endringar er synlege etterpå • Vi ser litt nærare på eksemplet i ParameterTester

16. 6.8 Overloading • Vi kan ha fleire metoder med same namn i same klasse • Desse må ha ulike parameterlister slik at kompilatoren veit kva metode som blir kalt • Tal på parameter til metoden • Datatype • Rekkefølgje • Det er ikkje nok å ha ulike typer returverdi, sidan denne ikkje alltid blir brukt • Vanleg å overloade konstruktørar

17. 6.9 Testing • Vi testar programvare for å finne feil • Så godt som all programkode inneheld feil • Betre at vi finn feil under testing enn at dei som skal bruke systemet gjer det • Inspeksjon • Gjennomgang av designdokument eller kode for å finne, men ikkje rette, feil • Test case • Input, det brukaren gjer, forventa output • Test suite, test cases som saman dekker dei ulike delene av systemet vi skal teste

18. Testing • Test cases må lagast med andakt • Skal helst avsløre alle feil • Skal ikkje overlappe kvarandre • Bruk av ekvivalensklasser til å finne input • Grenseverdier • Black box testing • Vi ser bort frå korleis programmet fungerer, ser kun på at output skal stemme med input • White box testing • Vi testar ut frå vår kunnskap om korleis programmet fungerer • Vi prøver å få kjørt alle statements i programmet

19. 6.10 GUI Design • Java tilbyr hjelpemiddel for å lage det mest utrulege av GUI • Men pass på ... • Kva lærte du om design i In105? • Prøv å • Hindre brukaren i å gjere feil • Tilby fart og effektivitet for den erfarne • Vere konsistent

20. 6.11 Layout managers • Ein layout manager er eit objekt som styrer korleis komponentar blir stilt opp i ein container • Bestemmer størrelse og plassering • Bestemmer kva endringar som skal skje når containeren endrar størrelse, eller når nye konponentar blir lagt til • Alle containerar har ein default layout manager som vi kan erstatte om vi vil

21. Layout managers • Mange typer, vi ser på nokre av dei mest brukte • Flow layout • Border layout • Grid layout • Box layout • Rigid area og glue

22. 6.12 Kantlinjer • Vi kan forsyne alle Swing-komponentar med kantlinjer av ulike slag • BorderFactory klassen tilbyr metoder for å lage slike • Bruk med fornuft, sjå BorderDemo-eksemplet

23. 6.13 Inneslutningshierarki • Har nokon eit betre ord for containment hierarchy? • Vi grupperer komponentar i containerar • Containerane er vidare gruppert i andre containerar • Til saman utgjer dette eit hierarki • Komplisert GUI-design kan gjerne representerast som ein trestruktur, jfr fig 6.13 i læreboka