Perché le raccolte Java non rimuovono i metodi generici?

Perché Collection.remove (Object o) non è generico?

Sembra che Collection<E>avrebbe potutoboolean remove(E o);

Quindi, quando si tenta di rimuovere accidentalmente (ad esempio) Set<String>invece di ogni singola stringa da a Collection<String>, si tratterebbe di un errore di compilazione anziché di un problema di debug in un secondo momento.

Josh Bloch e Bill Pugh fanno riferimento a questo problema in Java Puzzlers IV: The Phantom Reference Menace, Attack of the Clone e Revenge of The Shift .

Josh Bloch dice (6:41) che hanno tentato di generare il metodo get di Map, rimuovere method e altri, ma "semplicemente non ha funzionato".

Esistono troppi programmi ragionevoli che non possono essere generati se si consente solo il tipo generico della raccolta come tipo di parametro. L'esempio dato da lui è un'intersezione di a Listdi Numbers e Listdi di Longs.

remove()(in Mape in Collection) non è generico perché dovresti essere in grado di passare qualsiasi tipo di oggetto a remove(). L'oggetto rimosso non deve essere dello stesso tipo dell'oggetto a cui si passa remove(); richiede solo che siano uguali. Dalla specifica di remove(), remove(o)rimuove l'oggetto etale che (o==null ? e==null : o.equals(e))è true. Nota che non c'è nulla che richiede oe edi essere dello stesso tipo. Ciò deriva dal fatto che il equals()metodo accetta un Objectparametro as, non solo lo stesso tipo dell'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, non è certamente sempre 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, è possibile avere un Map<ArrayList, Something>e per me chiamare remove()con un LinkedListargomento as, e dovrebbe rimuovere la chiave che è un elenco con lo stesso contenuto. Ciò non sarebbe possibile se remove()fossero generici e limitassero il tipo di argomento.

Perché se il parametro type è un carattere jolly, non è possibile utilizzare un metodo di rimozione generico.

Mi sembra di aver incontrato questa domanda con il metodo get (Object) di Map. Il metodo get in questo caso non è generico, anche se dovrebbe ragionevolmente prevedere di passare un oggetto dello stesso tipo del primo parametro di tipo. Mi sono reso conto che se stai passando su Maps con un carattere jolly come primo parametro di tipo, allora non c'è modo di estrarre un elemento dalla Mappa con quel metodo, se quell'argomento fosse generico. Gli argomenti con caratteri jolly non possono davvero essere soddisfatti, poiché il compilatore non può garantire che il tipo sia corretto. Suppongo che il motivo per cui l'aggiunta sia generica sia che ci si aspetta che il tipo sia corretto prima di aggiungerlo alla raccolta. Tuttavia, quando si rimuove un oggetto, se il tipo non è corretto, non corrisponderà comunque a nulla.

Probabilmente non l'ho spiegato molto bene, ma mi sembra abbastanza logico.

Oltre alle altre risposte, c'è un'altra ragione per cui il metodo dovrebbe accettare un Object, che è predicati. Considera il seguente esempio:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

Il punto è che l'oggetto che viene passato al removemetodo è responsabile della definizione del equalsmetodo. Costruire predicati diventa molto semplice in questo modo.

Assumere uno ha una collezione di Cat, e alcuni riferimenti a oggetti di tipi Animal, Cat, SiameseCat, e Dog. Chiedere alla raccolta se contiene l'oggetto a cui fa riferimento il riferimento Cato SiameseCatsembra ragionevole. Chiedere se contiene l'oggetto a cui fa Animalriferimento il riferimento può sembrare complicato, ma è comunque perfettamente ragionevole. Dopotutto, l'oggetto in questione potrebbe essere a Cate potrebbe apparire nella raccolta.

Inoltre, anche se l'oggetto sembra essere qualcosa di diverso da un Cat, non c'è alcun problema a dire se appare nella raccolta - rispondi semplicemente "no, non lo fa". Una raccolta di tipo "lookup" dovrebbe essere in grado di accettare in modo significativo il riferimento di qualsiasi supertipo e determinare se l'oggetto esiste all'interno della raccolta. Se il riferimento all'oggetto passato è di tipo non correlato, non è possibile che la raccolta possa contenerlo, quindi la query non è in alcun senso significativa (risponderà sempre "no"). Tuttavia, poiché non esiste alcun modo per limitare i parametri ai sottotipi o ai supertipi, è molto pratico semplicemente accettare qualsiasi tipo e rispondere "no" per qualsiasi oggetto il cui tipo non è correlato a quello della raccolta.

Ho sempre pensato che fosse perché remove () non ha motivo di preoccuparsi del tipo di oggetto che gli dai. È abbastanza facile, a prescindere, controllare se quell'oggetto è uno di quelli contenuti nella Raccolta, poiché può chiamare equals () su qualsiasi cosa. È necessario controllare il tipo su add () per assicurarsi che contenga solo oggetti di quel tipo.

È stato un compromesso. Entrambi gli approcci hanno il loro vantaggio:

• remove(Object o)
  • è più flessibile. Ad esempio, consente di scorrere un elenco di numeri e rimuoverli da un elenco di long.
  • il codice che utilizza questa flessibilità può essere più facilmente generato
• remove(E e) porta maggiore sicurezza del tipo a ciò che la maggior parte dei programmi vuole fare rilevando bug sottili in fase di compilazione, come tentare erroneamente di rimuovere un numero intero da un elenco di cortocircuiti.

La compatibilità con le versioni precedenti era sempre un obiettivo importante durante l'evoluzione dell'API Java, pertanto è stato scelto remove (Object o) perché ha reso più semplice la generazione di codice esistente. Se la compatibilità con le versioni precedenti NON fosse stata un problema, suppongo che i progettisti avrebbero scelto di rimuovere (E e).

Rimuovere non è un metodo generico, pertanto il codice esistente che utilizza una raccolta non generica verrà comunque compilato e avrà lo stesso comportamento.

Vedere http://www.ibm.com/developerworks/java/library/j-jtp01255.html per i dettagli.

Modifica: un commentatore chiede perché il metodo di aggiunta sia generico. [... rimosso la mia spiegazione ...] Il secondo commentatore ha risposto alla domanda di Firebird84 molto meglio di me.

Un altro motivo è dovuto alle interfacce. Ecco un esempio per mostrarlo:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

Perché romperebbe il codice esistente (pre-Java5). per esempio,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

Ora potresti dire che il codice sopra è sbagliato, ma supponi che o provenga da un insieme eterogeneo di oggetti (cioè conteneva stringhe, numero, oggetti, ecc.). Vuoi rimuovere tutte le corrispondenze, il che era legale perché rimuovere avrebbe semplicemente ignorato le non stringhe perché non uguali. Ma se lo fai rimuovi (String o), non funziona più.