public class NaivRiking { private HeldigSnylter minsnylter; public NaivRiking(HeldigSnylter h) { minsnylter = h;

Transkript

1 Forklaring til programmet NaivRiking.java (med tilhørende filer HeldigSnylter.java, Skattbar.java, FremkomstMiddel.java, Bil.java, Sykkel.java, Hus.java, Pils.java, Brus.java, Konto.java, SpareKonto.java) Antallet involverte filer kan se skremmende stort ut her, men merk da at de aller fleste av disse bare opprettes objekter av uten at objektene foretar seg noe særlig. Selve programmet er derfor forholdsvis enkelt mhp handlingsgangen samhandlingen utspiller seg stort sett mellom klassene NaivRiking og HeldigSnylter, hvor instanser av førstnevnte driver og gir forskjellige gaver til instanser av sistnevnte. Viktig å merke seg er dessuten grensesnittet Skattbar, som er det sentrale momentet som illustreres i dette eksemplet, og som implementeres av klassene Bil, Hus og Konto. For å forkorte forklaringen noe har jeg redusert antall linjer i NaivRiking.java i forhold til det som ble vist på forelesning, ved at kallene til new (new Bil(...), new Pils(), etc.) nå er satt direkte inn som argument til gigave()- metoden, som f.eks. nr1.gigave(new Bil(...)); mens det på forelesningsarket ble vist som Bil bil = new Bil(...); nr1.gigave(bil); Dette gjør ingen forskjell mhp hvordan programmet kjører. Før selve utførelsen av programmet forklares, litt om grensesnitt, her representert ved "!#%$ &('() * Som grensesnitt forøvrig ser vi det deklareres på samme måte som en klasse, bare at man bruker ordet interface istf class. Innmaten i grensesnittet består imidlertid kun av metodehoder (a la den abstrakte metoden i eksemplet AbstraktKontoTest), ingen kode som kan utføres. Det er derfor ingen arv med i bildet, i form av at en klasse kan overta kode fra grensesnittet Skattbar og dermed slippe å skrive den selv. Når en klasse implements Skattbar, som er det som tilsvarer extends... når det gjelder grensesnitt, oppnår ikke denne klassen som sådan noen åpenbar gevinst det den derimot gjør er å påta seg en forpliktelse. F.eks.,+#, / % ) +5 6&( 708$ %-49'# 708-;:<01$ %-4=9) * "!#%$ &(' % 9 A A A ) * * hvor de mest relevante delene av koden er understreket. Det som skjer her er at klassen Hus påtar seg å implementere Skattbar, som innebærer at Hus må tilby alle metodene definert i grensesnittet. I dette eksemplet dreier det seg kun om en enkelt metode, likningsverdi(), og som vi ser tilbyr klassen Hus denne med kode inkludert, i motsetning til selve grensesnittet, hvor kun metodehodet er definert. Samme kan man se for klassene Bil og Konto. Bil viser ikke noe nytt i forhold til Hus (merk bare at metoden likningsverdi() naturlig nok er programmert på en ganske annen måte fordi reglene for beregningen er vidt forskjellige for hus og biler og i dette eksemplet forøvrig helt oppdiktet, kemneren ville neppe ha vært imponert...). Mhp klassen Konto kan det nevnes at likningsverdi()-metoden her vil arves av subklassene KredittKonto og SpareKonto. Selv om det ikke står implements Skattbar i deklarasjonene av disse to subklassene, vil disse via arv også være regnet som implementører av det samme grensesnittet. Et av de fundamentale spørsmålene som forhåpentligvis kan bli klarere gjennom dette eksemplet er: Hva oppnår man egentlig ved at klassene Hus, Bil og Konto påtar seg en forpliktelse gjennom å skrive implements Skattbar i deklarasjonen? Man kunne jo også ha tilbudt metoden likningsverdi() helt uten videre, dvs. uten å skrive implements Skattbar. Og man sparte tilsynelatende ingenting ved å skrive implements Skattbar her siden man uansett måtte programmere den aktuelle metoden i sin helhet, da det jo ikke fantes noen kode man kunne arve. Svaret på dette er at det ikke er klassene Hus, Bil, Konto som blir enklere, men at man kan oppnå forenklinger andre steder i programmet. Grensesnitt har nemlig de samme fordeler som superklasser med typekompabilitet og substituerbarhet. Gitt de ovenstående kodefragmentene kan man dermed aksessere et objekt som egentlig er et hus gjennom en objektreferanse av typen Skattbar, f.eks. Skattbar s = new Hus(321); I denne enkle linjen ser ikke dette ut som noen gevinst, men dette vil forhåpentligvis bli klarere når vi etter hvert ser på klassen HeldigSnylter.

2 public class NaivRiking { private HeldigSnylter minsnylter; public NaivRiking(HeldigSnylter h) { minsnylter = h; public void gigave(object o) { minsnylter.mottagave(o); public static void main(string[] args) { HeldigSnylter h1 = new HeldigSnylter(); NaivRiking nr1 = new NaivRiking(h1); NaivRiking nr2 = new NaivRiking(h1); nr1.gigave(new Bil(200,1995,300000)); nr1.gigave(new Bil(130,1997,435000)); nr2.gigave(new Pils()); nr1.gigave(new Brus()); nr1.gigave(new Sykkel(45)); nr2.gigave(new Hus(234)); nr1.gigave(new SpareKonto(100000)); System.out.print("Snylteren har skattbar formue: "); System.out.println(h1.skattbarFormue()); import java.util.arraylist; public class HeldigSnylter { private ArrayList allemineting; public HeldigSnylter() { allemineting = new ArrayList(); public void mottagave(object o) { allemineting.add(o); public int skattbarformue() { int sum = 0; for (int i=0; i < allemineting.size(); i++) { try { sum += ((Skattbar)(alleMineTing.get(i))).likningsVerdi(); catch (ClassCastException e) { //gjør ingenting i catch fordi vi bevisst legger opp til å //å gjøre noen ulovlige cast her, er ikke sikkert alle //gjenstandene vi eier er Skattbare, og vi vet ikke hvilke return sum;

3 De øvrige filene er ikke vist. Grensesnittet Skattbar og klassen Hus står allerede på første side, Konto-klassene er vist i forklaringen til forrige eksempel. Klassen FremkomstMiddel (som er abstrakt), har subklassene Bil og Sykkel, hvorav Bil implementerer grensesnittet Skattbar (og altså tilbyr en metode likningsverdi()), mens Sykkel ikke implementerer dette grensesnittet. Klassene Pils og Brus gjør ingenting som helst (og implementerer heller ikke grensesnittet), de er bare med for å vise at vi kan opprette objekter av diverse forskjellige typer). Når programmet startes med java NaivRiking, vil utførelsen begynne med dennes main()-metode (linje 9). Her skjer følgende: Linje 10 oppretter en instans av HeldigSnylter (høyre side) og setter objektreferansen h1 til å vise til denne. Konstruktoren til HeldigSnylter vil her utføres (linje 28-30). Det eneste denne gjør er å opprette en ArrayList som snylterens private instansvariabel allemineting refererer til. Linje 11 oppretter en NaivRiking og setter objektreferansen nr1 til å vise til denne. Objektreferansen h1 (som nettopp ble tilordnet i forrige linje) gis inn som argument til konstruktoren, som nå utføres (linje 3-5). Det eneste denne gjør er å gi instansvariabelen minsnylter samme verdi som argumentet til konstruktoren. Dette innebærer altså at den naive rikingen som nr1 refererer til vil ha den heldige snylteren vi opprettet i linje 10 som sin heldige snylter. Linje 12 oppretter en ny NaivRiking som nr2 refererer til. Igjen er h1 argument til konstruktoren, som igjen utføres (linje 3-5). Dette innebærer at også denne nye naive rikingen har samme heldige snylter som den forrige. Vi har nå følgende situasjon (variable vises som rektangler, objekter som ovaler): h1 En riking-instans minsnylter nr1 minsnylter allemineting En snylterinstans En ArrayList-instans (foreløpig uten noen objekter i lista) En riking-instans nr2 Som man ser av denne figuren har vi altså lagd to forskjellige NaivRiking-instanser, men begge har den samme HeldigSnylter-instansen som sin snylter. I de neste 6 linjene (13-19) blir den heldige snylteren overrakt 6 forskjellige gaver. I linje13 opprettes en ny bil, og konstruktoren for klassen Bil blir utført. Denne er ikke vist her, men hvis man ser på filen Bil.java, vil man se at dette blir en bil med toppfart 200, årsmodell 1995 og nypris Den nyopprettede Bil-instansen blir umiddelbart brukt som argument i metodekallet nr1.gigave, som innebærer at gigave()-metoden kalles for den naive rikingen nr1, dvs linje 6-8 utføres. Her kan vi merke oss at det formelle argumentet i metodehodet (linje 6) har typen Object, mens det aktuelle argumentet som ble gitt inn i kallet var av typen Bil. Dette går imidlertid fint fordi Object er superklasse (direkte eller indirekte) for alle klasser i Java dette blir akkurat på samme måte som når det gjelder typekompabilitet ved tilordning: Ved tilordning må det som blir tildelt en verdi (dvs som står på venstre side av =) enten ha samme type som det som står på høyre side, eller en mer generell type som er direkte eller indirekte superklasse til denne Ved metodekall må det formelle argumentet (som står i metodens deklarasjon) enten ha samme type som det aktuelle argumentet (som blir gitt inn i kallet til metoden) eller være av en mer generell type som er direkte eller indirekte superklasse til denne. Hadde det derimot vært motsatt, at argumentet i metodens deklarasjon hadde vært av typen Bil, mens parameteren i kallet hadde vært av typen Object, ville man fått kompileringsfeil, jfr tilsvarende betraktninger for eksemplet AbstraktKontoTest. Resultatet av kallet er altså at objektreferansen o i linje 6 i dette tilfellet vil referere til samme objekt som det som ble gitt inn i kallet, i dette tilfellet den nylig opprettede bilen. Det eneste metoden så gjør, skjer i linje 7, hvor denne objektreferansen o (som altså nå viser til en bil) blir brukt som argument til et nytt kall, nå minsnylter.mottagave(o), som innebærer at snylteren bes om å motta den gaven rikingen vil gi bort. Her vil man Først sjekke hvilket objekt nr1.minsnylter viser til, dette viser seg å være snylter-instansen vist på figuren (i dette tilfellet har jo også begge rikingene samme snylter, men dette kunne ha vært annerledes)

4 Så kalle mottagave()-metoden for denne snylteren, linje Her er argumentet også Object o. Referansen o i mottagave-metoden vil ikke være samme variabel som referansen o i gigave-metoden, men de to variablene vil ha samme innhold, dvs begge vil komme til å referere til det samme objektet, nemlig den bilen som vi nettopp lagde med new Bil(...) Nå utføres altså denne metoden, og det eneste den gjør er å legge den mottatte bilen inn i ArrayList allemineting ved hjelp av metoden add(). Denne sistnevnte metoden slipper vi å skrive selv siden den fins i biblioteksklassen ArrayList det eneste man måtte huske i denne forbindelse var å importere denne klassen (linje 25). Som man også kan se i API en for ArrayList vil add(object o) legge inn det nye objektet bakerst i lista (for å legge inn noe annet sted enn bakerst, må man bruke en parameter til for posisjonen). Men her er lista foreløpig tom, så elementet havner uansett først (indeks 0). Situasjonen med forbindelsene mellom rikinger og snylteren er den samme som før, vi viser her kun den nye situasjonen for arraylista allemineting: En snylterinstans allemineting En ArrayListinstans 0 En Bilinstans En ArrayList vokser som kjent dynamisk etter behov, mens et array får en fast størrelse ved deklarasjon. Arraylista vil derfor på dette tidspunktet kun ha ett element, med indeks 0, og dette elementet vil inneholde en referanse til bil-instansen som vi overførte som argument i metodekallene. Bil-instansen vil inneholde tre private variable (hvorav en er arvet fra superklassen FremkomstMiddel og to er definert i Bil selv, jfr koden for disse hvis du gidder), som fikk verdi i og med konstruktorkallet, men disse gidder vi ikke å vise her fordi de ikke er spesielt viktige. De neste linjene vil funke helt på samme måte, av og til er det nr1 som gir, andre ganger nr2, men siden begge disse er koblet til den samme snylteren, vil alle gavene havne i den samme arraylista i tur og orden en bil til, en Pils, en Brus, en Sykkel (med toppfart 45), et Hus (234 kvm boareal) og en SpareKonto (med saldo ). Siden add()-metoden stadig legger inn nye objekter bakerst, vil vi etter linje 19 ha følgende situasjon: En snylterinstans allemineting En ArrayListinstans En Bilinstans En Bilinstans En Pilsinstans En Brusinstans En Sykkel-Einstans Husinstans En Spare- Kontoinstans Nå inneholder altså ArrayLista 7 forskjellige objekter, med indeks 0-6. Grunnen til at vi kan putte objekter av mange forskjellige typer inn i en og samme ArrayList, er at den internt representerer sitt innhold nettopp med referanser av den generelle typen Object, og som vi har sett ovenfor kan denne vise til hvilke objekter som helst. En annen stor fordel med å kunne benytte referanser av generelle typer som Object heller enn alltid å bruke de spesifikke typene som instansene faktisk har, viser seg også i metodene gigave() i NaivRiking og mottagave() i HeldigSnylter. Hvis vi ikke kunne ha brukt generelle referanser Object o som formelt argument i disse metodene, måtte vi ha skrevet en rekke forskjellige metoder: gibil(bil b), gihus(hus h), gipils(pils p),... og

5 tilsvarende mottabil(bil b), mottahus(hus h), mottapils(pils p), etc. noe som for det første hadde gitt oss langt mer kode å skrive, og som for det andre ville ha medført at vi også måtte ha lagt til to ekstra metoder hver gang det ble gjort en liten endring i main()-metoden med at rikingen begynte å gi en ny type gave. Den neste programsetninga (linje 20) gjør noe helt vanlig utskrift som vil komme ut på skjermen akkurat slik den står. Linje 21 skriver også ut, men her må kallet h1.skattbarformue() utføres før man vet hva som skal skrives ut. h1 viser til snylter-objektet, altså utføres nå metoden skattbarformue() i klassen HeldigSnylter (linje 34-46). Det vi her skal gjøre, er å beregne den totale skattbare formuen som snylteren besitter, som innebærer å summere opp den skattbare formuen for hver av eiendelene hans (som fins i arraylista allemineting). For å forklare det som skjer i denne metoden, kan det være en fordel å først vise en oversikt over hvordan grensesnittet Skattbar henger sammen med de involverte klassene: Skattbar Object Konto Hus Fremkomst -Middel Pils Brus Kreditt Konto Spare Konto Bil Sykkel I denne figuren er extends (dvs vanlig arv) vist som heltrukne linjer til pilene, dvs. f.eks KredittKonto extends Konto, Bil extends FremkomstMiddel, Hus extends Object. Arv fra Object er implisitt i Java, dvs man behøver ikke skrive extends Object for noen av klassene man definerer fordi dette vil skje uansett. Implementasjon av grensesnitt ( implements ) er vist ved prikkede linjer, dvs. man vil her ha Konto implements Skattbar, Hus implements Skattbar, Bil implements Skattbar. Konto har to subklasser, disse vil arve dette forholdet til Skattbar (akkurat som arv fra Object til Konto også vil forplante seg videre til subklassene til Konto). Poenget med grensesnittet Skattbar i dette eksemplet er: Man blir i stand til å definere fellestrekk mellom ulike klasser på tvers av arvehierarkiet (som representeres med heltrukne linjer), nemlig i dette tilfellet at akkurat konti, hus og biler er skattbare objekter, mens sykler, pils og brus ikke er det. Vi har tidligere sett at man kan referere til hus, biler, pils, brus etc via referanser av den generelle typen Object, fordi alle klasser er direkte eller indirekte subklasser av denne, jfr figuren. Poenget nå er at man på samme måte kan referere til Konto-objekter (inkludert kredittkonti og sparekonti), Hus-objekter og Bil-objekter gjennom referanser av typen Skattbar, fordi de alle implementerer dette grensesnittet (og man dermed er garantert at alle Konto-, Hus-, og Bil-objekter ville være i stand til å svare på et hvert metodekall som kunne rettes mot et Skattbar-objekt (i dette tilfellet kun metoden likningsverdi(), som alle disse tre klassene tvinges til å tilby kode for når de implements Skattbar ). F.eks. kunne man da skrive følgende programsetning: Skattbar s = new Hus(256); eller Skattbar s = new SpareKonto(1300); Altså: selv om det er umulig å instansiere noe objekt av typen Skattbar med new Skattbar(...) fordi dette ikke er noen klasse men et grensesnitt, kan man akkurat som for abstrakte klasser (som man heller ikke kunne instansiere noe av, jfr Konto i eksemplet AbstraktKontoTest) eller den generelle klassen Object, komme i kontakt med ulike slags objektinstanser via referanser av typen Skattbar, så sant disse objektene faktisk tilhører en klasse som implementerer dette grensesnittet. I eksemplet har vi ingen spesiell interesse av å skrive programsetninger a la de som står i kursiv like over her, men benytter muligheten til å kalle objekter for Skattbar på en måte som vil forklares når vi nå ser på metoden skattbarformue() steg for steg: Metoden begynner i linje 34, den skal returnere et heltall (int) og tar ingen argumenter. Utførelsen vil derfor kun basere seg på innholdet i den HeldigSnylter-instansen som metoden utføres for, i dette tilfellet den instansen som h1 viser til (som i dette eksemplet dessuten er den eneste snylter-instansen vi har), og som hadde en arrayliste allemineting som nå inneholder 7 objekter som snylteren fikk i gave. Metodens forløp er nå som følger:

6 Linje 35 deklarerer en variabel int sum = 0; Siden deklarasjonen her står inni metoden skattbarformue(), vil dette være en lokal variabel for denne metoden, dvs den er kun synlig inni metoden og dens levetid begrenser seg til en utførelse av denne metoden. Dette i motsetning til snylterobjektet selv og dens arraylist allemineting som her vil eksistere fra man gjør new HeldigSnylter og til programmet avsluttes. For-løkka linje 36 skal gå igjennom alle elementene i arraylista allemineting. økkevariabelen int i starter på 0 (som er indeksen til første element i lista). size() er en standardfunksjon i biblioteksklassen ArrayList, den returnerer antall elementer i den gitte lista, dvs. her antall elementer i lista allemineting, som er 7. Når betingelsen i løkka settes som i<7, vil siste i-verdi som kjøres gjennom løkka være i=6, som nettopp er indeksen for siste element i lista (siden indeksen starter på 0 er siste indeks generelt en mindre enn antall elementer) Innmaten i for-løkka (linje 38) skal nå summere inn likningsverdien for ett nytt element i lista for hver runde, sum +=... betyr det samme som sum = sum +...; Det som står på høyresida, har en avskrekkende mengde parenteser i forbindelse med en cast, men hvis vi nå forklarer det steg for steg, skal det forhåpentligvis være forståelig. Parentessetting her har samme hensikt som i matematiske uttrykk med addisjon og multiplikasjon, nemlig å sørge for at operasjoner blir utført i riktig rekkefølge. I figuren nedenfor er det illustrert hva som skjer, bare ikke de aller innerste parentesene, som burde være innlysende: (i) betyr rett og slett at i er argument for get-metoden, dvs. man skal ha elementet med indeks i (som begynner på 0). () etter likningsverdi viser at denne metoden har null argumenter. Mhp (Skattbar) viser parentesene at det foretas en cast i motsetning til om typenavnet hadde stått uten parentes rundt, da ville det ha signalisert en deklarasjon (eller med punktum bak aksessering av en statisk klassemetode) Viser at casten må utføres før vi gjør kallet likningsverdi(). Ellers blir dette et forsøk på å kalle likningsverdi() for noe av type Object, som vil gi kompileringsfeil. Etter casten har man derimot noe av typen Skattbar, og da er kallet likningsverdi() ok. Viser at allemineting.get(i) skal utføres før casten. Ellers ville casten ha blitt utført på allemineting som sådan, dvs et forsøk på å caste en ArrayList til Skattbar. Mens vi jo vil caste den objektreferansen vi får ut som det i te elementet i lista. ( (Skattbar) ( allemineting.get(i) ) ).likningsverdi(); Try-catch-blokka (linje 37, 39) er nødvendig fordi ikke alle snylterens eiendeler er skattbare. ArrayLista allemineting inneholder som vi har sett tidligere både skattbare objekter som hus, biler og ikkeskattbare objekter som pils, brus og sykler. Hadde vi derimot hatt en liste som bare besto av skattbare objekter, ville linje 38 alene ha vært tilstrekkelig som innmat i løkka. Så veldig mye vanskeligere blir det imidlertid ikke på grunn av denne komplikasjonen. Vi benytter oss av kunnskapen om at hvis en cast til Skattbar går galt (dvs et objekt viser seg å ikke stemme med den påståtte typen), vil kjøretidssystemet kaste en ClassCastException. I dette tilfellet er det ikke noe poeng i å skrive ut en feilmeldig i catch-delen vi vet jo her at det egentlig er helt normalt om casten skjærer seg for noen av objektene i lista. Try/catch brukes derfor her bare for å unngå å få feilmelding, og siden setningen sum += vil avbrytes uten å ha blitt utført de gangene casten går galt, vil vi unngå å summere inn noe tall de gangene det ikke fins noen likningsverdi å legge til. Derfor er det fornuftig rett og slett med en tom setning { bak catch. Med de 7 elementene vi har i lista (vist i en tidligere figur), vil for-løkka fungere på følgende måte: Første runde, i=0, vi får en Object-referanse til den første bilen ut av get(i)-metoden, denne castes til Skattbar og vi utfører kallet likningsverdi(). Kjøretidssystemet vil se at objektet egentlig er en bil og utfører likningsverdi()-metoden til denne klassen. Heltallet som returneres adderes inn i sum, som fra før var 0. Andre runde, i=1, finner den neste bilen, fortsettelsen blir tilsvarende punktet over. Heltallet som returneres adderes inn i sum, som fra før var likningsverdien for den forrige bilen (etterpå summen av likningsverdiene for de to bilene)

7 Tredje runde, i=2, get(i) gir oss en Object-referanse til et Pils-objekt. Vi prøver å caste dette til Skattbar, men dette gir feil fordi klassen Pils ikke implementerer grensesnittet Skattbar. Forsøket på å utføre sum +=... avbrytes dermed, og det blir kastet et unntak av typen ClassCastException verdien til sum blir ikke endret. Unntaket fanges i catch-delen, hvor vi ikke foretar oss noe som helst. Siden try/catchblokka her står inni løkka, vil vi på normalt vis gå videre med løkka etterpå (hvis try/catch derimot hadde stått utenfor løkka, ville vi ikke ha fått fullført summeringen hvis det gikk galt underveis). Fjerde runde, i=3, får en Object-referanse til et Brus-objekt. Samme hendelsesforløp som med Pils. Femte runde, i=4, får en Object-referanse til et Sykkel-objekt, samme hendelsesforløp som med Pils. Sjette runde, i=5, får en Object-referanse til et Hus-objekt. Her går casten bra fordi Hus implementerer Skattbar, og metoden likningsverdi() i klassen Hus blir utført. Heltallet som returneres plusses på det vi hadde fra før (som har vært uforandret siden andre runde). Sjuende runde, i=6, får en Object-referanse til et SpareKonto-objekt. Igjen går casten bra, nå fordi SpareKonto sin superklasse Konto implementerer Skattbar og dette arves av subklassene. Det er nå SpareKonto sin likningsverdi()-metode som blir utført i denne klassen står det ingen slik metode, men den er nettopp arvet fra Konto, dvs. det er metoden likningsverdi() som beskrevet i Konto som utføres i dette tilfellet. Kallet this.hentsaldo() betyr at man igjen kaller hentsaldo() for det samme objektet (this). Her kunne man selvsagt også ha skrevet return saldo; direkte, men den valgte varianten gjør det enda lettere å endre koden hvis man fant behov for å programmere om kontoen slik at saldoen ble representert på en annen måte (f.eks. at man ikke lenger ville lagre saldoen til enhver tid, men beregne denne fra saldoen ved siste månedsskifte og alle transaksjoner som var utført etterpå). Med det opplegget vi har valgt her, må kun hentsaldo()-metoden endres i dette tilfellet, mens bruk av return saldo; ville ha gjort at man også måtte endre metoden likningsverdi(). Kanskje ikke så viktig i dette konkrete eksemplet, men bare for å vise muligheten og gjøre oppmerksom på at det av og til kan være interessant å gjøre slike vurderinger slik at det ved behov skal bli så enkelt som mulig å endre koden. Etter at for-løkka er ferdig, returneres den summen man da endte opp med (linje 45), denne kommer tilbake til linje 21, hvor det brukes som argument til en utskriftssetning som er det siste som skjer i main-metoden. Med dette avsluttes programmet. Mer generelt om hva som er poenget med grensesnitt Som vi har sett fører bruk av grensesnitt ikke til at vi arver noe alle metoder må skrives fra grunnen av i de klassene som vil implementere et grensesnitt fordi det bare er metodehodene som står i selve grensesnittet. Hva har man da egentlig oppnådd? Kunne ikke Hus, Bil og Konto like gjerne hatt hver sin metode likningsverdi() uten at man behøvde å skrive implements Skattbar i tillegg, som her synes å være bare to ekstra ord å skrive, uten noen gevinst. Poenget er imidlertid noe av det samme som man også kan se med bruk av den generelle superklassen Object i dette eksemplet: vi oppnår å abstrahere oss bort fra spesifikke klasser. Den potensielle gevinsten er mest merkbar i klassen HeldigSnylter, hvor man kan observere at: De forskjellige klassene av objekter som snylteren kan få i gave fra rikingen (Bil, Hus, Pils,...), er overhodet ikke nevnt i koden i stedet nevnes kun Object og Skattbar. Dette gir for det første enklere kode. Vi greier oss med en metode mottagave(object o), og dette går bra fordi alle objekter vi kan gi inn i kallet vil være kompatible med Object. Hvis vi derimot skulle ha spesifisert gavetypen eksakt i denne metodedeklarasjonen, måtte vi ha skrevet mange forskjellige metoder: mottabil(bil b), mottahus(hus h) etc. På samme måte med bruken av Skattbar i for-løkka. Her kan vi ikke bruke Object, for denne klassen tilbyr ingen likningsverdi()-metode (og hvis vi ikke får kompilert programmet feilfritt, vil ikke polymorfi-mekanismen hjelpe oss). Største felles divisor for Hus, Bil og Konto er da nettopp typen Skattbar; ved å bruke denne greier vi oss med en enkelt cast inni for-løkka. Hvis vi ikke hadde hatt med implements Skattbar men bare hatt frittstående likningsverdi()-metoder i hver av disse klassene, måtte vi teste med if-setninger e.l. hvilken klasse det objektet vi fikk ut av get(i) egentlig var og deretter caste til Hus hvis det var et hus, til Bil hvis det var en bil, etc., og utføre kallet. Enklere kode er imidlertid ikke det eneste poenget, og kanskje ikke engang det viktigste. Vel så interessant er det avhengigheten mellom klassene NaivRiking og HeldigSnylter blir redusert, slik at programmet totalt sett blir mer fleksibelt for endringer. Hvis vi skulle ha hatt spesifikke metoder mottabil, mottahus etc., og gjort spesifikke cast til Bil, Hus, etc i for-løkka, ville vi også ha blitt nødt til å endre koden for klassen HeldigSnylter som følge av endringer i NaivRiking, f.eks. hvis NaivRiking også begynte å gi gaver som Fly, Båt, Elgsteik, Klokke,... måtte vi inkludere nye mottagave-metoder for dette, og nye alternative if-tester og cast-setninger for å behandle dette i for-løkka. Slik som vi har gjort det nå, kan koden i HeldigSnylter forbli upåvirket av introduksjon av nye gaveklasser, eller også fjerning av gaveklasser.

8 Nå er dette selvsagt et oppkonstruert eksempelprogram som ikke gjør noe nyttig et nyttig program som illustrerte det samme ville lett ha blitt for omfattende til å forklares på en forelesningstime. Men det som her er vist, er en generelt nyttig mekanisme, da man ofte kan ha en situsjon som vist nedenfor: Klasse som mottar objektene og gjør visse generelle metodekall mot dem Trenger bare vite om superklasser eller grensesnitt B A Klasse som produserer visse typer objekter (new...) Må forholde seg til de spesifikke klassene A1 A2 A3 Klasser som skal utføre new må nødvendigvis nevne navnet på det spesifikke klassene som det skal lages instanser av. Det samme gjelder hvis man f.eks. ønsker å kalle en metode som kun fins i subklassen A3, da må man nødvendigvis ha en objektreferanse som også er av type A3 (siden verken superklassen A eller grensesnittet B vil støtte denne metoden). Men vanligvis er det ikke alle klasser som har slike spesifikke behov. I et større programsystem vil det også gjerne finnes en del klasser som kun etterspør mer generelle tjenester fra diverse objekter, dvs. metoder som enten er støttet allerede av en superklasse eller av et grensesnitt (slik som er tilfelle med HeldigSnylter s omgang med gaver i dette eksemplet). Da trenger man ikke vite om hvilke spesifikke klasser objektene er instanser av, og ønsker heller ikke å vite det, fordi klassen blir mer fleksibel for endringer hvis slik detaljkunnskap ikke er innbakt i koden. I figuren er det nok at klassen til høyre vet om de spesifikke subklassene A1, A2, A3 (som den må, for å kunne skape riktig type instans med new), men når denne sender disse til klassen til venstre f.eks. som returverdi på et metodekall eller argument til et metodekall, kan referansen som er brukt for returverdien eller argumentet være de mer generelle A eller B. Kjøretidssystemet vil likevel sørge for at metoder blir kalt for riktig klasse i tilfeller hvor man har overlagring.