Java, problema con le interfacce

[andy_]

Ciao a tutti, sto studiando Java e mi è sorto un dubbio. Visto che nelle interfacce i metodi sono astratti e quindi non hanno alcuna implementazione, quando ad esempio ottengo una Collection usando il metodo values() da una HashMap, perchè poi posso chiammare su di essa (la Collection) metodi, come toString() ecc? Essendo veramente di una interfaccia (non è una chiamata virtuale) quando chiama metodi su di essa non dovrebbero essere metodi astratti e quindi non chiamabili? Spero di essermi spiegato. Grazie.

[RoTeam]

Perché tu stai utilizzando un oggetto non direttamente l'interfaccia e ogni oggetto in java estende la classe Object che ha tutti quei metodi(toString(), hashCode(), equals(), etc...)

[andy_]

Si hai ragione, mi sono spiegato male io, scusami. Quello che volevo dire è che se ad esempio chiamo toString() sulla Collection così ottenuta il risultato è una stringa non del tipo “ClassName@HashCode” ma una stringa con tutti i vari toString() degli oggetti che contiene(giusto?), mentre visto che quel metodo non è stato riscritto, chiamando toString(), se chiamassi quello dell'oggetto, dovrebbe restituirmi “ClassName@HashCode”. E comunque il tuo discorso non è applicabile a tutti gli altri metodi che Collection ha ma che non ha Object(get(), isEmpty() ecc).

[francesco.muia]

Si chiama "Polimorfismo", spiegarlo in poche righe è difficile, soprattutto se ancora non hai visto cos'è l'ereditarietà.
Cmq cerco di spiegarti il caso in particolare che hai evidenziato.
HashMap come tutte le collezioni di oggetti in java implementano l'interfaccia Collection e ovviamente implementando questa interfaccia devo definire i metodi che essa contiene (isEmpty,get etc...). Ora tipicamente quando un oggetto eredita/implementa un'altro oggetto si definisce un relazione del tipo "è un" cioè un HasMap è un HashMap ma è anche una Collection, quindi essendoci questo tipo di relazione si può definire un metodo esempio values che ha come tipo di ritorno una Collection e all'interno di questo metodo effettuare il return this (non è questo il caso di HashMap non ritorna semplicemente il this), in quanto la classe in questione è anche una Collection.

[andy_]

Si chiama "Polimorfismo", spiegarlo in poche righe è difficile, soprattutto se ancora non hai visto cos'è l'ereditarietà.
Cmq cerco di spiegarti il caso in particolare che hai evidenziato.
HashMap come tutte le collezioni di oggetti in java implementano l'interfaccia Collection e ovviamente implementando questa interfaccia devo definire i metodi che essa contiene (isEmpty,get etc...). Ora tipicamente quando un oggetto eredita/implementa un'altro oggetto si definisce un relazione del tipo "è un" cioè un HasMap è un HashMap ma è anche una Collection, quindi essendoci questo tipo di relazione si può definire un metodo esempio values che ha come tipo di ritorno una Collection e all'interno di questo metodo effettuare il return this (non è questo il caso di HashMap non ritorna semplicemente il this), in quanto la classe in questione è anche una Collection.

La mia domanda è su cosa succede sui metodi chiamati su quella Collection ritornata dal metodo di HashMap, che è propio una Collection(a=unaHashMap.value(),a è propio una Collection, non c'è polimrfismo, a me interessano i metodi chiamati su a; a.toString() al massimo dovrebbe chiamare col polimorfismo il metodo di Object e a.get(0) semplicemente non dovrebbe essere implementato).

[francesco.muia]

Il polimorfismo c'è e come se c'è....
appunto perchè c'è il polimorfismo non viene invocato il metodo toString di object ma dell'implementazione della collection.
nel caso particolare da te evidenziato cioè hashmap il toString che verrà invocato è quello definito nella classe AbstractCollection.

430    public String toString() {
431        Iterator<E> i = iterator();
432        if (! i.hasNext())
433            return "[]";
434
435        StringBuilder sb = new StringBuilder();
436        sb.append('[');
437        for (;;) {
438            E e = i.next();
439            sb.append(e == this ? "(this Collection)" : e);
440            if (! i.hasNext())
441                return sb.append(']').toString();
442            sb.append(", ");
443        }
444    }

[andy_]

No, stiamo parlando di cose diverse.
Allora:
Map<...> a=new HashMap<>();
...
Collection <...> b;

ok??
a.toString() è quello che dici tu e ok non c'è alcun problema. Però:
b=a.values;
b.toStrign();
Qesto toString() è un metodo di una Colletion non di una HashMap! Al massimo potrebbe chiamare per polimorfismo il toString() di Object che restituirebbe NomaClasse@indirizzoesadecimale.
Invece ad esempio b.isEmpty() non è ereditato da niente e non è neppure riscritto, come lo esegue?

[francesco.muia]

Ritorniamo sempre li....
Una domanda L'ereditarietà l'hai già studiata?
prova a farti stampare b.getClass, sicuramente rimarrai stupito sul fatto che non ti stampi java.util.Collection....

[andy_]

Ho capito che non è una collection, sai spegarmi anche il perchè o no?

[francesco.muia]

Te lo spiegato nella prima risposta e come ti ho detto se non hai ancora studiato L'ereditarietà non lo potrai mai capire fino in fondo. Il concetto di fondo è che come hai ben notato che il tipo dichiarato in una classe può essere diverso a runtime.
poi non è proprio vero che non è un collection, ma in pratica è una classe ,per quanto riguarda hashmap è un innerClass "Values", che estende AbstractCollection che a sua volta implementa collection. In AbstractCollection sono definiti i metodi come isEmpty, e altri nel tuo caso vengono definiti nella inner class Values