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 <ClassName> [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). Rectangle void draw(); double area(); ColourRectangle void draw(); Color getcolor(); 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 <InterfaceName> [extends SuperInterfaceList] { //Konstantdeklarationer <Typ> <Konstantnamn>=<värde>[,<Konstantnamn>=<värde>]; } //Deklaration av abstrakta metoder <ReturTyp> <Metodnamn> ( [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.