Guardando il codice sorgente JDK per LinkedHashMap, ho notato che questa classe è dichiarato come:LinkedHashMap firma
public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
{...
perché il ridondante "implements Map<K,V>" (dal HashMap implementa già Mappa)? Non riesco a immaginare questo è un errore di battitura ...
Grazie.
Suppongo che sia un modo di dire
Non importa ciò che si interfaccia HashMap attrezzi (ora o in futuro), questa classe dovrebbe implementare l'interfaccia Map.
Se qualcuno responsabile della HashMap decide che non dovrebbe più implementare l'interfaccia Map, il compilatore avviserà il manutentore di LinkedHashMap che non è più implementa l'interfaccia Map come egli ha voluto.
Naturalmente è sciocco in questo caso particolare (HashMap sarà ovviamente sempre una mappa), ma situazioni simili possono beneficiare (e hanno dato origine a) tale convenzione.
Sembra convenzione stile/codice: LinkedHashSet ha una firma simile. Forse è solo per enfatizzare l'utilizzo dell'interfaccia. Confronta con C++, dove è buona pratica scrivere "virtuale" con tutte le funzioni virtuali, anche se sono già implicitamente virtuali.
Come LinkedList. Immagino che sia più facile capire quali interfacce sono implementate. –
Potrebbe essere un errore da parte del codificatore.
Potrebbero anche volere rendere esplicito l'uso dell'interfaccia. Dal momento che dichiararlo due volte non fa male al di là di colpi di tasti extra, non ho alcun problema con esso.
La mia ipotesi è di consentire a LinkedHashMap di fornire un'implementazione personalizzata dei metodi dichiarati nell'interfaccia Mappa. In questo modo non erediterebbe tutte le implementazioni da HashMap.
Non erediterà comunque i metodi da HashMap .. poiché li sovrascriverà. – aioobe
Rende l'intento più chiaro, in modo che sia ovvio che questa sia intesa come implementazione di una mappa, con un comportamento specifico, che casualmente deve essere creato estendendo HashMap, quindi in grado di essere utilizzato in alcuni punti, in luogo di una HashMap.
È un codice antico. Fino a un certo punto, attorno a JDK 1.1.6, Javadoc non mostrava interfacce ereditate, quindi era consuetudine o addirittura necessario reiterarle nelle classi derivate per far funzionare correttamente Javadoc. Sono stati introdotti in JDK 1.2, ma erano disponibili molto prima come add-on per 1.1.x.
Stessa situazione con HashMap e AbstractMap –