Ответ.

В Java методы equals() и hashCode() крайне важны для корректной работы коллекций, таких как HashMap, HashSet, и других. Этот вопрос часто упускается начинающими разработчиками, хотя нарушение контрактов этих методов приводит к труднообнаружимым ошибкам в логике приложений.

История вопроса:

В языке Java изначально все классы наследуют методы equals() и hashCode() от класса Object. По умолчанию, equals() сравнивает ссылки на объекты (т.е. их физическое расположение в памяти), а hashCode() возвращает уникальный код для каждого объекта. Однако для пользовательских классов часто необходимо сравнивать объекты по содержимому, а не по ссылке.

Проблема:

Если методы equals() и hashCode() не переопределены или переопределены некорректно, то объекты могут вести себя неожиданно в коллекциях, основанных на хешировании. Это приведёт к отсутствию элементов, дублированию или ошибкам поиска.

Решение:

Переопределять оба метода всегда совместно, строго соблюдая контракт:

Если a.equals(b) == true, то a.hashCode() == b.hashCode()
Если a.equals(b) == false, требование к hashCode таково, что уникальность не обязательна

Пример корректной реализации:

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

Ключевые особенности:

Метод equals() должен быть рефлексивным, симметричным, транзитивным и консистентным.
Метод hashCode() должен возвращать одно и то же значение для объекта при неизменяемых данных.
В переопределённых методах должны сравниваться именно значимые поля.

Вопросы с подвохом.

Можно ли использовать только equals() без hashCode() в классах, которые будут храниться в HashSet?

Нет. Если вы переопределили только equals(), коллекции на базе хеширования не будут корректно определять уникальность объектов. HashSet сначала сравнивает hashCode, а затем equals.

Обязательно ли использовать все поля класса в equals() и hashCode()?

Нет. Только значимые для логической идентичности класса. Например, если у объекта есть внутренний, уникальный идентификатор, достаточно его.

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

Можно ли базироваться на геттере вместо прямого поля в equals()?

Обычно да, если нет побочных эффектов и геттер стабилен. Но есть риск, что геттер возвращает разные значения на разных вызовах — тогда поведение будет непредсказуемым.

Типовые ошибки и анти-паттерны

Не переопределять hashCode() при переопределённом equals().
Использовать mutable поля в расчётах hashCode().
Игнорировать контракт между этими методами.

Пример из жизни

Негативный кейс

Разработчик реализует класс User и определяет только метод equals(), забыв hashCode(). В результате добавления и поиска объектов в HashSet происходят дубли и "теряются" элементы.

Плюсы:

Минимальный код

Минусы:

Работа коллекции нарушена
Невнятные и трудноуловимые баги в приложении

Позитивный кейс

Разработчик реализует оба метода строго по контракту, использует только id внутри логики равенства и хеширования. Коллекции ведут себя ожидаемо, поиск и хранение работают корректно.