Quand vous redéfinissez equals() pour définir l'égalité logique, vous devez également redéfinir hashCode() — car les collections basées sur le hachage (HashMap, ) reposent sur le contrat que . Violer cela entraîne des bugs subtils et difficiles à trouver.
HashSet// by default, equals() compares IDENTITY (same object?), hashCode() is based on memory address
Person p1 = new Person("Ann", 30);
Person p2 = new Person("Ann", 30);
p1.equals(p2); // false by default — different objects, even with same data
Sans redéfinition, deux objets avec un contenu identique ne sont "pas égaux" — généralement pas ce que vous voulez pour les objets de valeur.
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person p = (Person) o;
return age == p.age && Objects.equals(name, p.name); // compare by CONTENT
}
@Override
public int hashCode() {
return Objects.hash(name, age); // MUST be consistent with equals()
}
Le contrat : si a.equals(b) est vrai, alors a.hashCode() == b.hashCode() DOIT être vrai.
Person p1 = new Person("Ann", 30);
Person p2 = new Person("Ann", 30); // equal by our equals()
Set<Person> set = new HashSet<>();
set.add(p1);
set.contains(p2); // ❌ likely FALSE — even though p1.equals(p2)!
Pourquoi ? HashMap/HashSet utilisent d'abord hashCode() pour trouver le bon bucket, puis equals() à l'intérieur. Avec le hashCode() par défaut (basé sur l'identité), p1 et p2 se retrouvent dans des buckets différents, donc contains ne les compare jamais — l'ensemble pense qu'ils sont différents. Cela produit des bugs déconcertants : des doublons dans un Set, des recherches en map échouées, etc.
1. equal objects → equal hash codes (REQUIRED for correctness)
2. unequal objects MAY have the same hash (collisions are allowed)
3. hashCode() must be consistent (same object → same code, unchanged)
4. equals() must be reflexive, symmetric, transitive, consistent
record Person(String name, int age) {} // records auto-generate equals/hashCode/toString!
Les records Java (et la génération par IDE / Lombok) produisent pour vous des equals/hashCode corrects et cohérents.
Le contrat equals/hashCode est l'une des règles les plus importantes de Java — et l'une des plus fréquemment violées.
Redéfinir equals() sans hashCode() casse les collections basées sur le hachage de manière difficile à déboguer : les objets que vous considérez égaux se "perdent" dans HashMap/HashSet (recherches échouées, doublons fantômes) car ils se hachent dans des buckets différents.
Comme ces collections sont omniprésentes, chaque classe de type valeur utilisée comme clé ou élément d'ensemble doit redéfinir les deux de manière cohérente.
Comprendre pourquoi (le mécanisme de recherche bucket-puis-equals) — et utiliser des records ou du code généré pour le faire correctement — est essentiel pour un comportement correct et un sujet classique d'entretien qui révèle une vraie compréhension du fonctionnement des collections Java.