Arv, forkrav, datainvariant og substitusjonsprinsippet

Arv – oppsummering

class Sub extends Super

Sub arver fra Super:

Sub blir en sub-type av Super
- objekter av sub-klassen kan brukes alle steder du forventer noe av super-klassen
Sub får alle feltvariabler og metoder (inkl kode) som Super har
Sub implementerer alle interfaces som Super implementerer
Når du lager et Sub-objekt, må konstruktøren kalle konstruktøren til super-klassen
En klasse kan bare ha én superklasse (i Java) – og Object er superklasse til alle klasser som ikke har en oppgitt superklasse. Det er lov å ha mange subklasser.
Superklassen kan igjen ha en superklasse osv.

class Impl implements Interface

Impl implementerer Interface:

Impl må ha alle metoder fra Interface.
Impl implementerer også alle grenesnitt som Interface utvider (extends)
Impl blir en sub-type av Interface
- objekter av Impl kan brukes alle steder der du forventer objekter av Interface-typen.
Mange klasser kan implementere samme grensesnitt.
Et grensesnitt sier ingenting om konstruktør eller feltvariabler, og inneholder ingen kode, og det kan ikke lages objekter av det (dvs. new Interface() er ikke lov)

Å implementere et grensesnitt har altså en del til felles med å arve fra en klasse, men det er også en del ting som er forskjellig.

Noe som må være sant før du kan kalle en metode
Forkravet sier hvilke argumenter som er gyldige
Brutt forkrav resultere som oftest i IllegalArgumentException eller en annen exception.
Det er generelt best å sjekke forkrav selv, og kaste en passende exception.
Viktigst: Dokumenter forkravene for den som skal bruke klassen (med JavaDoc).
Helst: Sjekk forkravene på begynnelsen av metoden, og gi en feilmelding med én gang om noe er galt.

En invariant er et uttrykk som skal være det samme hver gang det blir regnet ut.
Klasseinvarianten er et uttrykk som skal være sant hver gang en public metode blir kalt eller returnerer.
Klasseinvarianten forteller om et objekt er konsistent eller ikke, dvs. om feltvariablene har gyldige verdier.
At klasseinvarianten er oppfylt, er også et forkrav til alle public metoder.
Alle public metoder skal ha som egenskap at de opprettholder klasseinvarianten.
Vi kan lage en metode som sjekker klasseinvarianten – den metoden vil da fortelle oss om et objekt er konsistent (at kombinasjonen av verdier til feltvariablene er gyldig).
Viktigst: Dokumenter klasseinvarianten for den som implementerer klassen (kommentar).
Nyttig: Sjekk klasseinvarianten før du returnerer fra konstruktøren og public metoder. Da vil du kunne oppdage inkonsistente objekter så tidlig som mulig.
Husk: Så lenge feltvariablene er private, kan de bare endres av klassens metoder. Dvs. at du bare trenger å sjekke at klassens egne public metoder opprettholder klasseinvarianten, siden dette er eneste stedet det kan skje endringer som evt. kan bryte den.

class Sub extends Super eller class Sub extends Interface

Forkrav: forkrav i Sub kan ikke være sterkere enn forkrav i Super/Interface. Det er i orden om Sub-klassen har svakere forkrav.
Oppførsel: Sub-klassen må minst gjøre det Super-klassen gjør / det som er spesifisert av Interface. Dvs., objekter av subklassen må kunne passere alle testene du har for superklassen.

Dette betyr at et Sub-objekt alltid kan brukes der du forventer et Super- eller Interface-objekt, og det vil virke minst like bra.

Dette er Liskovs substitusjonsprinsipp.

Alle metoder (inkl konstruktør) i subklassen må opprettholde superklassens klasseinvariant (dette følger av regelen om at subklassens oppførsel skal være kompatibel med superklassens).
Hvis Sub har en egen klasseinvariant (som er strengere enn den til Super), så må alle metodene oppretteholde den, også de som man arver fra Super. Hvis de ikke gjør det, så må de overstyres (@Override) av subklassen slik at de gjør det. (Dette er hovedsaklig et problem hvis Sub har egne feltvariabler.)

Eksempel: Klassen Kanin arver fra Dyr, og har en ekstra feltvariabel, tannLengde.

Hvis vi krever at tannLengde >= 0, så er Kanins klasseinvariant at Dyrs klasseinvariant er oppfylt, pluss at tannLengde >= 0.
Vi vet at alle metodene i Dyr også vil tilfredsstille tannLengde >= 0, fordi klassen Dyr ikke kjenner til tannLengde og kan derfor ikke sette den til noe ulovlig.
Hvis vi derimot krever at det skal være et spesielt forhold mellom tannLengde og vekt (fra Dyr), må vi overstyre alle metodene fra Dyr i Kanin, og sørger for at de opprettholder dette forholdet. Ellers vil f.eks. spis()-metoden endre vekt uten å gjøre en tilsvarende endring i tannLengde.