Il senso delle interfacce di Java?

[Loue]

Salve,

mi chiedevo a cosa servono le interfacce di Java... sto studiando la parte teorica di questo ambiente e l'ereditarietà multipla è permessa solo tra interfacce, secondo le mie fonti.
Guardando la definizione di interfaccia (=signature dei metodi della classe), mi chiedevo il senso di questa cosa. In pratica la classe ereditata da più interfacce non eredita un bel niente... , deve ridefinire tutto come se ereditasse da una classe astratta. Anzi, deve anche implementare tutto.

E poi ripensavo al principio di sostituibilità: "È sempre possibile usare un oggetto di una sotto-classe al posto di un oggetto di una classe base".

Ora mi chiedo: ma se la sottoclasse ridefinisce un metodo della derivata, la cosa vale ancora?

Grazie dell'attenzione!!

[andbin]

Originariamente inviato da Loue
In pratica la classe ereditata da più interfacce non eredita un bel niente... , deve ridefinire tutto come se ereditasse da una classe astratta. Anzi, deve anche implementare tutto.

Una interfaccia è da vedere come se fosse una classe astratta "al 100%". Quando vedi il termine "abstract" devi pensare a un qualcosa di "incompleto" .... che quindi devi completare tu! Le interfacce e in casi minori le classi astratte, vengono usate tipicamente per definire un "contratto". Tu dichiari in una classe C di implementare la interfaccia X. Quindi sei obbligato ad implementare tutti i metodi di X. La interfaccia non dice come devi implementarli .... dice solo cosa devi implementare. Poi dovunque sia richiesto un oggetto di tipo X .... tu puoi benissimo passare una istanza della tua classe C.
Questo è il senso delle interfacce (e in generale dei metodi abstract): imporre al programmatore di implementare quei metodi.

Originariamente inviato da Loue
E poi ripensavo al principio di sostituibilità: "È sempre possibile usare un oggetto di una sotto-classe al posto di un oggetto di una classe base".

Ora mi chiedo: ma se la sottoclasse ridefinisce un metodo della derivata, la cosa vale ancora?

Sì certo. "ridefinire" vuol dire principalmente poter "cambiare la implementazione". E ci sono tutta una serie di regole legate al "override" che sono tali da poter garantire che il principio di "sostituibilità" resti valido.

Ad esempio: un metodo che fa l'override può dichiarare un livello di accesso uguale o eventualmente più "ampio" rispetto al metodo nella superclasse ma non più ristretto.
Se nella superclasse il metodo è protected, quello in override nella sottoclasse può essere marcato protected o eventualmente public ma non certo private o con accesso di "default" (package level). Se questo fosse possibile .... un oggetto di questa sottoclasse non sarebbe usabile dove è richiesto un oggetto della superclasse!!