Kapittel 6 Objektorientert design. 6.1 Programvareutvikling Skriving av kode ein liten del av arbeidet med å lage programvare Fire hovudaktivitetar Kravspesifikasjon.

Presentasjon om: "Kapittel 6 Objektorientert design. 6.1 Programvareutvikling Skriving av kode ein liten del av arbeidet med å lage programvare Fire hovudaktivitetar Kravspesifikasjon."— Utskrift av presentasjonen:

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