În java există 3 comportamente legate de subiectul dvs.:
- (documente oficiale aici)
- supraîncărcare (documentația oficială este secțiunea "Metode de supraîncărcare")
- ascundere (documentația oficială aici)
Deoarece documentația spune că:
Metoda principală are același nume, numărul și tipul parametrilor și tipul retur. O suprascrie de tipul returnat de metoda suprascrisa. Acest subtip este denumit un tip de returnare covariante.
iar în cazul tău ați încălcat numărul de regulă și tipul parametrilor. atunci se pare că nu este suprasolicitat. În același timp, în ceea ce privește supraîncărcarea, este scris:
Limba de programare Java suportă metode de supraîncărcare, iar Java poate face distincție între metodele cu semnături diferite de metode. Acest lucru înseamnă că metodele au același nume dacă au liste de parametri diferite (există anumite calificări care vor fi discutate în lecția intitulată "Interfețe și moștenire").
Ce este relevant pentru situația dvs. Astfel, prin apelarea metodei cu referința Pair, veți apela metoda de clasă Pair. în ciuda faptului că este, de fapt, obiectul Detail.
În plus, java are un mecanism de urmărire a unor astfel de neînțelegeri sub forma adnotărilor @Override, marcând-o cu o metodă, compilatorul va arunca o eroare în cazul în care nu este suprascrisă. În cazul dvs.:
Compilatorul va returna o eroare "Metoda nu suprascrie metoda din superclajul său".
Ei bine, în cele din urmă, pentru a obține o clasă reală în clasa Detail, metoda ar trebui să arate astfel:
În acest caz, veți obține rezultatul așteptat.
Sper că am reușit să explic totul în detaliu. Mult noroc în studiul suplimentar =).
Pentru a înțelege ce se întâmplă, trebuie să clarificați câteva concepte:
Perezruzka. Puteți avea două metode în aceeași clasă cu același nume, dar cu diferiți parametri.
Supracomandarea. Este necesar să se potrivească complet tipurile de parametri de intrare.
Moștenirea. Oferă câmpuri și metode pentru clasa parentală
Aceasta nu este o definiție a noțiunilor de supraîncărcare, redefinire și moștenire, ci doar câteva puncte relevante pentru această problemă.
În cazul tău, obiectul Detail are două variante ale metodei getObject. unul este cel pe care l-ați definit explicit în clasă. public void getObject (data o). iar al doilea pe care la primit de la părinte ca rezultat al moștenirii. public void getObject (Obiect o).
Atunci când VM trebuie să determine ce metodă să invocăm, se uită la tipul de parametru pe care l-ați trimis la metodă și pe tipul acestui parametru alege opritorul corespunzător de suprasarcină.
Urmând această logică, ați putea crede că trebuie apelată o metodă cu parametrul Date. Dar tu faci tipuri de distribuție:
O listă de metode pentru obiect este întotdeauna determinată de tipul indicatorului. Și din moment ce tipul de pointer aveți acum Pair și are doar o singură versiune a acestei metode, atunci el sa oferit voluntar. Ei bine, și din moment ce ia Obiectul, atunci Data "a înghițit" fără să se răcească. " Singura metodă disponibilă pentru Pereche a fost getObject (Object).
A răspuns la 8 august, ora 2:00
Nu este chiar așa. Dacă în acest exemplu Pair are parametrul Date setat ca parametru de intrare sau dacă Object este setat la Object, va fi afișat mesajul "Text from Detail". și nu "Textul din pereche", în ciuda tuturor acestor tipuri de indicii. de dragul interesului, puneți data în pereche și obiect în detaliu - rezultatul va fi același ca și pentru TC, deși logica dvs. a fost influențată de faptul că Object a înghițit Data - Alexey Shimansky 8 august la 6:15
@ Alexey Shimansky nu, nu ați înțeles corect explicația mea. Ce Obiect înghițit Data înseamnă că nu există probleme cu tipurile de turnare. Și logica mea indică faptul că lista de metode este determinată de tipul indicelui, iar în cazul metodelor de renaștere acest lucru este, de asemenea, adevărat. - Pavel Aug 8 la 21:58
Trimiteți-le prietenilor: