Ett kompendium om arv och gränssnitt

More documents

Recommendations

Info

• 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
Page 1 and 2: 3 Arv och gränssnitt 3.1 Vad inneb
Page 3 and 4: 3.4 Åtkomstregler vid arv Klasser
Page 5: Anrop av det nya: Anrop av det göm
Page 9 and 10: En klass som innehåller en eller f
Page 11: denna begäran till implementations

Ett kompendium om arv och gränssnitt

Create successful ePaper yourself

Delete template?

Save as template?