Antwoord.

In Java zijn de methoden equals() en hashCode() van cruciaal belang voor de correcte werking van collecties zoals HashMap, HashSet en anderen. Deze kwestie wordt vaak over het hoofd gezien door beginnende ontwikkelaars, terwijl schending van de contracten van deze methoden leidt tot moeilijk te detecteren fouten in de logica van toepassingen.

Geschiedenis van de kwestie:

In de programmeertaal Java erven alle klassen oorspronkelijk de methoden equals() en hashCode() van de klasse Object. Standaard vergelijkt equals() objectverwijzingen (dat wil zeggen, hun fysieke locatie in het geheugen), en hashCode() retourneert een unieke code voor elk object. Voor gebruikersklassen is het echter vaak nodig om objecten op inhoud te vergelijken in plaats van op verwijzing.

Probleem:

Als de methoden equals() en hashCode() niet worden overschreven of onjuist zijn overschreven, kunnen objecten zich onverwacht gedragen in collecties die op hashing zijn gebaseerd. Dit leidt tot het ontbreken van elementen, duplicatie of zoekfouten.

Oplossing:

Overschrijf altijd beide methoden samen en volg strikt het contract:

Als a.equals(b) == true, dan moet a.hashCode() == b.hashCode() zijn.
Als a.equals(b) == false, is de eis voor hashCode dat uniciteit niet verplicht is.

Voorbeeld van een correcte implementatie:

public class Person {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return age == person.age && Objects.equals(name, person.name);
    }

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

Belangrijke kenmerken:

De methode equals() moet reflexief, symmetrisch, transitief en consistent zijn.
De methode hashCode() moet dezelfde waarde retourneren voor een object met onveranderlijke gegevens.
In de overschreven methoden moeten juist de significante velden worden vergeleken.

Vragen met een valstrik.

Kan je alleen equals() gebruiken zonder hashCode() in klassen die in HashSet worden opgeslagen?

Nee. Als je alleen equals() hebt overschreven, kunnen collecties op basis van hashing de uniciteit van objecten niet correct bepalen. HashSet vergelijkt eerst hashCode, daarna equals.

Moet je alle velden van de klasse gebruiken in equals() en hashCode()?

Nee. Alleen de velden die belangrijk zijn voor de logische identiteit van de klasse. Bijvoorbeeld, als een object een interne, unieke identificator heeft, is het voldoende om deze te gebruiken.

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    User user = (User) o;
    return Objects.equals(id, user.id);
}

Is het mogelijk om te baseren op een getter in plaats van een direct veld in equals()?

Over het algemeen wel, als er geen bijwerkingen zijn en de getter stabiel is. Maar er is een risico dat de getter bij verschillende aanroepen verschillende waarden retourneert — dan zal het gedrag onvoorspelbaar zijn.

Typische fouten en antipatterns

Niet hashCode() overschrijven bij een overschreven equals().
Mutable velden gebruiken in berekeningen van hashCode().
Het contract tussen deze methoden negeren.

Voorbeelden uit het leven

Negatief geval

Een ontwikkelaar implementeert de klasse User en definieert alleen de methode equals(), en vergeet hashCode(). Als gevolg van het toevoegen en zoeken van objecten in HashSet ontstaan duplicaten en "verdwijnen" elementen.

Voordelen:

Minimaal code

Nadelen:

Werkzaamheid van de collectie is aangetast
Onduidelijke en moeilijk te traceren bugs in de applicatie

Positief geval

Een ontwikkelaar implementeert beide methoden strikt volgens het contract, en gebruikt alleen id binnen de logica van gelijkheid en hashing. Collecties gedragen zich zoals verwacht, zoeken en opslaan werken correct.