Ett kompendium om arv och gränssnitt

3 Arv och gränssnitt
3.1 Vad innebär arv?
Ett objektorienterat språk bygger på att programmeraren ges möjligheten att modellera
verkligheten med hjälp av objekt. Objekt låter sig definieras i form av klasser. Liksom i
de flesta objektorienterade språk så tillåter även Java att klasser definieras utifrån andra
klasser. Det är detta som är arv.
Arv innebär att man skapar en ny klass (subklass) utifrån en redan existerande klass
(superklass, basklass).
I en objektorienterad terminologi kan vi därför påstå att bilar, motorcyklar, traktorer,
grävskopor och bulldozer är olika typer av motorfordon. Motorfordon utgör således en
superklass till de andra fordonen vilka i sin tur är subklasser till motorfordon.
Varje subklass ärver superklassens egenskaper (fält) och beteende (metoder). Normalt
lägger man dock till nya egenskaper (nya fält) och utökar beteendet (nya metoder).
För att dra en parallell till exemplet ovan så har en grävskopa bl a en metod för att kunna
gräva, detta utgör då ett utökat beteende i förhållande till superklassen motorfordon som
inte har detta beteende.
Subklasser kan också omdefiniera superklassens egenskaper och beteende, detta är en
viktig mekanism vid arv.
För att återgå till exemplet så har alla motorfordon ett inbyggt beteende - att kunna köra
framåt. När du som användare av en motorcykel vill köra framåt vrider du på styrets
gashandtag med handen, vill du åstadkomma samma effekt med en bil trycker du på
gaspedalen med foten. I detta ligger en viktig skillnad. För att kunna använda beteendet
att köra framåt hos olika typer (subklasser) av motorfordon framåt så krävs att detta
beteende implementeras på olika sätt för olika subklasser av motorfordon. Subklasser
tillhandahåller specialiserade beteenden med utgångspunkt i de gemensamma element
som ges av superklassen.
Ett bra sätt för att avgöra om ett arv är lämpligt eller inte är att sätta samman påståendet:
"Subklassen är en/ett superklass ". Om påståendet är jakande så är arvet sannolikt
motiverat annars inte. Ett undantag skulle givetvis kunna uppträda om man idkat dålig
namnsättning på klasserna.
Arv bidrar bl a till
• att skapa en relation (är en/ett) mellan klasserna.
• att kunna återanvända kod (klasser). Detta är speciellt påtagligt i Java då språket
innehåller massor med fördefinierade klasser och gränssnitt. (Javas API)
• modularisering genom att strukturera program i generell och specialiserad kod.
• att det blir lättare att underhålla mjukvaran.
• att det blir lättare att vidareutveckla mjukvaran.

3.2 Syntax vid arv
I Java kan man endast ärva från en superklass (enkelt arv). Dock kan man samtidigt ärva
ett godtyckligt antal s.k. gränssnitt (interface).
Arv av en superklass indikeras med nyckelordet extends och arv av gränssnitt indikeras
med nyckelordet implements.
[public] [abstract|final] class
[extends SuperClass] [implements InterfaceList]
{
[Constructors] // initialiseringsmetod(er)
[Fields] // Fält
[Methods] // och metoder
}// i godtycklig ordning
Nyckelorden abstract och final betyder att klassen inte kan instansieras och att den inte
kan ärvas respektive. Mer information om abstrakta klasser finns i avsnittet Abstrakta
klasser.
Om man inte anger något arv (dvs. extends saknas) så kommer ändå klassen som
deklareras att ärva automatiskt från klassen Object, vilken är en fördefinierad klass i Java
som innehåller en del generella metoder som alla klasser skall ha.
3.3 Generella åtkomstregler
Vad gäller kontroll av åtkomst så finns public, protected, private och default = "åtkomst
inom paketet” att tillgå. För att använda sig av default-åtkomst så utelämnar man
åtkomstmodifieraren. Konstruktorer, fält och metoder kan använda sig av alla
accessdeklarationer medan klasser endast kan använda sig av public och default.
default (”paket åtkomst”): Åtkomsten som man får om man inte anger någon
åtkomstmodifierare ger full tillgänglighet inom eget paket men ingen åtkomst utanför.
public: Klasser, interface och medlemmar som är publika är åtkomliga överallt förutsatt
att paketet där de deklareras har importeras. Dock är publika medlemmar som ligger i en
klass som endast har default-åtkomst normalt inte åtkomliga utanför det paketet där de är
deklarerade.
private: Medlemmar som är privata är endast åtkomliga inom den egna klassen.
protected: Medlemmar som har skyddad åtkomst är fullt tillgängliga inom eget paket.

3.4 Åtkomstregler vid arv
Klasser måste vara publika för att kunna ärvas av klasser i andra paket. Har klassen
default-åtkomst så kan den bara ärvas inom eget paket.
I en subklass ärvs alla medlemmar av superklassen med de restriktioner som
åtkomstmodifierarna i superklassen sätter. Medlemmar som är public nedärvs som public.
Samma sak gäller även för de medlemmar som är protected. Det som är intressant med
medlemmar som har åtkomstmodifieraren protected är att dessa nedärvs även av
subklasser som tillhör ett annat paket. M a o medlemmar med skyddad åtkomst
(protected) i en publik klass vilken ärvs av klasser i andra paket nedärvs inom dessa
subklasser. Vid arv så frångås alltså åtkomstmodifieraren protected sin generella
restriktion att gälla endast inom det egna paketet. Vill man att en medlem av en klass
endast skall kunna ärvas inom det egna paketet använder man default-åtkomst.
Medlemmar som är private är inte åtkomliga ens för subklasser.
Ett ord om private-medlemmar som inte ärvs. I litteraturen anges ofta att de medlemmar
som är private inte nedärvs. Detta är en sanning med modifikation. En superklass är alltid
en delmängd av en subklass, detta betyder att subklassen faktiskt består av hela
superklassen (inklusive de medlemmar som är private) med eventuellt utökade
egenskaper och beteenden. Det enda som åtkomstmodifieraren private egentligen
åstadkommer är an accessrestriktion.
3.5 Konstruktorer vid arv
Konstruktorer ärvs inte.
Om ett objekt instansieras utifrån en subklass så kommer denna att anropa superklassens
konstruktor, om superklassen i sin tur är en subklass till en annan klass så kommer denna
att anropa dess konstruktor o s v. Eftersom en arvshierarki kan vara hur djup som helst så
kommer den konstruktor som ingår i den "överst liggande" superklassen att exekvera
först. Konstruktorn för den klass man instansierar ett objekt utav kommer att exekvera
sist.
Om man inte deklarerar någon konstruktor explicit så skapas en defaultkonstruktor som
endast anropar en defaultkonstruktor i superklassen. En defaultkonstruktor innehåller
endast satsen:
super();
Om en superklass har en explicit deklarerad konstruktor som skiljer sig från
defaultkonstruktorn, så måste denna också explicit anropas med en super-sats i
subklassens konstruktor. Om superklassen har flera konstruktorer så måste åtminstone en
av dem anropas explicit såvida inte en av dem är defaultkonstruktorn. Denna kan då
anropas automatiskt av subklassen.

Om en konstruktor initialiserar en variabel så överrider det eventuell initialisering i
variabeldeklarationen.
3.6 Utökning och modifiering av beteende
I Java finns det tre viktiga begrepp som har att göra med hur man kan utöka och
modifiera en klass. Dessa begrepp är
• gömma (hide)
• omdefiniera (redefine) även kallat överrida (override)
• överlagra (overload)
Man kan gömma fält och klassmetoder. Att gömma fält innebär att man i subklassen
deklarerar fält med samma namn som finns i superklassen. Då har man gömt
superklassens fält. Att gömma en klassmetod innebär att man i subklassen deklarerar en
klassmetod med samma returtyp, namn och parametrar som i superklassen, men med en
annan implementation. Fält och klassmetoder kan endast gömmas, de kan inte
omdefinieras eller tas bort.
Man kan omdefiniera instansmetoder. Att omdefiniera en instansmetod innebär att man i
subklassen deklarerar en instansmetod med samma returtyp, namn och parametrar som i
superklassen, men med en annan implementering.
Man kan överlagra metoder. Att överlagra metoder (klassmetoder och instansmetoder)
innebär att man deklarerar ytterligare metoder med samma namn som en befintlig metod,
men med andra parametrar och annan implementering. Överlagring kan göras både av
ärvda metoder (rekommenderas ej!) och egna metoder.
3.7 Gömmande av fält och klassmetoder
Det som kännetecknar gömmande är att det som gömts ”fortfarande finns kvar” i den
meningen att åtkomst fortfarande är möjlig enligt deklarerade åtkomst regler. För att
komma åt en instansvariabel som gömts kan man använda en referensvariabel av
superklassens typ eller göra en explicit typecast. Detta gäller även för klassvariabler och
klassmetoder, dock kan dessa givetvis också accessas direkt utan att något objekt
existerar.
Antag att vi har en gömd instansvariabel ”storlek”, en gömd klassvariabel ”maxStorlek”
och en gömd klassmetod ”AndraMaxStorlek()”som ursprungligen deklarerats i klassen
Bild, men som gömts av subklassen Foto. Vi befinner oss i en tredje klass som har
åtkomst till klasserna Bild och Foto och vi har en referensvariabel ”aktuelltFoto” av
klasstypen Foto som refererar till ett objekt av klassen Foto. Då kan vi komma åt de
gömda sakerna på följande sätt:

Anrop av det nya: Anrop av det gömda:
Bild aktuellBild = (Bild)aktuelltFoto;
int s = aktuelltFoto.storlek; int s = aktuellBild.storlek;
int ms = Foto.maxStorlek int ms = Bild.maxStorlek;
Foto.andraMaxStorlek(); Bild.andraMaxStorlek();
3.7.1 Regler vid gömning
Fält:
• Fält som gömmer behöver inte ha samma typ som det gömda fältet.
• En instansvariabel kan gömma en klassvariabel och tvärtom.
• Gömmande av fält bör undvikas eftersom det lätt leder till svårbegripliga program
där man lätt blandar ihop olika variabler med samma namn. Oftast går det inte att
motivera gömmande av fält, detta brukar oftast tyda på att den som gjort det tror
att gömmandet omdefinierar superklassens fält vilket det inte gör.
Metoder:
• En klassmetod kan ej gömma en instansmetod, ej heller kan en instansmetod
gömma en klassmetod eftersom detta skulle innebära att man försöker
omdefiniera en klassmetod vilket inte är tillåtet.
• Returtyp och argument måste vara samma för den metod som gömmer som för
originalet och undantag som kastas måste överensstämma.
• Accessen till den gömmande medlemmen måste vara större än eller lika med
accessen till originalet.
3.8 Omdefinition av instansmetoder
Det som kännetecknar omdefinition är att den omdefinierade metoden (gamla metoden)
”inte finns kvar” i den meningen att den är oåtkomlig från utsidan av klassen. Den gamla
metoden är dock fortfarande åtkomlig inom klassen. Detta för att möjliggöra att den
omdefinierande metoden (nya metoden) ska kunna använda den gamla metodens
implementation om den vill. Anrop till den gamla metoden sker med hjälp av super:
super.GammalMetod();
Det är viktigt att betydelsen av en metod bibehålls vid omdefinition. I annat fall får man
svårhanterliga program.
3.8.1 Regler vid omdefinition
• Endast instansmetoder kan omdefinieras. En instansmetod kan inte omdefiniera
en klassmetod.

• Omdefinierade metoder måste ha samma signatur (dvs. samma namn och
parametrar) och samma returtyp som originalet i superklassen. Dessutom måste
exakt samma undantag deklareras i throws-satsen.
• Utifrån kommer man alltid att anropa de omdefinierade metoderna på ett objekt
oavsett om man sätter referenstypen till subklassen eller superklassen.
• Konstruktorn ärvs inte och kan således inte omdefinieras.
• Metoder som är final kan inte omdefinieras.
• Metoder som är private kan aldrig omdefinieras.
• Accessrättigheterna för det som omdefinieras/göms måste vara lika eller större än
för det som göms.
3.9 Överlagring av metoder
• Överlagring och omdefiniering sker var för sig i Java. Detta är en skillnad mellan
Java och C++.
• Överlagrade metoder måste ha samma namn och måste ha olika parametrar samt
kan ha olika returtyp. Throws-satserna kan vara olika, dvs. olika undantag kan
kastas.
• Vid ett anrop till överlagrade metoder så bestäms vilken metod man ska ta genom
att titta på metodernas signatur (dvs. namn och parametrar). Returtypen kan som
sagt vara olika mellan de överlagrade metoderna.
• Överlagrade metoder som ärvs kan omdefinieras var och en för sig. De metoder
som inte omdefinieras ärvs som de är. Ärvda metoder bör dock överhuvudtaget
inte överlagras eftersom det leder till svårläst kod.
• Omdefinierade metoder kan överlagras, men detta bör undvikas.
3.10 Objektreferenser i samband med arv
Fall 1: konvertering av objektreferenser uppåt i arvshierarkin.
Om man har en objektreferens till ett objekt av en subklass, så kan denna objektreferens
användas i alla sammanhang där en referens till någon av klassens superklasser kan
användas. Det sker en implicit typkonvertering (cast) i detta fall då man går uppåt i
arvshierarkin.
Fall 2: konvertering av objektreferenser nedåt i arvshierarkin.
En motsatt situation är om man har en referensvariabel som är typad för en superklass,
men som innehåller ett referensvärde till en subklass, och man vill tilldela detta
referensvärde till en annan referensvariabel som är typad för subklassen. I detta fall måste
man göra en explicit cast, och då bör man först testa med instanceof-operatorn för att
försäkra sig om att cast:en är möjlig att göra.

Sådana explicita casts nedåt i arvshierarkin enligt fall 2 bör man försöka undvika. Ofta
leder dessa typkonverteringar till att man lyckas generera ett ClassCastException, detta är
också ett fel som uppstår under exekvering, varför risken finns att man kraschar sitt
program. Situationer där man kan frestas till detta går ofta att lösa med polymorfism om
man från början tänker på det.
3.11 Polymorfism
Polymorfism är en hörnsten i objektorienterad programmering. Det betyder ”många
former”. I Java har alla metoder automatiskt stöd för polymorfism och det krävs inte
något speciellt nyckelord för att beskriva att en metod skall ha möjligheten att vara
polymorf.
Den stora fördelen med polymorfism är att programmeraren inte behöver bry sig om att
kontrollera typer, systemet sköter detta. Polymorfism kan realiseras på olika sätt för olika
programmeringsspråk och kan därför ges olika innebörder rent praktiskt. I Java har
polymorfism implementerats med s.k. dynamisk bindning, det som är dynamiskt är
typbestämmandet av ett objekt. Typen för ett objekt kan alltså avgöras under exekvering.
Vad är nu detta bra för?
Detta är bra p g a att "rätt" metod kan anropas "automatiskt". I Java utnyttjas
polymorfism vid arv (liksom i de flesta objektorienterade språk).
ColourRectangle
void draw();
Color getColor();
Rectangle
void draw();
double area();
ImageRectangle
void draw();
void rotate();
VideoRectangle
void play();
void stop();
I figuren ovan ses en arvshierarki där vi har tre subklasser av superklassen Rectangle.
Polymorfism bygger på att vi i subklasserna omdefinierar metoder som ärvs av

superklassen. Som ses av figuren ovan så omdefinierar två av subklasserna superklassens
draw() - metod.
Fördelen med detta är att jag kan skapa en referensvariabel till superklassen Rectangle
och tilldela denna ett objekt av en subklass.
Rectangle cr = new ColorRectangle(…);
cr.draw();
Trots att cr är deklarerad som en referensvariabel till superklassen Rectangle så
kommer anropet till dess draw() - metod att innebära ett anrop till den draw() - metod
som finns implementerad i klassen ColorRectangle. Detta p g a att
objektet som tilldelats referensvariabeln cr typbestämms vid exekvering.
public void handleRectangle (Rectangle r)
{
…
r.draw();
…
}
Metoden handleRectangle demonstrerar ytterligare nyttan med polymorfism då
denna kan anropas med alla objekt av typen Rectangle eller subklasser härav som
argument. Om metoden anropas med en subklass som ej har omdefinierat metoden
draw() så kommer superklassens metod att anropas.
Obs! Endast metoder som deklarerats i superklassen kan anropas på detta sätt:
r.rotate(); går inte!
3.12 Abstrakta klasser och metoder
En önskvärd egenskap att ha hos en generell basklass är att kunna definiera metoder som
saknar implementation.
Antag att vi har en basklass Figur, vi vet att vi vill ha en metod rita(), men det är
meningslöst att försöka implementera denna då vi inte vet vad för sorts figur som skall
ritas. Om vi däremot gör en subklass Kvadrat till Figur så kan vi ge metoden rita() en
implementation eftersom vi vet exakt hur en kvadrat skall ritas. Genom att inte ge någon
implementation av metoden rita() i klassen Figur vill vi tvinga alla subklasser att
implementera denna.
De metoder som saknar implementation och bara innehåller namn, returtyp och
parametrar deklareras som abstrakta.

En klass som innehåller en eller flera abstrakta metoder måste deklareras som abstrakt.
Klasser och metoder deklareras som abstrakta med hjälp av nyckelordet abstract.
En abstrakt klass kan inte instansieras (eftersom den helt eller delvis saknar exekverbar
kod), det förutsätts att den ärvs och att subklassen implementerar de metoder som är
abstrakta. Att deklarera en abstrakt metod är ett sätt att tvinga en subklass att
tillhandahålla en implementation av metoden. Om subklassen inte tillhandahåller en
implementation av alla abstrakta metoder i superklassen så måste även subklassen
deklareras som abstrakt.
En klass kan deklareras som abstrakt även om full implementering finns av alla metoder,
men en sådan klass går trots detta inte att instansiera.
En abstrakt klass kan lämpligen användas när man vill ha en generell basklass, och det
inte är möjligt att ge en generell implementation av alla samtliga metoder. (Om samtliga
metoder måste göras abstrakta så är det sannolikt bättre att använda gränssnitt.)
3.13 Gränssnitt (Interface)
Gränssnitt kan endast innehålla abstrakta metoder och konstanter.
Gränssnitt tillämpas typiskt på så sätt att man definierar ett gränssnitt för varje typisk
egenskap som man vill ge en klass, t.ex. Cloneable, Drawable, Storeable, … .
Gränssnittet definierar signatur och returtyp för alla metoder som behövs för egenskapen
ifråga, men ingen implementering.
En klass som vill ha en sådan egenskap måste då implementera motsvarande gränssnitt.
Java tillåter att ett godtyckligt antal gränssnitt implementeras i en klass (multipelt arv av
gränssnitt), så att man kan ge en klass många olika egenskaper. En klass kan alltså
samtidigt ärva högst en klass men ett godtyckligt antal gränssnitt.
En klass som implementerar ett gränssnitt måste implementera samtliga metoder i
gränssnittet.
En referensvariabel vars typ är en gränssnittstyp kan användas för att referera till alla
objekt som implementerar gränssnittstypen ifråga.
Ett gränssnitt kan ärva ett eller flera gränssnitt, så att man kan bygga upp gränssnitt
hierarkiskt.

3.14 Gränssnittsdeklaration
[public] interface
[extends SuperInterfaceList]
{
//Konstantdeklarationer
=[,=];
}
//Deklaration av abstrakta metoder
( [Formella parametrar] )
[throws Exceptionklasser];
Nyckelordet extends anger arv. Ett obegränsat antal superinterface kan ärvas. Klasser kan
inte ärvas av gränssnitt.
Alla medlemmar (konstanter och metoder) i ett interface har implicit åtkomsten public,
och är åtkomliga i vilket paket som helst förutsatt att interfacet har åtkomsten public.
Alla konstanter är implicit public, static och final. Dessa modifierare ska alltså inte anges.
Alla metoder är implicit public och abstract. Dessa modifierare ska heller inte anges.
3.15 Skillnader mellan arv och gränssnitt
• När man ärver en klass ärver man både en specifikation och en implementation,
såvida inte klassen är helt abstrakt.
• När man implementerar ett gränssnitt så ärver man endast en specifikation.
• Varför kan man inte använda en helt abstrakt klass lika väl som ett gränssnitt?
• Arv bör användas då ett verksamhetsmässigt släktskap mellan klasser råder. Om
ett sådant finns så är det osannolikt att en generell basklass inte kan tillhandahålla
någon implementation alls.
• Gränssnitt används för generella, ofta tekniska egenskaper som många orelaterade
klasser ska kunna stödja, ett gränssnitt kan jämföras med ett protokoll. Ett
gränssnitt påtvingar inte en klass ett släktskap. Exempel på gränssnitt är
Storeable, Drawable, Sendable, Observable etc.
• Om många klasser använder ett visst gränssnitt och implementationen i klasserna
är någorlunda lika så måste detta gränssnitts implementation upprepas i alla
klasser. Detta är inte i enlighet med objektorienteringens filosofi, att skapa
återanvändbar kod. Lösningen är att koden för att implementera gränssnittet läggs
i en egen klass, och alla andra klasser som behöver detta gränssnitt skapar ett
objekt av denna klass. När en metod i gränssnittet anropas så vidarebefordras

denna begäran till implementationsobjektet som då hanterar anropet. Denna
teknik kallas delegering.
• Rent praktiskt så är gränssnitt också ett sätt att ge en klass fler utökade egenskaper
och beteenden än vad som kan ges med ett enkelt arv.
• Ytterligare en skillnad som är viktig är att arvshierarkin för ett gränssnitt och
arvshierarkin för en klass är oberoende. Klasser som implementerar samma
gränssnitt kan men behöver inte ha ett släktskap. Detta är en viktig skillnad i
jämförelse med multipelt arv, vilket påtvingar ett släktskap.
3.16 Inre klasser
• Det är tillåtet i Java att deklarera klasser (s.k. inre klasser) inuti klasser. De inre
klasserna ligger alltså inbäddade i en annan klass och har ingen egen fil. Sådana
inre klasser är bara åtkomliga inuti den klass de ligger i. Där kan den inre klassen
instansieras.
• En inre klass kan implementera gränssnitt och ärva andra klasser på samma sätt
som vanliga klasser.
• Inre klasser ska användas endast till tydligt avgränsade uppgifter som endast berör
den klass de ligger i. Exempel på sådana uppgifter är implementering av
gränssnitt eller händelselyssnare.
• En inre klass kan definieras direkt efter new-satsen där den instansieras. Detta
kallas "inline" definition.
• Klasser som behöver användas på många ställen i en applikation ska inte vara inre
klasser.