Apache Commons égale / hashCode builder [fermé]

Réveillez-vous! depuis Java 7 il y a des méthodes d'aide pour égale et hashCode dans la bibliothèque standard. Leur utilisation est totalement équivalente à l'utilisation de Goyave méthodes.

si vous ne voulez pas dépendre d'une bibliothèque tierce (peut-être que vous utilisez un périphérique avec des ressources limitées) et que vous ne voulez même pas taper vos propres méthodes, vous pouvez aussi laisser L'IDE faire le travail, par exemple dans l'utilisation d'eclipse

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

vous obtiendrez le code 'natif' que vous pouvez configurer comme vous voulez et que vous devez prise en charge sur les modifications.

exemple (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;
    }

}

La EqualsBuilder et HashCodeBuilder ont deux aspects principaux qui sont différentes de manuellement le code écrit:

• manutention nulle
• création d'instance

grâce à EqualsBuilder et HashCodeBuilder, il est plus facile de comparer des champs qui pourraient être nuls. Avec le code écrit manuellement cela crée beaucoup de boilerplate.

le constructeur D'equals va d'autre part créer une instance per égale appel de méthode. Si vos méthodes égales sont souvent appelées, cela créera beaucoup d'instances.

pour hiberner les égaux et l'implémentation du hashCode ne font aucune différence. Ils sont juste un détail d'implémentation. pour presque tous les objets du domaine chargés avec hibernate, le runtime overhead (même sans analyse de fuite) du constructeur peut être ignoré . Les frais généraux de base de données et de communication seront importants.

comme skaffman mentionné la version de réflexion ne peut pas être utilisé dans le code de production. La réflexion sera de ralentir et la "mise en œuvre" ne sera pas correcte pour toutes les classes sauf les plus simples. La prise en compte de tous les membres est également dangereuse, car les membres nouvellement introduits modifient le comportement de la méthode equal. La réflexion peut être utile dans le code de test.

si vous ne voulez pas écrire votre propre, Il ya aussi la possibilité d'utiliser google guava (anciennement google collections)

si vous avez juste affaire à l'entité bean où id est une clé primaire, vous pouvez simplifier.

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

à mon avis, il ne joue pas bien avec Hibernate, en particulier les exemples de la réponse comparant la longueur, le nom et les enfants pour une entité. Hibernate conseille d'utiliser la clé pour être utilisé dans equals() et hashCode(), et ils ont leurs raisons. Si vous utilisez auto equals() et hashCode() générateur sur votre clé d'entreprise, c'est ok, juste des problèmes de performance doivent être considérés comme mentionné précédemment. Mais les gens utilisent généralement toutes les propriétés ce qui est IMO très mauvaise. Par exemple, je travaille actuellement sur un projet où les entités sont écrites en utilisant Pojomatic avec @AutoProperty, ce que je considère comme un très mauvais modèle.

leurs deux principaux scénarios pour utiliser hashCode () et equals () sont:

• quand vous mettez des instances de classes persistantes dans un ensemble (le
• lorsque vous utilisez le rattachement d'instances détachées

donc supposons que notre entité ressemble à ceci:

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

les deux sont la même entité pour L'hibernation, qui ont été récupérées d'une session à un moment donné (leur id et classe/table sont égaux). Mais quand nous implémentons auto equals () un hashCode () sur tous les accessoires, qu'avons-nous?

1. lorsque vous mettez l'entity2 à l'ensemble persistant où l'entity1 existe déjà, cela sera mis deux fois et aura pour résultat exception pendant la commit.
2. si vous voulez attacher l'entité2 détachée à la session, où entity1 existe déjà, ils (probablement, je n'ai pas testé cela en particulier) ne seront pas fusionnés correctement.

ainsi, pour 99% des projets que je réalise, nous utilisons l'implémentation suivante d'equals () et de hashCode () écrits une fois dans la classe de base entity, ce qui est compatible avec les concepts D'hibernation:

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

pour l'entité transitoire Je fais la même chose que Hibernate fera sur l'étape de persistance, c.-à-d.. J'utilise la correspondance d'instance. Pour les objets persistants je compare la clé unique, qui est la table/id (je n'utilise jamais les clés composites).

juste au cas où, d'autres le trouveront utile, je suis venu avec cette classe D'aide pour le calcul de code de hachage qui évite la création d'objet supplémentaire au-dessus mentionné ci-dessus (en fait, la au-dessus des objets.la méthode hash () est encore plus grande quand vous avez l'héritage car elle créera un nouveau tableau à chaque niveau!).

exemple d'utilisation:

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

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

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

j'ai pensé que 10 est le maximum nombre raisonnable de propriétés dans un modèle de domaine, si vous avez plus que vous devriez penser à refactoring et introduire plus de classe au lieu de maintenir un tas de chaînes et de primitives.

les inconvénients sont: il n'est pas utile si vous avez principalement des primitives et/ou des tableaux que vous devez hachez profondément. (Normalement c'est le cas lorsque vous avez à traiter avec télévision (transfert) des objets qui sont hors de votre contrôle).