Miért kell az equals() és a hashCode() metódust együtt felüldefiniálni?

Question

Accepted Answer

Ha felüldefiniálod az `equals()` metódust a logikai egyenlőség definiálásához, **kötelezően** felül kell definiálnod a `hashCode()` metódust is — mivel a hash-alapú kollekciók (`HashMap`, `HashSet`) arra az szerződésre támaszkodnak, hogy az **egyenlő objektumok azonos hash kódokkal rendelkeznek**. Ennek megsértése finom, nehezen megtalálható bugokhoz vezet. ## Az alapértelmezett viselkedés ```java // 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 ``` Felüldefinálás nélkül két azonos tartalommal rendelkező objektum "nem egyenlő" — általában nem az, amit value objektumok esetén szeretnél. ## Az equals() felüldefiniálása logikai egyenlőséghez ```java @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 } ``` ## A kritikus szabály: a hashCode() felüldefiniálása is szükséges ```java @Override public int hashCode() { return Objects.hash(name, age); // MUST be consistent with equals() } ``` **A szerződés:** ha `a.equals(b)` igaz, akkor `a.hashCode() == b.hashCode()` **szükségképpen** igaz kell legyen. ## Mi szakad meg, ha felüldefiniálod az equals()-t, de nem a hashCode()-ot ```java Person p1 = new Person("Ann", 30); Person p2 = new Person("Ann", 30); // equal by our equals() Set set = new HashSet<>(); set.add(p1); set.contains(p2); // ❌ likely FALSE — even though p1.equals(p2)! ``` Miért? A HashMap/HashSet először a `hashCode()` alapján keresi meg a megfelelő **bucketet**, majd az abban lévő elemeket hasonlítja össze `equals()` segítségével. Az alapértelmezett (identitás-alapú) `hashCode()`-dal a `p1` és `p2` *különböző* bucketekbe kerülnek, így a `contains()` soha nem hasonlítja össze őket — a halmaz azt gondolja, hogy különbözőek. Ez zavaró bugokat eredményez: duplikátumok a Set-ben, sikertelen map lookupok, stb. ## A szerződés szabályai ```text 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 ``` ## Modern megoldás ```java record Person(String name, int age) {} // records auto-generate equals/hashCode/toString! ``` A Java **recordok** (és az IDE-generálás / Lombok) helyes, konzisztens `equals`/`hashCode` implementációt hoznak létre helyetted. ## Miért fontos Az equals/hashCode szerződés az egyik legfontosabb — és leggyakrabban megsértett — szabály a Java-ban. Az `equals()` felüldefiniálása `hashCode()` nélkül megtöri a hash-alapú kollekciókat olyan módokon, amelyek nehezen debugolhatók: az objektumok, amelyeket egyenlőnek tekintesz, "elvesznek" a `HashMap`/`HashSet`-ben (sikertelen lookupok, fantom duplikátumok), mivel különböző bucketekbe hashelődnek. Mivel ezek a kollekciók mindenütt jelen vannak, minden olyan value-type osztályt, amelyet kulcsként vagy set elemként használsz, **mindkettőt** konzisztensen felül kell definiálnod. Annak megértése, *hogy miért* (a bucket-majd-equals lookup mechanizmus) — és recordok vagy generált kód használata a helyes implementációhoz — nélkülözhetetlen a helyes viselkedéshez és egy klasszikus interjúkérdés, amely a Java kollekciók működésének valódi megértését mutatja ki.