Quali sono i motivi per cui Map.get (Object key) non è (completamente) generico

Quali sono i motivi alla base della decisione di non avere un metodo get completamente generico nell'interfaccia di java.util.Map<K, V>.

Per chiarire la domanda, la firma del metodo è

V get(Object key)

invece di

V get(K key)

e mi chiedo perché (stessa cosa per remove, containsKey, containsValue).

Come menzionato da altri, il motivo per cui get(), ecc. Non è generico perché la chiave della voce che stai recuperando non deve essere dello stesso tipo dell'oggetto a cui passi get(); la specifica del metodo richiede solo che siano uguali. Ciò deriva da come il equals()metodo accetta un oggetto come parametro, non solo lo stesso tipo di oggetto.

Anche se può essere comunemente vero che molte classi hanno equals()definito in modo tale che i suoi oggetti possano essere uguali a quelli della propria classe, ci sono molti posti in Java in cui non è così. Ad esempio, la specifica per List.equals()dice che due oggetti Elenco sono uguali se sono entrambi Elenchi e hanno gli stessi contenuti, anche se sono implementazioni diverse di List. Quindi, tornando all'esempio in questa domanda, secondo la specifica del metodo è possibile avere un Map<ArrayList, Something>e per me chiamare get()con un LinkedListargomento as, e dovrebbe recuperare la chiave che è un elenco con lo stesso contenuto. Ciò non sarebbe possibile se get()fossero generici e limitassero il tipo di argomento.

Un fantastico programmatore Java su Google, Kevin Bourrillion, ha scritto esattamente questo problema in un post di blog qualche tempo fa (è vero che nel contesto di Setanziché Map). La frase più rilevante:

Uniformamente, i metodi di Java Collections Framework (e anche di Google Collections Library) non limitano mai i tipi dei loro parametri, tranne quando è necessario per evitare che la raccolta si rompa.

Non sono del tutto sicuro di essere d'accordo con esso come principio - .NET sembra andare bene richiedendo il giusto tipo di chiave, per esempio - ma vale la pena seguire il ragionamento nel post del blog. (Dopo aver menzionato .NET, vale la pena spiegare che parte del motivo per cui non è un problema in .NET è che c'è un problema più grande in .NET di varianza più limitata ...)

Il contratto è così espresso:

Più formalmente, se questa mappa contiene una mappatura da una chiave k a un valore v tale che (chiave == null? K == null: key.equals (k) ), allora questo metodo restituisce v; altrimenti restituisce null. (Può esserci al massimo una di queste mappature.)

(la mia enfasi)

e come tale, una ricerca chiave riuscita dipende dall'implementazione della chiave di input del metodo di uguaglianza. Ciò non dipende necessariamente dalla classe di k.

È un'applicazione della Legge di Postel, "sii prudente in ciò che fai, sii liberale in ciò che accetti dagli altri".

I controlli di uguaglianza possono essere eseguiti indipendentemente dal tipo; il equalsmetodo è definito sulla Objectclasse e accetta qualsiasi Objectcome parametro. Pertanto, ha senso che l'equivalenza chiave e le operazioni basate sull'equivalenza chiave accettino qualsiasi Objecttipo.

Quando una mappa restituisce valori chiave, conserva quante più informazioni possibili sul tipo, usando il parametro type.

Penso che questa sezione di Generics Tutorial spieghi la situazione (la mia enfasi):

"Devi assicurarti che l'API generica non sia indebitamente restrittiva; deve continuare a supportare il contratto originale dell'API. Considera di nuovo alcuni esempi da java.util.Collection. L'API pre-generica assomiglia a:

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

Un ingenuo tentativo di generarlo è:

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

Anche se questo è sicuramente sicuro, non è all'altezza del contratto originale dell'API. Il metodo contieneAll () funziona con qualsiasi tipo di raccolta in entrata. Avrà successo solo se la raccolta in arrivo contiene davvero solo istanze di E, ma:

• Il tipo statico della raccolta in arrivo potrebbe essere diverso, forse perché il chiamante non conosce il tipo preciso della raccolta inoltrata o forse perché si tratta di una raccolta <S>, dove S è un sottotipo di E.
• È perfettamente legittimo chiamare IncludesAll () con una raccolta di tipo diverso. La routine dovrebbe funzionare, restituendo false. "

Il motivo è che il contenimento è determinato da equalse hashCodequali sono i metodi attivi Objected entrambi accettano un Objectparametro. Questo è stato un primo difetto di progettazione nelle librerie standard di Java. Insieme alle limitazioni nel sistema di tipi Java, impone che tutto ciò che si basa su uguale e hashCode Object.

L'unico modo per avere le tabelle hash type-safe e uguaglianza in Java è quello di astenersi Object.equalse Object.hashCodedi utilizzare un sostituto generico. Java funzionale viene fornito con classi di tipi solo per questo scopo: Hash<A>e Equal<A>. Viene HashMap<K, V>fornito un wrapper per che prende Hash<K>e Equal<K>nel suo costruttore. Questa classe gete i containsmetodi quindi prendono un argomento generico di tipo K.

Esempio:

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

Compatibilità.

Prima che i generici fossero disponibili, c'era solo get (Object o).

Se avessero cambiato questo metodo per ottenere (<K> o) avrebbe potenzialmente imposto una manutenzione massiccia del codice agli utenti java solo per far compilare nuovamente il codice funzionante.

Avrebbero potuto introdurre un metodo aggiuntivo , ad esempio get_checked (<K> o) e deprecare il vecchio metodo get () in modo che esistesse un percorso di transizione più delicato. Ma per qualche motivo, questo non è stato fatto. (La situazione in cui ci troviamo ora è che è necessario installare strumenti come findBugs per verificare la compatibilità dei tipi tra l'argomento get () e il tipo di chiave dichiarato <K> della mappa.)

Gli argomenti relativi alla semantica di .equals () sono falsi, credo. (Tecnicamente sono corretti, ma continuo a pensare che siano falsi. Nessun progettista nella sua mente giusta renderà mai o1.equals (o2) vero se o1 e o2 non hanno alcuna superclasse comune.)

C'è un motivo in più, non può essere fatto tecnicamente, perché rompe la Mappa.

Java ha una costruzione polimorfica generica come <? extends SomeClass>. Contrassegnato tale riferimento può puntare al tipo firmato con <AnySubclassOfSomeClass>. Ma il generico polimorfico fa quel riferimento in sola lettura . Il compilatore consente di utilizzare i tipi generici solo come tipo di metodo di restituzione (come i getter semplici), ma blocca l'utilizzo di metodi in cui il tipo generico è argomento (come i setter ordinari). Significa che se scrivi Map<? extends KeyType, ValueType>, il compilatore non ti consente di chiamare il metodo get(<? extends KeyType>)e la mappa sarà inutile. L'unica soluzione è quella di rendere questo metodo non generico: get(Object).

Compatibilità all'indietro, immagino. Map(o HashMap) deve ancora supportare get(Object).

Stavo guardando questo e pensando perché l'hanno fatto in questo modo. Non credo che nessuna delle risposte esistenti spieghi perché non possano semplicemente far accettare alla nuova interfaccia generica solo il tipo corretto per la chiave. Il vero motivo è che nonostante abbiano introdotto i generici NON hanno creato una nuova interfaccia. L'interfaccia di Map è la stessa vecchia mappa non generica che serve sia come versione generica che non generica. In questo modo, se si dispone di un metodo che accetta una mappa non generica, è possibile passarlo a Map<String, Customer>e funzionerebbe comunque. Allo stesso tempo, il contratto per get accetta Object, quindi anche la nuova interfaccia dovrebbe supportare questo contratto.

A mio avviso avrebbero dovuto aggiungere una nuova interfaccia e implementare entrambe le raccolte esistenti, ma hanno deciso a favore di interfacce compatibili anche se ciò significa un design peggiore per il metodo get. Si noti che le raccolte stesse sarebbero compatibili con i metodi esistenti che solo le interfacce non avrebbero.

Stiamo facendo un grande refactoring proprio ora e ci mancava questo get () fortemente tipizzato per verificare che non ci siamo persi alcuni get () con il vecchio tipo.

Ma ho trovato una soluzione alternativa / brutto trucco per il controllo del tempo di compilazione: crea un'interfaccia di Map con get fortemente, contieneKey, rimuovi ... e inseriscila nel pacchetto java.util del tuo progetto.

Otterrai errori di compilazione solo per la chiamata di get (), ... con tipi errati, tutto ciò che gli altri sembrano ok per il compilatore (almeno all'interno di eclipse kepler).

Non dimenticare di eliminare questa interfaccia dopo aver verificato la tua build in quanto non è ciò che desideri in runtime.