¿Llamar a super.equals y super.hashCode en la clase infantil?

Question

Si implemento equals() y hashCode() en las clases primaria y secundaria, ¿es necesario llamar al super.equals() en equals() en la clase secundaria, p.

public boolean equals(Object obj) { 

    if (obj.getClass() != ChildClass.class) { 
    return false; 
    } 

    return super.equals() && this.var == ((ChildClass) obj).var; 

} 

Answer 1

No, eso no es necesario, y probablemente sería incorrecto. De hecho, parte de la razón por la que está anulando equal es porque super.equals no da el comportamiento correcto (¿no?).

O dicho de otra manera, si super.equals da el comportamiento correcto, es probable que no necesita ir a la dificultad de anular la misma.

Pero si está anulando equals, entonces sí, necesita anular hashCode, también.

Answer 2

Si su super clase no implementa iguales, a continuación, llamar super.equals le conseguirán la implementación de objetos que sólo se compara referencias, por lo que en cualquier aplicación normal, es igual a la que desea comparar una clave de negocio se haría realidad causa muchos falsos negativos

Dicho esto, su implementación anterior realmente no es diferente semánticamente que la implementación predeterminada de igual en Objeto ya que solo está usando == para la comparación.

En cuanto a hashCode, si reemplaza a igual, realmente debe anular hashCode para mantener el contrato de los dos. Por ejemplo, si está utilizando una clave comercial para iguales, probablemente debería usar la misma clave comercial para el código hash, de modo que dos objetos que son iguales generen el mismo código hash.

Answer 3

EDITAR

te acabo di cuenta utiliza la igualdad de clases, no instanceof - lo que significa que la reflexividad habría ser correcta. En su ejemplo, el uso de super.equals es probablemente correcto, siempre que la superclase no proporcione una definición de igualdad que sea contraria a la que desea su subclase (como Object, por ejemplo).

El punto principal es que la definición de igualdad debe provenir de exactamente un tipo (clase o interfaz) en la jerarquía de su clase. Si la implementación de esa definición se aprovecha de super.equals, está bien.

FIN EDITAR, texto original a continuación

Es casi seguro que lo peor que puede hacer, porque violaría la propiedad reflexiva de la igualdad.

Digamos que tiene una Forma, y ​​es igual a otra Forma si son del mismo tipo: Cuadrado es igual a Cuadrado, Círculo es igual a Círculo, etc. Ahora extiende eso para hacer una Plaza de Color que agrega una verificación de color.

Shape shape1 = new Shape(SQUARE); 
Shape shape2 = new ColoredShape(SQUARE, RED); 

se implementa como ColoredSquare.equalssuper.equals(other) && other.color == this.color, como en su pregunta. Pero ahora, tenga en cuenta que shape1.equals(shape2) == true (desde shape1 solo usa Shape.equals), pero shape2.equals(shape1) == false (ya que agrega la verificación de color).

La moraleja de la historia es que el uso de esta clase de igualdad en cascada es muy difícil, si no imposible. Básicamente, la igualdad debe provenir de exactamente un tipo dentro de la jerarquía de tipo - ya sea Object, su tipo en sí, un tipo estupendo, o alguna de las interfaces que define un contrato (por ejemplo, en el marco de las colecciones, que definen la igualdad para Set, List, etc.)