Ebből értettél egy szót is? Komolyan??? Na lássuk:
Tehát "egyértelműen kinyilvánított felcímkézése egy metódus felülbírálatának" - na ez már annyira érthető, mint az első magyarított Windows-hibaüzenetek. Fussunk neki másképp!
A korábbiakban sokszor csináltunk saját toString metódust az örökölt toString override-olásával: Arra is emlékszel, hogy az Eclipse ezt jelzi is egy kis zöld háromszöggel:
No, de mi van akkor, ha véletlenül valamit kihagytunk, vagy elgépeltünk? Például csak annyi, hogy toString helyett tostring lett - az S kisbetűs. Nos, akkor ez egy sima egyszerű új metódus, és nincs kis zöld háromszög, mert nincs override:
A következő lépés pedig, hogy hangosan bosszankodunk, hogy "nééézd meg, itt van a tostring de mégsem ezt írja ki a program, hanem hogy Sor@232dfa23".
Valljuk be, ilyen apró kis elgépelés előfordulhat, nem?
A programba tehetünk emberi fogyasztásra szánt megjegyzéseket:
private double felszolgaltMeret=5; // ez itt deciliterben van
és tehetünk gépi fogyasztásra szánt megjegyzéseket is, ezek a @ karakterrel kezdődnek:
@Override
public String toString() {
return nev+", "+felszolgaltMeret+" deci, "+alkoholTartalomSzazalek+"%";
}
Az @Override a leggyakrabban használt ilyen annotáció. Ez azt jelenti, hogy "Igen ezt a metódust tényleg override-olni szeretném".
Ha így írjuk a dolgot, és minden helyes, akkor semmi sem történik. De ha elrontjuk, és esetleg olyan metódus nevet írunk, ami nincs az ős-osztályban, és emiatt nem override-olunk, hanem egy picit más néven egy új metódust hozunk létre:
no akkor panaszkodik, és egyből látjuk, hogy ott biza valami nem stimmel!
Tehát akkor az explicit override annotáció azt jelenti, hogy minden override-olni kívánt metódusra kitesszük az @Override annotációt, hogy egyértelműen kinyilvánítsuk, hogy ott bizony mi override-olni akarunk, és szóljon, ha valami miatt ez nem lehetséges.
Feladat: javítsd ki a Kocsma példa összes osztályában az override-okat explicit override annotációval!