Apache Commons equals / hashCode constructor [cerrado]

Tengo curiosidad por saber, ¿qué piensa la gente de usar org.apache.commons.lang.builder EqualsBuilder/ HashCodeBuilder para implementar el equals/ hashCode? ¿Sería una mejor práctica que escribir la tuya? ¿Juega bien con Hibernate? ¿Cual es tu opinion?

Los creadores de commons / lang son geniales y los he estado usando durante años sin sobrecarga de rendimiento notable (con y sin hibernación). Pero como Alain escribe, la forma de la guayaba es aún mejor:

Aquí hay una muestra de Bean:

public class Bean{

    private String name;
    private int length;
    private List<Bean> children;

}

Aquí está equals () y hashCode () implementado con Commons / Lang:

@Override
public int hashCode(){
    return new HashCodeBuilder()
        .append(name)
        .append(length)
        .append(children)
        .toHashCode();
}

@Override
public boolean equals(final Object obj){
    if(obj instanceof Bean){
        final Bean other = (Bean) obj;
        return new EqualsBuilder()
            .append(name, other.name)
            .append(length, other.length)
            .append(children, other.children)
            .isEquals();
    } else{
        return false;
    }
}

y aquí con Java 7 o superior (inspirado en Guava):

@Override
public int hashCode(){
    return Objects.hash(name, length, children);
}

@Override
public boolean equals(final Object obj){
    if(obj instanceof Bean){
        final Bean other = (Bean) obj;
        return Objects.equals(name, other.name)
            && length == other.length // special handling for primitives
            && Objects.equals(children, other.children);
    } else{
        return false;
    }
}

Nota: este código originalmente hacía referencia a Guava, pero como los comentarios han señalado, esta funcionalidad se ha introducido en el JDK, por lo que Guava ya no es necesaria.

Como puede ver, la versión Guava / JDK es más corta y evita objetos auxiliares superfluos. En caso de igual, incluso permite un cortocircuito en la evaluación si una Object.equals()llamada anterior devuelve falso (para ser justos: commons / lang tiene un ObjectUtils.equals(obj1, obj2)método con semántica idéntica que podría usarse en lugar de EqualsBuilderpermitir un cortocircuito como se indicó anteriormente).

Entonces: sí, los constructores de lang comunes son muy preferibles a los métodos equals()y hashCode()métodos construidos manualmente (o esos monstruos horribles que Eclipse generará para usted), pero las versiones de Java 7+ / Guava son aún mejores.

Y una nota sobre Hibernate:

tenga cuidado con el uso de colecciones diferidas en sus implementaciones equals (), hashCode () y toString (). Eso fallará miserablemente si no tiene una sesión abierta.

Nota (sobre equals ()):

a) en ambas versiones de equals () anteriores, es posible que desee utilizar uno o ambos de estos atajos también:

@Override
public boolean equals(final Object obj){
    if(obj == this) return true;  // test for reference equality
    if(obj == null) return false; // test for null
    // continue as above

b) dependiendo de su interpretación del contrato equals (), también puede cambiar la (s) línea (s)

    if(obj instanceof Bean){

a

    // make sure you run a null check before this
    if(obj.getClass() == getClass()){ 

Si usa la segunda versión, probablemente también desee llamar super(equals())dentro de su equals()método. Las opiniones difieren aquí, el tema se discute en esta pregunta:

forma correcta de incorporar superclase en una implementación de Guava Objects.hashcode ()?

(aunque se trata hashCode(), lo mismo se aplica a equals())

Nota (inspirada en el comentario de kayahr )

Objects.hashCode(..)(al igual que el subyacente Arrays.hashCode(...)) podría funcionar mal si tiene muchos campos primitivos. En tales casos, en EqualsBuilderrealidad puede ser la mejor solución.

Amigos, despierten! Desde Java 7 hay métodos auxiliares para equals y hashCode en la biblioteca estándar. Su uso es totalmente equivalente al uso de los métodos de guayaba.

Si no desea depender de una biblioteca de terceros (tal vez está ejecutando un dispositivo con recursos limitados) e incluso no desea escribir sus propios métodos, también puede dejar que el IDE haga el trabajo, por ejemplo, en uso de eclipse

Source -> Generate hashCode() and equals()...

Obtendrá un código 'nativo' que puede configurar a su gusto y que debe admitir en los cambios.

Ejemplo (eclipse Juno):

import java.util.Arrays;
import java.util.List;

public class FooBar {

    public String string;
    public List<String> stringList;
    public String[] stringArray;

    /* (non-Javadoc)
     * @see java.lang.Object#hashCode()
     */
    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((string == null) ? 0 : string.hashCode());
        result = prime * result + Arrays.hashCode(stringArray);
        result = prime * result
                + ((stringList == null) ? 0 : stringList.hashCode());
        return result;
    }
    /* (non-Javadoc)
     * @see java.lang.Object#equals(java.lang.Object)
     */
    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        FooBar other = (FooBar) obj;
        if (string == null) {
            if (other.string != null)
                return false;
        } else if (!string.equals(other.string))
            return false;
        if (!Arrays.equals(stringArray, other.stringArray))
            return false;
        if (stringList == null) {
            if (other.stringList != null)
                return false;
        } else if (!stringList.equals(other.stringList))
            return false;
        return true;
    }

}

EqualsBuilder y HashCodeBuilder tienen dos aspectos principales que son diferentes del código escrito manualmente:

• manejo nulo
• creación de instancias

EqualsBuilder y HashCodeBuilder facilitan la comparación de campos que podrían ser nulos. Con el código escrito manualmente, esto crea una gran cantidad de repeticiones.

El EqualsBuilder, por otro lado, creará una instancia por llamada al método igual. Si sus métodos de igualdad son llamados a menudo, esto creará muchas instancias.

Para Hibernate, la implementación de igual y hashCode no hace ninguna diferencia. Son solo un detalle de implementación. Para casi todos los objetos de dominio cargados con hibernación, se puede ignorar la sobrecarga de tiempo de ejecución (incluso sin análisis de escape) del generador . La sobrecarga de la base de datos y la comunicación será significativa.

Como skaffman mencionó, la versión de reflexión no se puede usar en el código de producción. La reflexión será lenta y la "implementación" no será correcta para todas las clases excepto las más simples. Tener en cuenta a todos los miembros también es peligroso ya que los miembros recién introducidos cambian el comportamiento del método igual. La versión de reflexión puede ser útil en el código de prueba.

Si no escribe el suyo, también existe la posibilidad de usar google guava (anteriormente colecciones de google)

Si solo está tratando con el bean de entidad donde id es una clave principal, puede simplificar.

   @Override
   public boolean equals(Object other)
   {
      if (this == other) { return true; }
      if ((other == null) || (other.getClass() != this.getClass())) { return false; }

      EntityBean castOther = (EntityBean) other;
      return new EqualsBuilder().append(this.getId(), castOther.getId()).isEquals();
   }

En mi opinión, no funciona bien con Hibernate, especialmente los ejemplos de la respuesta que comparan longitud, nombre e hijos para alguna entidad. Hibernate aconseja utilizar la clave comercial para ser utilizada en equals () y hashCode (), y tienen sus razones. Si usa el generador auto equals () y hashCode () en su clave comercial, está bien, solo los problemas de rendimiento deben considerarse como se mencionó anteriormente. Pero la gente generalmente usa todas las propiedades de lo que es IMO muy mal. Por ejemplo, actualmente estoy trabajando en un proyecto donde las entidades se escriben usando Pojomatic con @AutoProperty, lo que considero un patrón realmente malo.

Sus dos escenarios principales para usar hashCode () y equals () son:

• cuando coloca instancias de clases persistentes en un Conjunto (la forma recomendada de representar asociaciones de muchos valores) y
• cuando usa la reconexión de instancias separadas

Así que supongamos que nuestra entidad se ve así:

class Entity {
  protected Long id;
  protected String someProp;
  public Entity(Long id, String someProp);
}

Entity entity1 = new Entity(1, "a");
Entity entity2 = new Entity(1, "b");

Ambos son la misma entidad para Hibernate, que se han obtenido de alguna sesión en algún momento (su id y clase / tabla son iguales). Pero cuando implementamos auto equals () a hashCode () en todos los accesorios, ¿qué tenemos?

1. Cuando coloca la entidad2 en el conjunto persistente donde la entidad1 ya existe, esto se colocará dos veces y dará como resultado una excepción durante la confirmación.
2. Si desea adjuntar la entidad2 separada a la sesión, donde la entidad1 ya existe, (probablemente, no lo he probado especialmente) no se fusionarán correctamente.

Entonces, para el 99% del proyecto que realizo, utilizamos la siguiente implementación de equals () y hashCode () escritos una vez en la clase de entidad base, que es consistente con los conceptos de Hibernate:

@Override
public boolean equals(Object obj) {
    if (StringUtils.isEmpty(id))
        return super.equals(obj);

    return getClass().isInstance(obj) && id.equals(((IDomain) obj).getId());
}

@Override
public int hashCode() {
    return StringUtils.isEmpty(id)
        ? super.hashCode()
        : String.format("%s/%s", getClass().getSimpleName(), getId()).hashCode();
}

Para la entidad transitoria, hago lo mismo que Hibernate hará en el paso de persistencia, es decir. Yo uso el partido de instancia. Para los objetos persistentes, comparo la clave única, que es la tabla / id (nunca uso claves compuestas).

Por si acaso, a otros les resultará útil, se me ocurrió esta clase de ayuda para el cálculo de código hash que evita la sobrecarga de creación de objetos adicionales mencionada anteriormente (de hecho, la sobrecarga del método Objects.hash () es aún mayor cuando tienes herencia ya que creará una nueva matriz en cada nivel!).

Ejemplo de uso:

public int hashCode() {
    return HashCode.hash(HashCode.hash(timestampMillis), name, dateOfBirth); // timestampMillis is long
}

public int hashCode() {
    return HashCode.hash(super.hashCode(), occupation, children);
}

El ayudante HashCode:

public class HashCode {

    public static int hash(Object o1, Object o2) {
        return add(Objects.hashCode(o1), o2);
    }

    public static int hash(Object o1, Object o2, Object o3) {
        return hash(Objects.hashCode(o1), o2, o3);
    }

    ...

    public static int hash(Object o1, Object o2, ..., Object o10) {
        return hash(Objects.hashCode(o1), o2, o3, ..., o10);
    }

    public static int hash(int initial, Object o1, Object o2) {
        return add(add(initial, o1), o2);
    }

    ...

    public static int hash(int initial, Object o1, Object o2, ... Object o10) {
        return add(... add(add(add(initial, o1), o2), o3) ..., o10);
    }

    public static int hash(long value) {
        return (int) (value ^ (value >>> 32));
    }

    public static int hash(int initial, long value) {
        return add(initial, hash(value));
    }

    private static int add(int accumulator, Object o) {
        return 31 * accumulator + Objects.hashCode(o);
    }
}

Me imaginé que 10 es el número máximo razonable de propiedades en un modelo de dominio, si tiene más, debería pensar en refactorizar e introducir más clases en lugar de mantener un montón de cadenas y primitivas.

Los inconvenientes son: no es útil si tiene principalmente primitivas y / o matrices que necesita analizar profundamente. (Normalmente este es el caso cuando tiene que lidiar con objetos planos (de transferencia) que están fuera de su control).