public class NaivRiking { private HeldigSnylter minsnylter; public NaivRiking(HeldigSnylter h) { minsnylter = h;
|
|
- Dag Andreassen
- 8 år siden
- Visninger:
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.
Forklaring til programmet AbstraktKontoTest.java med tilhørende filer Konto.java, KredittKonto.java, SpareKonto.java
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Forklaring til programmet AbstraktKontoTest.java med tilhørende
Detaljer2 Om statiske variable/konstanter og statiske metoder.
Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.
DetaljerEnkle generiske klasser i Java
Enkle generiske klasser i Java Oslo, 7/1-13 Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo Del 1: Enkle pekere Før vi tar fatt på det som er nytt i dette notatet, skal vi repetere litt
DetaljerAlgoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1
Delkapittel 3.1 Grensesnittet Liste Side 1 av 11 Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1 3.1 En beholder 3.1.1 En beholder En pappeske er en beholder En beholder er noe vi kan legge ting
DetaljerLøsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF1000 - Høst 2011)
Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF1000 - Høst 2011) Løsningsforslag til oppgave 7, 8, og 9 mangler Klasser og objekter (kap. 8.1-8.14 i "Rett på Java" 3. utg.) NB! Legg merke til at disse
DetaljerINF1000 - Uke 10. Ukesoppgaver 10 24. oktober 2012
INF1000 - Uke 10 Ukesoppgaver 10 24. oktober 2012 Vanlige ukesoppgaver De første 4 oppgavene (Oppgave 1-4) handler om HashMap og bør absolutt gjøres før du starter på Oblig 4. Deretter er det en del repetisjonsoppgaver
Detaljerclass Book { String title; } class Dictionary extends Book { int wordcount; } class CartoonAlbum extends Book { int stripcount; }
Arv Arv (eng: inheritance) er en mekanisme for å bygge videre på eksisterende klasser og regnes ofte som varemerket til objektorientert programmering. Når arv brukes riktig, kan den gjøre koden ryddigere
DetaljerEksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus
// class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen
DetaljerINF1000 Metoder. Marit Nybakken marnybak@ifi.uio.no 16. februar 2004
INF1000 Metoder Marit Nybakken marnybak@ifi.uio.no 16. februar 2004 Motivasjon Når man begynner å skrive store programmer, vil man fort oppleve at programmene blir uoversiktlige. Det blir vanskeligere
DetaljerKonstruktører. Bruk av konstruktører når vi opererer med "enkle" klasser er ganske ukomplisert. Når vi skriver. skjer følgende:
Konstruktører Bruk av konstruktører når vi opererer med "enkle" klasser er ganske ukomplisert. Når vi skriver Punkt p = new Punkt(3,4); class Punkt { skjer følgende: int x, y; 1. Det settes av plass i
DetaljerArv. Book book1 = new Book(); book1. title = "Sofies verden" class Book { String title; } class Dictiona ry extends Book {
Arv Arv (eng: inheritance) er en mekanisme for å bygge videre på eksisterende klasser og regnes ofte som varemerket til objektorientert programmering. Når arv brukes riktig, kan den gjøre koden ryddigere
DetaljerTDT4100 Objektorientert programmering
Eksamensoppgave i TDT4100 Objektorientert programmering Torsdag 12. august 2010, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikret av Svein Erik Bratsberg. Kontaktperson
DetaljerINF1010 Arv. Marit Nybakken marnybak@ifi.uio.no 2. februar 2004
INF1010 Arv Marit Nybakken marnybak@ifi.uio.no 2. februar 2004 Motivasjon Arv bruker vi så vi skal slippe å skrive oss i hjel. Når vi programmerer, prøver vi gjerne å modellere en del av verden ved hjelp
Detaljer13.09.2012 LITT OM OPPLEGGET. INF1000 EKSTRATILBUD Stoff fra uke 1-3 12. September 2012 Siri Moe Jensen EKSEMPLER
.9.22 LITT OM OPPLEGGET INF EKSTRATILBUD Stoff fra uke - 2. September 22 Siri Moe Jensen Målgruppe: De som mangler forståelse for konseptene gjennomgått så langt. Trening får du ved å jobbe med oppgaver,
DetaljerPost-it spørsmål fra timen (Arv og subklasser)
Post-it spørsmål fra timen 30.01 (Arv og subklasser) Tegning Spørsmål: Skjønte ikke tegningene Hater tegningene. Lær meg å tegne. Mvh frustrert elev. Spørsmål: Datastruktur-tegning, og hvor mye detaljer
DetaljerTDT4102 Prosedyre og Objektorientert programmering Vår 2014
Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:
DetaljerArray&ArrayList Lagring Liste Klasseparametre Arrayliste Testing Lenkelister
Dagens tema Lister og generiske klasser, del I Array-er og ArrayList (Big Java 6.1 & 6.8) Ulike lagringsformer (Collection) i Java (Big Java 15.1) Klasser med typeparametre («generiske klasser») (Big Java
DetaljerLæringsmål for forelesningen
Læringsmål for forelesningen Objektorientering Abstrakte klasser og grensesnitt, redefinering av metoder Java-programmering Arv og bruk av abstrakte klasser Eclipse Undersøke instanser i Eclipse 1 Dagens
Detaljer2 Om statiske variable/konstanter og statiske metoder.
Gaustadbekkdalen, januar 22 Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo Innledning Dette notatet beskriver noe av det som foregår i primærlageret når
DetaljerJavaScriptbibliotek. Introduksjon MVVC. Informasjonsteknologi 2. Gløer Olav Langslet Sandvika VGS
MVVC JavaScriptbibliotek Gløer Olav Langslet Sandvika VGS Knockout.js Informasjonsteknologi 2 Introduksjon I dag skal vi se nærmere på et JavaScriptbibliotek som heter Knockout. Knockout og andre biblioteker,
DetaljerKanter, kanter, mange mangekanter
Kanter, kanter, mange mangekanter Nybegynner Processing PDF Introduksjon: Her skal vi se på litt mer avansert opptegning og bevegelse. Vi skal ta utgangspunkt i oppgaven om den sprettende ballen, men bytte
DetaljerINF1000 : Forelesning 4
INF1000 : Forelesning 4 Kort repetisjon av doble (nestede) løkker Mer om 1D-arrayer Introduksjon til 2D-arrayer Metoder Ole Christian Lingjærde Biomedisinsk forskningsgruppe Institutt for informatikk Universitetet
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO BOKMÅL Det matematisk-naturvitenskapelige fakultet Eksamen i : Eksamensdag : Torsdag 2. desember 2004 Tid for eksamen : 09.00 12.00 Oppgavesettet er på : Vedlegg : Tillatte hjelpemidler
Detaljeri=0 i=1 Repetisjon: nesting av løkker INF1000 : Forelesning 4 Repetisjon: nesting av løkker Repetisjon: nesting av løkker j=0 j=1 j=2 j=3 j=4
Repetisjon: nesting av løkker Kort repetisjon av doble (nestede) løkker Mer om D-arrayer Introduksjon til D-arrayer Metoder Ole Christian Lingjærde Biomedisinsk forskningsgruppe Institutt for informatikk
DetaljerINF1010, 22. mai Prøveeksamen (Eksamen 12. juni 2012) Stein Gjessing Inst. for Informatikk Universitetet i Oslo
INF, 22. mai 23 Prøveeksamen 23 (Eksamen 2. juni 22) Stein Gjessing Inst. for Informatikk Universitetet i Oslo Oppgave a Tegn klassehierarkiet for de 9 produkttypene som er beskrevet over. Inkluder også
DetaljerArgumenter fra kommandolinjen
Argumenter fra kommandolinjen Denne veiledningen er laget for å vise hvordan man kan overføre argumenter fra kommandolinjen til et program. Hvordan transportere data fra en kommandolinje slik at dataene
DetaljerUtførelse av programmer, metoder og synlighet av variabler i JSP
Utførelse av programmer, metoder og synlighet av variabler i JSP Av Alf Inge Wang 1. Utførelse av programmer Et dataprogram består oftest av en rekke programlinjer som gir instruksjoner til datamaskinen
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Side 1 Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1010 Objektorientert programmering Eksamensdag: Onsdag 4. juni 2014 Tid for eksamen: 9:00-15:00 Oppgavesettet er på
DetaljerLæringsmål for forelesningen
Læringsmål for forelesningen Objektorientering Håndtering av unntak (eng: exceptions) Java-programmering Håndtering av unntak Exception-objekter og klasser try, catch og finally throw og throws Eclipse
DetaljerVerden. Steg 1: Vinduet. Introduksjon
Verden Introduksjon Processing Introduksjon Velkommen til verdensspillet! Her skal vi lage begynnelsen av et spill hvor man skal gjette hvilke verdensdeler som er hvor. Så kan du utvide oppgava til å heller
DetaljerArray&ArrayList Lagring Liste Klasseparametre Arrayliste Testing Lenkelister Videre
Dagens tema Lister og generiske klasser, del I Array-er og ArrayList (Big Java 6.1 & 6.8) Ulike lagringsformer (Collection) i Java (Big Java 15.1) Klasser med typeparametre («generiske klasser») (Big Java
Detaljeri=0 Repetisjon: arrayer Forelesning inf Java 4 Repetisjon: nesting av løkker Repetisjon: nesting av løkker 0*0 0*2 0*3 0*1 0*4
Forelesning inf - Java 4 Repetisjon: arrayer Tema: Løkker Arrayer Metoder Ole Christian Lingjærde,. september Deklarere og opprette array - eksempler: int[] a = new int[]; String[] a = new String[]; I
DetaljerForelesning inf Java 4
Forelesning inf1000 - Java 4 Tema: Løkker Arrayer Metoder Ole Christian Lingjærde, 12. september 2012 Ole Chr. Lingjærde Institutt for informatikk, 29. august 2012 1 Repetisjon: arrayer Deklarere og opprette
DetaljerLæringsmål for forelesningen
Læringsmål for forelesningen Objektorientering Bruk av grensesnitt og implementasjoner i Collection-klasser Java-prog, kap. 14-16 i Big Java Og side 990-997 i Appendix D Collection-rammeverket og iterasjon
DetaljerDet du skal gjøre i denne oppgava er først å sette opp bakgrunnen til spillet og så rett og slett å få firkanter til å falle over skjermen.
Tetris Introduksjon Processing Introduksjon Lag starten på ditt eget tetris spill! Det du skal gjøre i denne oppgava er først å sette opp bakgrunnen til spillet og så rett og slett å få firkanter til å
Detaljerprogrameksempel Et større En større problemstilling Plan for forelesingen Problemstillingen (en tekstfil) inneholdt ordet "TGA"
Et større programeksempel Hvordan løse et reelt problem med en objektorientert fremgangsmåte En større problemstilling I uke 4 skrev vi et program for å sjekke om et gen (en tekstfil) inneholdt ordet "TGA"
DetaljerKapittel 7: Mer om arv
Kapittel 7: Mer om arv Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag,
DetaljerTetris. Introduksjon. Skrevet av: Kine Gjerstad Eide. Lag starten på ditt eget tetris spill!
Tetris Skrevet av: Kine Gjerstad Eide Kurs: Processing Introduksjon Lag starten på ditt eget tetris spill! Det du skal gjøre i denne oppgava er først å sette opp bakgrunnen til spillet og så rett og slett
Detaljernotater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS
Mine notater Gløer Olav Langslet Sandvika VGS Et praktisk eksempel med objekter Vi kjenner alle til korktavlen med gule lapper. Vi henger opp en lapp for at vi selv eller andre skal huske eller bli minnet
DetaljerAv Stein Gjessing, Institutt for informatikk, Universitetet i Oslo
Gaustadbekkdalen, januar 27 Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo Innledning Dette notatet beskriver noe av det som foregår inne i primærlageret
DetaljerInnhold uke 4. INF 1000 høsten 2011 Uke 4: 13. september. Deklarasjon av peker og opprettelse av arrayobjektet. Representasjon av array i Java
INF høsten 2 Uke 4: 3. september Grunnkurs i Objektorientert Programmering Institutt for Informatikk Universitetet i Oslo Siri Moe Jensen og Arne Maus Mål for uke 4: Innhold uke 4 Repetisjon m/ utvidelser:
DetaljerINF Notater. Veronika Heimsbakk 10. juni 2012
INF1010 - Notater Veronika Heimsbakk veronahe@student.matnat.uio.no 10. juni 2012 1 Tilgangsnivåer 2 CompareTo Modifier Class Package Subclass World public Y Y Y Y protected Y Y Y N no modifier Y Y N N
DetaljerINF1010 Sortering. Marit Nybakken 1. mars 2004
INF1010 Sortering Marit Nybakken marnybak@ifi.uio.no 1. mars 2004 Dette dokumentet skal tas med en klype salt og forfatter sier fra seg alt ansvar. Dere bør ikke bruke definisjonene i dette dokumentet
DetaljerTOD063 Datastrukturer og algoritmer
TOD063 Datastrukturer og algoritmer Øving : 3 Utlevert : Uke 7 Innleveringsfrist : 26. februar 2010 Klasse : 1 Data og 1 Informasjonsteknologi Gruppearbeid: 2-3 personer pr. gruppe. Oppgave 1 Vi skal lage
DetaljerEKSAMENSFORSIDE Skriftlig eksamen med tilsyn
BOKMÅL EKSAMENSFORSIDE Skriftlig eksamen med tilsyn Emnekode: 108 + 108N Dato: 19.12.201 Ansv. faglærer: Roy M. Istad Campus: Bø Antall oppgaver: 5 Tillatte hjelpemidler (jfr. emnebeskrivelse): Alt trykt
DetaljerOblig 4Hybelhus litt mer tips enn i oppgaven
Oblig 4Hybelhus litt mer tips enn i oppgaven lørdag 19. okt 2013 Arne Maus Obligatorisk oppgave 4 Gulbrand Grås husleiesystem I denne oppgaven skal vi se på hans studenthus Utsyn. Utsyn består av 3 etasjer,
DetaljerOversikt. INF1000 Uke 1 time 2. Repetisjon - Introduksjon. Repetisjon - Program
Oversikt INF1000 Uke 1 time 2 Variable, enkle datatyper og tilordning Litt repetisjon Datamaskinen Programmeringsspråk Kompilering og kjøring av programmer Variabler, deklarasjoner og typer Tilordning
DetaljerRepitisjonskurs. Arv, Subklasser og Grensesnitt
Repitisjonskurs Arv, Subklasser og Grensesnitt Subklasser Klasser i OO-programmering representerer typer av objekter som deler et sett med egenskaper. En subklasse har egenskapene til en klasse + ett sett
DetaljerVerden - Del 2. Steg 0: Oppsummering fra introduksjonsoppgaven. Intro
Verden - Del 2 Nybegynner Processing Intro Denne oppgaven bygger på oppgaven med samme navn som ligger på introduksjonsnivå her i Processingoppgavene. Klikk her for å gå til introduksjonsoppgaven av verden.
DetaljerVerden. Introduksjon. Skrevet av: Kine Gjerstad Eide og Ruben Gjerstad Eide
Verden Skrevet av: Kine Gjerstad Eide og Ruben Gjerstad Eide Kurs: Processing Tema: Tekstbasert Fag: Matematikk, Programmering, Samfunnsfag Klassetrinn: 8.-10. klasse, Videregående skole Introduksjon Velkommen
DetaljerIN1010 V19, Obligatorisk oppgave 2
IN1010 V19, Obligatorisk oppgave 2 Innleveringsfrist: Tirsdag 26.02 kl 23.59 Introduksjon I de obligatoriske oppgavene fremover skal du lage et system som holder styr på leger, pasienter, resepter og legemidler.
DetaljerDiverse eksamensgaver
Diverse eksamensgaver Noen har fått den idé å lage et språk hvor klasser kan ha noe tilsvarende byvalue-result -parametere. Klasser har ingen konstruktører, og by-value-result parametere spesifiseres som
DetaljerEKSAMEN I FAG TDT4100 Objekt-orientert programmering. Fredag 3. juni 2005 KL. 09.00 13.00
Side 1 av 6 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap EKSAMEN I FAG
Detaljerif-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS
Løkker og if-tester Gløer Olav Langslet Sandvika VGS 29.08.2011 Informasjonsteknologi 2 Funksjoner, løkker og iftester Læreplansmål Eleven skal kunne programmere med enkle og indekserte variabler eller
DetaljerJentetreff INF1000 Debugging i Java
Jentetreff INF1000 Debugging i Java Ingrid Grønlie Guren ingridgg@student.matnat.uio.no 11. november 2013 Kort om feilmeldinger i Java Java har to ulike type feilmeldinger som man kan få når man skriver
DetaljerFra Python til Java, del 2
Fra Python til Java, del 2 Hvordan kjøre Java? På Ifis maskiner På egen maskin Et eksempel Array-er For-setninger Lesing og skriving Metoder Biblioteket Hva trenger vi egentlig? Å kjøre Java For å kunne
Detaljer23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.
Grunnkurs i objektorientert programmering Introduksjon til objektorientert programmering INF1000 Høst 2015 Siri Moe Jensen INF1000 - Høst 2015 uke 5 1 Siri Moe Jensen INF1000 - Høst 2015 uke 5 2 Kristen
DetaljerInformasjon Eksamen i IN1000 høsten 2017
Informasjon Eksamen i IN000 høsten 207 Tid 8. desember kl. 09.00 (4 timer) Faglærerne vil besøke lokalet ca kl 0. Oppgavene Oppgave 2b og 2c er flervalgsoppgaver. Her får man det angitte antall poeng om
DetaljerKanter, kanter, mange mangekanter. Introduksjon: Steg 1: Enkle firkanter. Sjekkliste. Skrevet av: Sigmund Hansen
Kanter, kanter, mange mangekanter Skrevet av: Sigmund Hansen Kurs: Processing Tema: Tekstbasert, Animasjon Fag: Matematikk, Programmering, Kunst og håndverk Klassetrinn: 8.-10. klasse, Videregående skole
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1010 Objektorientert programmering Dato: 9. juni 2016 Tid for eksamen: 09.00 15.00 (6 timer) Oppgavesettet er på 7 sider.
DetaljerOblig4 - forklaringer. Arne og Ole Christian
Oblig4 - forklaringer Arne og Ole Christian Struktur og alle (?) klassene import easyio.*; import java.util.*; class Oblig4 { public static void main (String[] args) { String s1 = "Stasjoner-1.txt"; String
DetaljerINF1000 Behandling av tekster
INF1000 Behandling av tekster Marit Nybakken marnybak@ifi.uio.no 23. februar 2004 Tekster Vi kommer nesten aldri utenom å bruke tekststrenger i programmene våre, ikke minst fordi det nesten alltid skal
DetaljerKort om meg. INF1000 Uke 2. Oversikt. Repetisjon - Introduksjon
Kort om meg INF1000 Uke 2 Variable, enkle datatyper og tilordning Fredrik Sørensen Kontor: Rom 4311-NR, Informatikkbygget Brukernavn/e-post: fredrso@ifi.uio.no Utdanning: Dataingeniør, 2000 Cand.Scient,
DetaljerKapittel 8: Programutvikling
Kapittel 8: Programutvikling Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF1010 Objektorientert programmering Dato: 9. juni 2016 Tid for eksamen: 09.00 15.00 (6 timer) Oppgavesettet er på 7 sider. Vedlegg:
DetaljerLøsningsforslag til Eksamen i fag SIF8005 Programmering. Torsdag 10. mai 2001 kl
Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni Løsningsforslag
DetaljerBOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs
BOKMÅL Side 1 av 7 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap KONTINUASJONSEKSAMEN
DetaljerOO-eksempel. Modellen ser slik ut: Studenter + antstudenter : int = 0
OO-eksempel I eksemplet er det deklarert tre klasser: 1) Fag (skal instansieres ett objekt for hvert fag) 2) Student (skal instansieres ett objekt for hver student) 3) Studenter (abstrakt klasse skal ikke
DetaljerINF1010 - Seminaroppgaver til uke 3
INF1010 - Seminaroppgaver til uke 3 Oppgave 1 I denne oppgaven skal vi lage et klassehiearki av drikker. Alle klassene i hiearkiet skal implementere følgende grensesnitt p u b l i c i n t e r f a c e Drikkbar
DetaljerHva er verdien til variabelen j etter at følgende kode er utført? int i, j; i = 5; j = 10; while ( i < j ) { i = i + 2; j = j - 1; }
Hva er verdien til variabelen j etter at følgende kode er utført? int i, j; i = 5; j = 10; while ( i < j ) { i = i + 2; j = j - 1; Hva skrives ut på skjermen når følgende kode utføres? int [] tallene =
DetaljerProgrammering i C++ Løsningsforslag Eksamen høsten 2005
Programmering i C++ Eksamen høsten 2005 Simen Hagen Høgskolen i Oslo, Avdeling for Ingeniørutdanning 7. desember 2005 Generelt Denne eksamensoppgaven består av tre oppgaver, pluss en ekstraoppgave. Det
DetaljerIntroduksjon til objektorientert programmering
Introduksjon til objektorientert programmering Samt litt mer om strenger og variable INF1000, uke6 Ragnhild Kobro Runde Grunnkurs i objektorientert programmering Strategi: Splitt og hersk Metoder kan brukes
DetaljerToPlayer. Steg 1: Kom i gang med metodene setup og draw. Gjør dette: Introduksjon:
ToPlayer Introduksjon Processing Introduksjon: Nå skal vi lage et spill som to personer kan spille mot hverandre. Vi har kalt det ToPlayer, men du kan kalle det hva du vil. Målet er å dytte en figur, eller
DetaljerSteg 1: Lag bildedeklarasjon
Bildepresentasjon Skrevet av: Ruben Gjerstad Eide og Kine Gjerstad Eide Kurs: Processing Tema: Tekstbasert, Animasjon Fag: Programmering, Kunst og håndverk Klassetrinn: 8.-10. klasse, Videregående skole
DetaljerGeneriske mekanismer i statisk typede programmeringsspråk
Generiske mekanismer i statisk typede programmeringsspråk Dette stoffet er Pensum, og det er bare beskrevet her Mye her er nok kjent stoff for mange INF5110 7. mai 2013 Stein Krogdahl 1 Hvordan kunne skrive
DetaljerMattespill Nybegynner Python PDF
Mattespill Nybegynner Python PDF Introduksjon I denne leksjonen vil vi se litt nærmere på hvordan Python jobber med tall, og vi vil lage et enkelt mattespill. Vi vil også se hvordan vi kan gjøre ting tilfeldige.
DetaljerOblig 4 (av 4) INF1000, høsten 2012 Værdata, leveres innen 9. nov. kl. 23.59
Oblig 4 (av 4) INF1000, høsten 2012 Værdata, leveres innen 9. nov. kl. 23.59 Formål Formålet med denne oppgaven er å gi trening i hele pensum og i å lage et større program. Løsningen du lager skal være
DetaljerToPlayer. Introduksjon: Skrevet av: Ruben Gjerstad Eide og Kine Gjerstad Eide
ToPlayer Skrevet av: Ruben Gjerstad Eide og Kine Gjerstad Eide Kurs: Processing Tema: Tekstbasert Fag: Matematikk, Programmering Klassetrinn: 8.-10. klasse, Videregående skole Introduksjon: Nå skal vi
DetaljerDagens forelesning. Java 13. Rollefordeling (variant 1) Rollefordeling (variant 2) Design av større programmer : fordeling av roller.
Dagens forelesning Java 13 Design av større programmer : fordeling av roller INF 101-13. mars 2003 Flere eksempler på bruk av objekter MVC-prinsippet MVC-prinsippet Flere eksempler på programmer med objekter
DetaljerINF1000 EKSTRATILBUD. Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen
INF1000 EKSTRATILBUD Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen PLAN FOR DAGEN gjennomgå stoff fra uke 1-5(6), men med en litt annen tilnærming kun gjennomgått stoff, men vekt på konsepter og
DetaljerHvor i All Verden? Del 2 Erfaren Scratch PDF
Hvor i All Verden? Del 2 Erfaren Scratch PDF Introduksjon Hvor i All Verden? er et reise- og geografispill hvor man raskest mulig skal fly innom reisemål spredt rundt i Europa. Dette er den andre leksjonen
DetaljerHvordan skrive Flok og Flass kode? I mange tilfelle er det svært enkelt:
Hvordan skrive Flok og Flass kode? I mange tilfelle er det svært enkelt: inchar INC inint INI Tegnet eller tallverdien kommer i I registeret. outchar OUTC outint (n) OUTI n outline OLIN I Flink maskinen
DetaljerEn algoritme for permutasjonsgenerering
Innledning La oss tenke oss at vi har en grunnskole-klasse på 25 elever der enkelte av elever er uvenner med hverandre. Hvis uvenner sitter nær hverandre blir det bråk og slåssing. Er det mulig å plassere
DetaljerUNIVERSITETET I OSLO
Side 1 UNIVERSITETET I OSLO Kandidatnr Det matematisk-naturvitenskapelige fakultet Eksamen i: PRØVEEKSAMEN INF1000 Eksamensdag: Prøveeksamen 22.11.2011 Tid for eksamen: 12:15-16:15 Oppgavesettet er på
DetaljerOppsummering. Kort gjennomgang av klasser etc ved å løse halvparten av eksamen Klasser. Datastrukturer. Interface Subklasser Klasseparametre
Oppsummering Kort gjennomgang av klasser etc ved å løse halvparten av eksamen 2012. Klasser Interface Subklasser Klasseparametre Datastrukturer Hva er problemet? Oppgaven Emballasjefabrikken Renpakk skal
Detaljer1. Finn klassene (hvilke objekter er det i problemet) 1. Dataene som beskriver problemet (hvilke objekter har vi og hvor mange klasser er det?
Obligatorisk oppgave 3 Gulbrand Grås husleiesystem Oblig 3hus litt mer tips enn i oppgaven I denne oppgaven skal vi se på hans studenthus Utsyn. Utsyn består av 3 etasjer, nummerert fra -3. I hver etasje
DetaljerAlgoritmer og datastrukturer A.1 BitInputStream
Vedlegg A.1 BitInputStream Side 1 av 8 Algoritmer og datastrukturer A.1 BitInputStream A.1 BitInputStream A.1.1 Instansiering BitInputStream har fire konstruktører og to konstruksjonsmetoder (eng: factory
DetaljerINF1000: Forelesning 7
INF1000: Forelesning 7 Klasser og objekter del 2 Konstruktører Static UML REPETISJON 2 Repetisjon Repetisjon forts. Verden består av objekter av ulike typer (klasser). Ofte er det mange objekter av en
DetaljerSprettende ball Introduksjon Processing PDF
Sprettende ball Introduksjon Processing PDF Introduksjon: I denne modulen skal vi lære et programmeringsspråk som heter Processing. Det ble laget for å gjøre programmering lett for designere og andre som
DetaljerINF1000: Forelesning 4. Mer om arrayer Metoder
INF1000: Forelesning 4 Mer om arrayer Metoder MER OM ARRAYER 2 Array som en samling verdier Anta at vi ønsker å lagre en liste med navnene på alle INF1000-studentene: String[] studenter = new String[500];
DetaljerMAT-INF 1100: Obligatorisk oppgave 1
3. september, 2004 MAT-INF 1100: Obligatorisk oppgave 1 Innleveringsfrist: 17/9-2004, kl. 14:30 Informasjon Den skriftlige besvarelsen skal leveres på ekspedisjonskontoret i 7. etg. i Niels Henrik Abels
DetaljerINF1010 våren 2008 Uke 4, 22. januar Arv og subklasser
Emneoversikt subklasser INF1010 våren 2008 Uke 4, 22. januar Arv og subklasser Stein Gjessing Institutt for informatikk Mange flere eksempler på fellesøvelsene og neste forelesning 1 Generalisering - spesialisering
DetaljerRepetisjon: Statiske språk uten rekursive metoder (C1 og C2) Dagens tema Kjøresystemer (Ghezzi&Jazayeri 2.6, 2.7)
Dagens tema Kjøresystemer (Ghezzi&Jazayeri.6,.7) Repetisjon Språk med rekursjon (C3) og blokker (C4) Statisk link Dynamisk allokering (C5) Parameteroverføring 1/5 Repetisjon: Statiske språk uten rekursive
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Kandidatnr Eksamen i INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Onsdag 1. desember 2010 Tid for eksamen: 14.00 18.00
Detaljerklassen Vin må få en ny variabel Vin neste alle personvariable (personpekere) i listeklassen må byttes til Vin
INF1010 forelesning Lenkelister II Dette skrivet inneholder en oversikt over det jeg planlegger å forelese på andre forlesning om lenkelister. Det inneholder stort sett programeksempler med kommentarer
DetaljerEks 1: Binærtre Binærtretraversering Eks 2: Binærtre og stakk
Godkjent oblig 1? Les e-post til din UiO-adresse Svar på e-post fra lablærer Ingen godkjenning før avholdt møte med lablærer Godkjentlistene brukes ikke til å informere om status for obligene Ta vare på
DetaljerJava PRP brukermanual
Java PRP brukermanual 1.1 Introduksjon 1.1.1 Hva er Java PRP Java PRP (Parallel Recursive Procedure) gir oss muligheten til automatisk parallellisering av programmer, som baserer seg på noen rekursive
DetaljerDagens tema Kjøresystemer (Ghezzi&Jazayeri 2.6, 2.7)
Dagens tema Kjøresystemer (Ghezzi&Jazayeri 2.6, 2.7) Repetisjon Språk med rekursjon (C3) og blokker (C4) Statisk link Dynamisk allokering (C5) Parameteroverføring 1/25 Forelesning 11 5.11.2003 Repetisjon:
Detaljer1- og 2-veis Innkapsling Java Stabel Kø Prio-kø Iterator. Enveis- og toveislister Innkapsling («boxing») (Big Java 6.8.5)
Dagens tema Litt mer om vanlige lister Enveis- og toveislister Innkapsling («boxing») (Big Java 6.8.5) Nyttige varianter av lister: Stabler («stacks») (Big Java 15.5.1) Køer («queues») (Big Java 15.5.2)
DetaljerObligatorisk oppgave 4: Lege/Resept
Obligatorisk oppgave 4: Lege/Resept INF1010 Frist: mandag 27. mars 2017 kl. 12:00 Versjon 1.0 (111c894 ) Innhold 1 Innledning 1 1.1 Begreper................................ 2 2 Pasienter 2 3 Leger og lister
Detaljer