Implémentation d'equals et hashCode dans une classe annotée Entity

Crédit photo : Groum – Licence Commons Creatives 2.0

Quelles sont les bonnes pratiques concernant les méthodes hashCode() et equals() pour les Entités JPA ?

Lorsque vous stockez des objets mappés avec un ORM comme Hibernate, dans des collections, il est intéressant de regarder comment implémenter correctement les méthodes equals() et hashCode(). C’est aussi une approche à comprendre en général dès lors qu’il devient nécessaire de stocker un objet dans une collection.

The general contract is: if you want to store an object in a List, Map or a Set then it is an requirement that equals and hashCode are implemented so they obey the standard contract as specified in the documentation.

L’approche Domain Driven Design donne un nom à ces objets, qui portent une clé d’identification unique… ce sont des Entities. Nous faisons en fait la différence entre les Values Objets dont l’identité est basée sur les valeurs des attributs des champs et les Entities, dont l’identité est déterminée par un ou plusieurs attributs.

Un Value Object

Un Value Object sera immuable. Ce n’est pas obligatoire, mais logique. S’il était possible de changer la valeur de l’un de ses attributs, ce serait alors un autre Value Object.
Prenez l’adresse postale où vous habitez et imaginez sa modélisation. Constituée d’un numéro, d’un nom de rue, d’un code postal et d’une ville, c’est bien l’ensemble de ces 4 attributs qui fait l’identité de l’objet. Si je change de ville, ce n’est plus la même adresse.

public class Address {
    private Integer number;
    private String streetName;
    private Integer zip;
    private String city;

    public Address(Integer number, String streetName, Integer zip, String city) {
        this.number = number;
        this.streetName = streetName;
        this.zip = zip;
        this.city = city;
    }

    public Integer getNumber() {
        return number;
    }

    public String getStreetName() {
        return streetName;
    }

    public Integer getZip() {
        return zip;
    }

    public String getCity() {
        return city;
    }

}

En conséquence il est logique et normal d’utiliser le générateur de votre IDE pour écrire les méthodes equals et hashCode :

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

        Address address = (Address) o;

        if (city != null ? !city.equals(address.city) : address.city != null) return false;
        if (number != null ? !number.equals(address.number) : address.number != null) return false;
        if (streetName != null ? !streetName.equals(address.streetName) : address.streetName != null) return false;
        if (zip != null ? !zip.equals(address.zip) : address.zip != null) return false;

        return true;
    }

    @Override
    public int hashCode() {
        int result = number != null ? number.hashCode() : 0;
        result = 31 * result + (streetName != null ? streetName.hashCode() : 0);
        result = 31 * result + (zip != null ? zip.hashCode() : 0);
        result = 31 * result + (city != null ? city.hashCode() : 0);
        return result;
    }

Entity

Une entité, et là je me rapproche maintenant de JPA, est un objet dont l’identité est déterminée par une ou plusieurs attributs. Prenons le cas simple où je n’ai qu’un Id de type Long sur une Entité personne. Votre base de donnée a déjà une contrainte et une intégrité, qui fixe l’unicité d’un objet avec la PRIMARY_KEY. C’est ce que l’on retrouve dans votre domaine, sur votre Entité.

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;

    private String firstName;
    private String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public Long getId() {
        return id;
    }

}

Notez qu’il n’y a pas de méthode setId, puisque nous laissons JPA se charger de l’affectation de l’id technique de notre classe Person.

En conséquence, il est alors possible de définir de manière différente les méthodes equals() et hashCode() afin de n’utiliser que l’ID technique. Qu’y gagne-t-on ? Un code plus léger ? Oui mais ce n’est pas l’intérêt principal de cette approche. C’est aussi le respect du contrat de l’identité, vu sous l’approche Domain Driven Design.
Voici une première implémentation, qui n’est pas complète, afin de vous montrer le principe :

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

        Person person = (Person) o;

        if (!id.equals(person.id)) return false;

        return true;
    }

    @Override
    public int hashCode() {
        return id.hashCode();
    }

La critique de ce premier script : je pars du principe qu’id n’est jamais null. Or c’est faux, à la création de l’objet par exemple. L’id n’est pas encore affecté par JPA. Il y a donc un souci.

Nous pouvons contourner ce problème en utilisant le VMID dont RMI se sert depuis java 1.4.2. D’après la Javadoc, le VMID est unique :

A VMID is a identifier that is unique across all Java virtual machines. VMIDs are used by the distributed garbage collector to identify client VMs.

A priori donc, nous n’aurons pas de soucis avec la JVM.

Il ne reste plus qu’à réécrire le equals/hashCode afin de se baser sur cet ID lorsque l’id technique est null :

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

        Person person = (Person) o;

        if (id == null) {
            if (person.uidInEquals == null) {
                return false;
            }
            if (uidInEquals == null) {
                uidInEquals = new java.rmi.dgc.VMID();
            }
            return (person.uidInEquals.equals(uidInEquals));
        }

        return id.equals(person.id);

    }

    @Override
    public int hashCode() {
        if(id==null){
            if(uidInEquals==null){
               uidInEquals = new java.rmi.dgc.VMID();
            }
            return uidInEquals.hashCode();
        }
        return id.hashCode();
    }

    private java.rmi.dgc.VMID uidInEquals = null;
...
...

Ce code est optimisable, et je l’ai vu la première fois lorsque j’avais testé le logiciel Celerio. Le site d’Hibernate présente avec plus de détails une solution complète et optimisée sur cette page.

L’approche clé métier

Une dernière approche est de ne pas utiliser l’id technique du tout mais de se baser sur la valeur des champs. C’est intéressant, et c’est un mix entre la notion de Value Object et la notion d’Entity. Si par exemple nous pensons que le prénom et le nom sont assez discriminant dans notre application, rien ne nous empêche d’écrire ce code :

@Entity
public class Person {
    @Id
    @GeneratedValue
    public Long id;

    private String firstName;
    private String lastName;

    public Person(final String firstName, final String lastName) {
        if(lastName==null){
            throw new IllegalArgumentException("lastname cannot be null");
        }
        if(firstName==null){
            throw new IllegalArgumentException("firstname cannot be null");
        }
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public String getFirstName() {
        return firstName;
    }


    public String getLastName() {
        return lastName;
    }

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

        Person person = (Person) o;

        if (!firstName.equals(person.firstName)) return false;
        if (!lastName.equals(person.lastName)) return false;

        return true;
    }

    @Override
    public int hashCode() {
        int result = firstName.hashCode();
        result = 31 * result + lastName.hashCode();
        return result;
    }
}

Si vous regardez attentivement ce code, vous verrez que j’ai retiré les setters, et que j’ai renforcé mon constructeur afin de rendre obligatoire le nom de famille et le prénom.

Pour calculer l’égalité de l’objet ou son hashCode, il est alors possible de se baser sur les valeurs des attributs… la définition même d’un Value Object.

Qu’en pensez-vous ?

Références
A lire absolument : equals and hashCode in Hibernate

Articles similaires:

Scala, partie 1 Exemple d'utilisation de java.util.BitSet Comment configurer l'encoding en UTF-8 dans JBoss Générer une application type CRUD en JSF 2.0 avec NetBeans 6.9