Pregunta

Siempre he pensado que el .equals() método en java debe ser reemplazado para ser hecho específicamente para la clase que usted ha creado.En otras palabras, para buscar la equivalencia de dos instancias diferentes en lugar de dos referencias a la misma instancia.Sin embargo me he encontrado con otros programadores que parecen pensar que el objeto predeterminado comportamiento deben ser dejados solos y un nuevo método creado para probar la equivalencia de dos objetos de la misma clase.

¿Cuáles son los argumentos a favor y en contra de reemplazar el método equals?

¿Fue útil?

Solución

Reemplazar el método equals es necesario si usted desea probar la equivalencia en la biblioteca estándar de clases (por ejemplo, asegurar un java.util.Set contiene elementos únicos o el uso de objetos como llaves en java.util.Los objetos del mapa).

Nota, si reemplazar iguales, asegúrese de honor de la API de contrato, como se describe en la documentación.Por ejemplo, asegúrese de que también se anulan Objeto.hashCode:

Si dos objetos son iguales de acuerdo a el equals(Object) método, entonces llamar al método hashCode en cada uno de los dos objetos deben producir el mismo resultado entero.

EDITAR:No he puesto esto como una respuesta completa sobre el tema, así que voy a echo Fredrik Kalseth la declaración de que el primordial es igual funciona mejor para los objetos inmutables.Para citar a la API para Mapa:

Nota:gran cuidado debe ser ejercido si los objetos mutables son utilizados como mapa de teclas.El comportamiento de un mapa no es especificado si el valor de un objeto se cambia de tal manera que afecta igual las comparaciones, mientras que el objeto es una clave en el mapa.

Otros consejos

Yo recomendaría altamente a recoger una copia de Efectivo de Java y la lectura a través del punto 7 obedeciendo a la es igual a contrato.Usted necesita tener cuidado si se va a reemplazar es igual para los objetos mutables, como muchas de las colecciones, tales como Mapas y Conjuntos de uso es igual a determinar la equivalencia, y la mutación de un objeto contenido en una colección que podría conducir a resultados inesperados.Brian Goetz también tiene una muy buena descripción general de la implementación de equals y hashCode.

"Nunca" override es igual a & getHashCode para objetos mutables - esto va para .net y Java ambos.Si lo hace, y el uso de un objeto como la clave de f.ex de un diccionario y, a continuación, cambio ese objeto, vas a estar en problemas porque el diccionario se basa en la etiqueta para encontrar el objeto.

He aquí un buen artículo sobre el tema: http://weblogs.asp.net/bleroy/archive/2004/12/15/316601.aspx

@David Schlosnagle menciona menciona Josh del Bloch Efectivos De Java -- este es un hay que leer para cualquier desarrollador de Java.

No es un tema relacionado:para inmutable objetos de valor, también se debe considerar la posibilidad de reemplazar compare_to.El texto estándar para si difieren es en la Comparable a la API:

Es generalmente el caso, pero no es estrictamente necesario que (compare(x, y)==0) == (x.es igual a(y)).En general, cualquier comparador de que viola esta condición debe indicar claramente este hecho.El lenguaje recomendado es "Nota:este comparador impone órdenes que son incompatibles con los iguales."

El método Equals es la intención de comparar las referencias.Así que no debe ser anulada a cambiar su comportamiento.

Usted debe crear un nuevo método para la prueba de equivalencia en los diferentes casos, si usted necesita (o utilice el método CompareTo en algunos .NET clases)

Para ser honesto, en Java no hay realmente un argumento contra la anulación de es igual.Si usted necesita para comparar instancias para la igualdad, entonces que es lo que haces.

Como se mencionó anteriormente, usted necesita estar consciente de que el contrato con hashCode, y del mismo modo, mirar hacia fuera para las trampas alrededor de la Comparable interfaz - en casi todas las situaciones desea que el natural de pedidos como se define por Comparables a ser en consonancia con los iguales (consulte la BigDecimal documento api para la canónica contador de ejemplo)

La creación de un nuevo método para decidir la igualdad, aparte de no trabajar con la existente en la biblioteca de clases, moscas en la cara de la convención de Java un poco.

Sólo es necesario reemplazar el equals() método si desea específicos de comportamiento a la hora de añadir objetos a datos ordenados en estructuras deSortedSet etc.)

Cuando usted hace esto, usted también debe reemplazar hashCode().

Ver aquí para una explicación completa.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top