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 og enklere å gjenbruke. En klasse definerer hvilken tilstand og oppførsel instanser av klassen vil ha, hvor tilstanden er alle attributtene (i Java kalles det felt) og oppførselen er metodene (og reglene for hva de gjør). Med arv(ingsmekanismen) kan en si at en ny klasse utvider en eksisterende klasse, slik at instansene av den nye klassene får en tilstanden og oppførsel som er kombinasjonen av det som er definert i den eksisterende og den nye klassen. Et eksempel er vist i tabellen under, hvor en Book-klasse definerer attributtet title og Dictionary og CartoonAlbum utvider denne med henholdsvis attributtene wordcount og stripcount. class Book { String title; class Dictionary extends Book { int wordcount; Notasjon for arv: Dictionary og CartoonAlbum arver fra Book class CartoonAlbum extends Book { int stripcount; En instans av hver klasse, hvor Dictiona e har tilstand som delvis er arvet fra Boo Java-kode med bruk av nøkkelordet extends I eksemplet over vil Dictionary og CartoonAlbum begge være subklasser av Book, og omvendt så vil Book være superklassen til både Dic tionary og CartoonAlbum. Sammen danner de et klassehierarki, som i dette tilfellet er på to nivåer, men som generelt ikke har noe begrensninger på størrelsen. Arvingsmekanismen er i bunn og grunn enkel, men det kompliseres litt av to faktorer: sammenhengen mellom instansiering og typer og (deklarasjonen av) typen til variabler og tilordninger regler for oppførsel og innkapsling Instanser og typer, deklarasjoner og tilordninger De tre objektene identifisert som book1, nynorsk og flatfirer er instanser av hver sin klasse, henholdsvis Book, Dictionary og CartoonAlb um. Samtidig, og her starter gjerne forvirringen, så sier vi at nynorsk og flatfirer også er instanser av eller er av typen Book, fordi de har alle egenskapene til Book-instanser og derfor kan betraktes som slike. Hvis en f.eks. bruker instanceof-operatoren i Java så vil den virke som vist i tabellen under: object instanceof Class Book Dictionary CartoonAlbum book1 true false false nynorsk true true false flatfirer true false true Vi ser altså at alle objektene er instanceof Book og at book1 ikke er instanceof de to subklassene. Hvis en altså sier at et objekt er en instans av en bestemt type T, så betyr det ikke nødvendigvis at en brukte new T() for å lage den, men new <T eller en subklasse av T>(). Dette er analogt med at en kan si at et objekt er en instans av (grensesnittet) Iterator, selv om en en nødvendigvis ikke har brukt new Iterator() for å opprette objektet. Hvis en ønsker å si nettopp det at en brukte new T() så kan en kanskje si at objektet ble instansiert som T. Situasjonen er nokså tilsvarende med deklarasjoner og tilordninger. Når en deklarerer en variabel (eller felt eller parameter) til å være av en type T, så sier en at denne variablen bare kan tilordnes instanser av T, eller mer presist, at den bare kan tilordnes verdien av uttrykk som har typen T. I koden under vises ulike tilfeller og kommentaren angir om det er lov eller ikke og hvorfor.
Book book1 = new Book(); // OK siden new Book() gir et object av typen Book Book book2 = new Dictionary(); // OK siden new Dictionary() gir et objekt av typen Book Book book3 = new CartoonAlbum(); // OK siden new CartoonAlbum() gir et objekt av typen Book Dictionary dict1 = new Book(); // ikke OK siden new Book() ikke gir et object av typen Dictionary Dictionary dict2 = new Dictionary(); // OK siden new Dictionary() gir et objekt av typen Dictionary Dictionary dict3 = new CartoonAlbum(); // ikke OK siden new CartoonAlbum() ikke gir et objekt av typen Dictionary book1 = book2; // OK siden book2 er deklarert som Book og dette er samme type som book1-variablen book1 = dict1; // OK siden dict1 er deklarert som Dictionary og dette er en subklasse av typen til book1-variablen book1 = cartoon1; // OK siden cartoon1 er deklarert som CartoonAlbum og dette er en subklasse av typen som book1-variablen er deklarert som dict1 = book2; // ikke OK siden book2 er deklarert som Book og dette ikke er samme eller en subtype av Dictionary dict1 = dict2; // OK siden dict2 er deklarert som Dictionary og dette er samme type som dict1-variablen dict1 = cartoon1; // ikke OK siden cartoon1 er deklarert som CartoonAlbum og dette ikke er samme eller en subtype av Dictionary Regelen er altså at en variable (eller felt eller parameter) av type T bare kan tilordnes verdien av et uttrykk, når uttrykket har type T eller en subklasse av type T. Et vesentlig poeng er skillet mellom typen til uttrykket og typen til verdien av uttrykket, som er illustrert av følgende setninger: Book book = new Dictionary(); // OK, se over Dictionary dict = book; // ikke OK, selv om book faktisk refererer til en instans av Dictionary, så er det typen til book-variablen som sjekkes og som må være Dictionary eller en Dictionary-subklasse Typen til et uttrykk kan lese direkte av (typen til delene av) uttrykket, mens det andre krever at en kjører koden og ser hva slags verdi en faktisk får. Dersom en skal ha garantier om at noe alltid er lov, må en altså se på typen til uttrykket og ikke vente til kjøretid og sjekke typen til verdien av uttrykket. Dette ser en enklest med følgende setning: Dictionary dict = (Math.random() < 0.5? new Book() : new Dictionary()); // ikke OK, fordi typen til if-uttrykket er Book Selv om en i (omtrent) annenhvert tilfelle får en (referanse til en) Dictionary som verdi av uttrykket, så kan en bare garantere at resultatet blir en Book og da kan en ikke tillate tilordningen. Innkapsling Ved innkapsling så prøver en å sikre korrekt bruk av metoder og konsistent tilstand, bla. ved å sikre at tilstanden initialiseres og at argumenter valideres. Anta at Book er skrevet som vist under, for å kapsle inn tilstanden ordentlig:
public class Book { private String title; public Book(String settitle(title); public String gettitle() { return title; if (! <sjekk at title bare inneholder bokstaver og tall>) { IllegalArgumentException("Book titles can only contain letters and digits"); // Feil!!! private int wordcount; // ingen initialisering av titl public Dictionary(int wordcount this.wordcount = wordcount; // egen validering av title if (! <sjekk at title slutte på 'ordbok'>) { IllegalArgumentException("Dictiona titles must end with 'ordbok'"); Denne koden sikrer to ting: 1) at title-attributtet får en initiell verdi og 2) at title-verdien alltid er en String med kun bokstaver og tall. Dette påvirker ikke bare hva andre klasser kan gjøre med Book-instanser, men også hva Dictionary og CartoonBook kan gjøre med sine instanser, siden de jo også er Book-instanser og derfor må følge reglene for slike. F.eks. kan ikke subklassene utelate initialisering og heller ikke slakke på kravene som stilles til tegnene i en title. Koden i midten høyre prøver begge deler og må derfor avvises. Mer spesifikt vil en få feilmelding om at 1) konstruktøren ikke kaller en konstruktør i superklassen og 2) at title-attributtet ikke er synlig og derfor ikke kan settes i s ettitle-metoden. Alternativet er koden til høyre, hvor super-nøkkelordet brukes på to måter: 1) til å kalle superklassens konstruktør (kan bare gjøres i konstruktøren) og 2) til å kalle superklassens settitle-metode (kan gjøres i alle metoder). Innkapslingen i Book-klassen er imidlertid fortsatt vanntett, så Dictionary-klassen kan fortsatt ikke omgå valideringen i superklassens settitl e-metode og dermed slakke på kravene. Dette kan løses på to måter, enten ved å åpne opp for direkte tilgang til title-attributtet, men kun for subklasser eller ved å la subklassen redefinere valideringslogikken. Subklasse-synlighet med protected-modifikatoren Det finnes en egen synlighetsmodifikator som gir subklasser tilgang til attributter og metoder definert i en superklasse, nemlig protected. Dette kan brukes for å gi Dictionary-subklassen direkte tilgang til title-attributtet og dermed muligheten til å omgå valideringen:
public class Book { protected String title; if (! ) { IllegalArgumentException(); if (! ) { IllegalArgumentException(); // fordi title-attributtet er deklarert med protected, // så har vi nå lov til å endre det direkte Bruk og redefinering av metoder En annen teknikk for å la en subklasse definere alternative regler for oppførsel, er å skille ut logikk i egne metoder som kan redefineres. Anta f.eks. at en forutser behovet for å definere subklasse-spesifikke regler for gyldige title-verdier. Dette kan håndteres som vist under: public class Book { private String title; protected boolean isvalidtitle(string return <true hvis title bare inneholder bokstaver og tall, og false ellers> if (! isvalidtitle(title)) { IllegalArgumentException(); @Override protected boolean isvalidtitle(string return <true hvis title slutter på 'ordbok', og false ellers> I Book-koden over har en lagt valideringslogikken i en egen isvalidtitle-metode, som er gjort synlig for subklassene med protected-modifik atoren. Dictionary-klassen redefinerer denne metoden med sin egen logikk. Hvis en kaller settitle på et objekt instansiert som Book, så vil
Book-klassen sin isvalidtitle-metode bli kalt. Men dersom objektet er en Dictionary-instans, så vil (den redefinerte) metoden i Dictionary-k lassen bli brukt i stedet. Dermed kan Dictionary-spesifikke valideringsregler overstyre valideringsreglene i Book, som jo var intensjonen. Dic tionary-klassen får altså fortsatt ikke direkte tilgang til title-attributtet, men får lov til å endre/overstyre valideringslogikken. Ved hjelp av protected-modifikatoren og redefinering av metoder kan altså en superklasse tillate at visse regler endre/overstyres av en subklasse. Dersom subklassen ønsker å bruke reglene til superklassen, så kan en (selektivt) bruke metodekall med super-nøkkelordet. Dictionary-klassen kan f.eks. kalle super.isvalidtitle(title) hvis den ønsker å (gjen)bruke superklassens logikk. Sidetype Ferdig Dekningsgrad Omfang teori 95 50 50