¿Por qué tenemos contiene (Objeto o) en lugar de contiene (E e)?

Question

¿Es para mantener la compatibilidad con versiones anteriores (no genéricas) de Collection? ¿O hay un detalle más sutil que me falta? Veo este patrón repetido en remove también (remove(Object o)), pero add está genericized como add(E e).

Answer 1

toma Object porque el objeto que coincide no tiene que ser del mismo tipo que el objeto que pasa a ; solo requiere que sean iguales. A partir de la especificación de , contains(o) devuelve verdadero si hay un objeto e tal que (o==null ? e==null : o.equals(e)) es cierto.Tenga en cuenta que no hay nada que requiera que o y e sean del mismo tipo. Esto se desprende del hecho de que el método equals() toma como parámetro Object, no solo del mismo tipo que el objeto.

Aunque puede ser comúnmente cierto que muchas clases tienen equals() definido de modo que sus objetos solo pueden ser iguales a los objetos de su propia clase, eso no siempre es el caso. Por ejemplo, la especificación para List.equals() dice que dos objetos List son iguales si ambos son List sy tienen el mismo contenido, incluso si son implementaciones diferentes de List. Volviendo al ejemplo en esta pregunta, es posible tener un Collection<ArrayList> y para llamar al con un LinkedList como argumento, y puede devolver verdadero si hay una lista con los mismos contenidos. Esto no sería posible si fuera genérico y restringiera su tipo de argumento a E.

De hecho, el hecho de que toma cualquier objeto como un argumento permite un uso interesante donde se puede usarlo para comprobar la existencia de un objeto en la colección que satisface una determinada propiedad:

Collection<Integer> integers; 
boolean oddNumberExists = integers.contains(new Object() { 
    public boolean equals(Object e) { 
     Integer i = (Integer)e; 
     if (i % 2 != 0) return true; 
     else return false; 
    } 
}); 

Answer 2

es porque la función contains utiliza la función equals, y la función equals se define en la clase de objeto de base con una firma de equals(Object o) en lugar de equals(E e) (ya que no todas las clases son de carácter genérico). El mismo caso con la función remove - atraviesa la colección utilizando la función equals que toma un argumento de objeto.

Esto no explica directamente la decisión, sin embargo, ya que podría haber todavía se utiliza el tipo E y permitió que fuera lanzado automáticamente al tipo de objeto en la llamada a equals; pero me imagino que querían permitir que se llamara a la función en otros tipos de objetos. No hay nada malo en tener un Collection<Foo> c; y luego llamar c.contains(somethingOfTypeBar) - siempre devolverá falso, y por lo que elimina la necesidad de un molde para escribir Foo (que puede lanzar una excepción) o, para proteger de la excepción, una llamada typeof. Así que puede imaginarse si está iterando sobre algo con tipos mixtos y llamando al contains en cada uno de los elementos, puede simplemente usar la función contains en todos ellos en lugar de necesitar guardias.

En realidad es una reminiscencia de los idiomas más "nuevos" mecanografiadas débilmente, cuando se mira de esa manera ...

Answer 3

respondida aquí.
Why aren't Java Collections remove methods generic?
En resumen, querían maximizar la compatibilidad hacia atrás, ya que las colecciones se han introducido mucho antes de que los genéricos.

Y para añadir de mí: el video se está refiriendo vale la pena ver.
http://www.youtube.com/watch?v=wDN_EYUvUq0

actualización
Para aclarar, el hombre que dice que (en el video) era una de las personas que actualizaron mapas y colecciones de Java para utilizar los genéricos. Si él no sabe, entonces quién.

Answer 4

porque de lo contrario podría haber solamente puede comparar con la coincidencia exacta de tipo de parámetro, específicamente colecciones comodín habrían dejado de funcionar, por ejemplo,

class Base 
{ 
} 

class Derived 
    extends Base 
{ 
} 

Collection< ? extends Base > c = ...; 

Derived d = ...; 

Base base_ref = d; 

c.contains(d); // Would have produced compile error 

c.contains(base_ref); // Would have produced compile error 

EDITAR
Para los escépticos que piensan que no es una de las razones, aquí hay una lista de arreglo modificado con un estarían generified método contains

class MyCollection<E> extends ArrayList<E> 
{ 
    public boolean myContains(E e) 
    { 
     return false; 
    } 
} 

MyCollecttion< ? extends Base > c2 = ...; 

c2.myContains(d); // does not compile 
c2.myContains(base_ref); // does not compile 

Básicamente contains(Object o) es un truco para hacer este caso de uso muy común para trabajar con Java Generics.

Answer 5

"¿esa cesta de manzanas contiene esta naranja?"

claramente no se puede dar una respuesta VERDADERA. pero eso aún deja demasiadas posibilidades:

1. la respuesta es FALSA.
2. la pregunta no está bien formada, no debe pasar la compilación.

la colección api eligió la primera. pero la segunda opción también tendría perfecto sentido. una pregunta como esa es una pregunta de mierda 99,99% de las veces, ¡así que no preguntes!