¿Por qué las colecciones de Java no eliminan los métodos genéricos?

¿Por qué Collection.remove (Object o) no es genérico?

Parece que Collection<E>podría haberboolean remove(E o);

Luego, cuando accidentalmente intente eliminar (por ejemplo) en Set<String>lugar de cada Cadena individual de una Collection<String>, sería un error de tiempo de compilación en lugar de un problema de depuración posterior.

Josh Bloch y Bill Pugh se refieren a este tema en Java Puzzlers IV: The Phantom Reference Menace, Attack of the Clone y Revenge of The Shift .

Josh Bloch dice (6:41) que intentaron generar el método get de Map, remove method y algunos otros, pero "simplemente no funcionó".

Hay demasiados programas razonables que no podrían generarse si solo permite el tipo genérico de la colección como tipo de parámetro. El ejemplo dado por él es una intersección de a Listde Numbersy a Listde Longs.

remove()( Maptanto como en Collection) no es genérico porque debería poder pasar cualquier tipo de objeto a remove(). El objeto eliminado no tiene que ser del mismo tipo que el objeto al que se pasa remove(); solo requiere que sean iguales. De la especificación de remove(), remove(o)elimina el objeto etal como (o==null ? e==null : o.equals(e))es true. Tenga en cuenta que no hay nada que requiera oy esea ​​del mismo tipo. Esto se deduce del hecho de que el equals()método toma un Objectparámetro as, no solo el mismo tipo que el objeto.

Aunque, puede ser comúnmente cierto que muchas clases se han equals()definido para que sus objetos solo puedan ser iguales a los objetos de su propia clase, ese no es siempre el caso. Por ejemplo, la especificación de List.equals()dice que dos objetos List son iguales si ambas son Listas y tienen el mismo contenido, incluso si son implementaciones diferentes de List. Volviendo al ejemplo en esta pregunta, es posible tener un Map<ArrayList, Something>y para que llame remove()con un LinkedListargumento como, y debería eliminar la clave, que es una lista con el mismo contenido. Esto no sería posible si remove()fuera genérico y restringiera su tipo de argumento.

Porque si su parámetro de tipo es un comodín, no puede usar un método genérico de eliminación.

Creo recordar haber encontrado esta pregunta con el método get (Object) de Map. El método get en este caso no es genérico, aunque debería esperar razonablemente que se le pase un objeto del mismo tipo que el primer parámetro de tipo. Me di cuenta de que si estás pasando Mapas con un comodín como primer parámetro de tipo, entonces no hay forma de sacar un elemento del Mapa con ese método, si ese argumento es genérico. Los argumentos comodín no pueden satisfacerse realmente, porque el compilador no puede garantizar que el tipo sea correcto. Especulo que la razón por la que agregar es genérico es que se espera que garantices que el tipo es correcto antes de agregarlo a la colección. Sin embargo, al eliminar un objeto, si el tipo es incorrecto, no coincidirá con nada de todos modos.

Probablemente no lo expliqué muy bien, pero me parece bastante lógico.

Además de las otras respuestas, hay otra razón por la cual el método debe aceptar un Object, que es predicados. Considere la siguiente muestra:

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);
        }});
    }
}

El punto es que el objeto que se pasa al removemétodo es responsable de definir el equalsmétodo. Construir predicados se vuelve muy simple de esta manera.

Suponga que uno tiene una colección de Cat, y algunas referencias a objetos de tipos Animal, Cat, SiameseCat, y Dog. Preguntar a la colección si contiene el objeto al que hace referencia la referencia Cato SiameseCatparece razonable. Preguntar si contiene el objeto al que hace Animalreferencia la referencia puede parecer dudoso, pero sigue siendo perfectamente razonable. El objeto en cuestión podría, después de todo, ser un Caty podría aparecer en la colección.

Además, incluso si el objeto Catno es un objeto , no hay problema para decir si aparece en la colección, simplemente responda "no, no lo hace". Una colección de "tipo de búsqueda" de algún tipo debería poder aceptar de manera significativa la referencia de cualquier supertipo y determinar si el objeto existe dentro de la colección. Si la referencia de objeto pasada es de un tipo no relacionado, no hay forma de que la colección pueda contenerla, por lo que la consulta no es significativa en algún sentido (siempre responderá "no"). No obstante, dado que no hay forma de restringir los parámetros a subtipos o supertipos, lo más práctico es simplemente aceptar cualquier tipo y responder "no" a cualquier objeto cuyo tipo no esté relacionado con el de la colección.

Siempre pensé que esto se debía a que remove () no tiene ninguna razón para importarle qué tipo de objeto le das. Sin embargo, es bastante fácil verificar si ese objeto es uno de los que contiene la Colección, ya que puede llamar a equals () en cualquier cosa. Es necesario verificar el tipo en add () para asegurarse de que solo contenga objetos de ese tipo.

Fue un compromiso. Ambos enfoques tienen su ventaja:

• remove(Object o)
  • Es más flexible. Por ejemplo, permite recorrer una lista de números y eliminarlos de una lista de longs.
  • el código que usa esta flexibilidad puede ser más fácilmente generado
• remove(E e) brinda más seguridad de tipografía a lo que la mayoría de los programas quieren hacer al detectar errores sutiles en el momento de la compilación, como tratar de eliminar por error un número entero de una lista de cortos.

La compatibilidad con versiones anteriores siempre fue un objetivo importante al desarrollar la API de Java, por lo tanto, se eligió eliminar (Objeto o) porque facilitaba la generación de código existente. Si la compatibilidad con versiones anteriores NO hubiera sido un problema, supongo que los diseñadores habrían elegido eliminar (E e).

Eliminar no es un método genérico, por lo que el código existente que utiliza una colección no genérica seguirá compilando y seguirá teniendo el mismo comportamiento.

Consulte http://www.ibm.com/developerworks/java/library/j-jtp01255.html para obtener más detalles.

Editar: Un comentarista pregunta por qué el método de agregar es genérico. [... eliminó mi explicación ...] El segundo comentarista respondió la pregunta de firebird84 mucho mejor que yo.

Otra razón es por las interfaces. Aquí hay un ejemplo para 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 */
}

Porque rompería el código existente (anterior a Java5). p.ej,

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

Ahora puede decir que el código anterior es incorrecto, pero suponga que o proviene de un conjunto heterogéneo de objetos (es decir, que contiene cadenas, números, objetos, etc.). Desea eliminar todas las coincidencias, lo cual era legal porque eliminar simplemente ignoraría las no cadenas porque no eran iguales. Pero si lo haces eliminar (String o), eso ya no funciona.