Как правильно переопределить equals и hashCode в entity-классах?

Основные рекомендации по переопределению equals и hashCode для entity

• Методы equals и hashCode обязаны соответствовать общему контракту: если equals возвращает true, значения hashCode должны совпадать
• сравнивать следует только идентифицирующее поле, например primary key
• не включать в equals изменяемые поля, чтобы сохранять стабильность сравнения
• значение hashCode должно оставаться константным на протяжении жизненного цикла объекта
• для новых entity с null id в equals следует использовать сравнение по ссылке либо бизнес-логику
• необходимо соблюдать контракт equals: рефлексивность, симметричность и транзитивность
• переопределение требуется для корректной работы объектов в коллекциях Set и Map
• можно применять генераторы IDE или Lombok, учитывая id и бизнес-поля
• при использовании ORM необходимо учитывать влияние на lazy-loading и прокси-классы
• следует избегать heavy-проверок и сосредоточиться на ключевых атрибутах

Итог: для стабильной работы и корректного поведения в коллекциях equals и hashCode должны опираться на неизменяемый уникальный идентификатор.

Подробный ответ

Основной ответ

Для entity-классов, используемых, например, в JPA или Hibernate, корректное переопределение методов equals() и hashCode() имеет большое значение при работе с коллекциями, кэшированием и ORM-инструментами. Обычно для реализации этих методов выбирают уникальный неизменяемый идентификатор — как правило, первичный ключ (ID). При этом следует помнить, что до сохранения сущности, то есть до вызова persist, ID может отсутствовать, поэтому для такого случая применяют специальные практики.

Ключевые моменты

• Опирайтесь на идентификатор (ID): если ID уже присвоен, методы equals и hashCode должны использовать его, поскольку именно этот идентификатор обеспечивает уникальность сущности в базе данных.
• Учитывайте transient-состояние: пока ID имеет значение null, например у новой сущности, необходимо предусмотреть fallback — ссылочное сравнение (super.equals) либо составной ключ из уникальных и неизменяемых бизнес-полей.
• Обеспечьте совместимость с коллекциями: в течение всего времени нахождения объекта в коллекции hashCode должен быть стабильным, иначе нарушится контракт HashMap/HashSet. Поэтому менять ID после добавления объекта в коллекцию нельзя.
• Не добавляйте изменяемые поля: бизнес-атрибуты, способные изменяться, не должны участвовать в equals и hashCode, поскольку это может нарушить сравнение и поиск объектов в коллекциях.
• Применяйте библиотеки и паттерны: Lombok с @EqualsAndHashCode, а также Apache Commons EqualsBuilder/HashCodeBuilder допустимы при осторожном использовании — с явным указанием исключений и поля ID.

Практический контекст

В проектах на JPA у сущностей обычно используется ID с автоинкрементом. Для новых объектов equals возвращает false при сравнении с любыми сохраненными сущностями, пока ID == null. После сохранения ID получает значение, и equals начинает основываться на нем. Такой вариант помогает избежать проблем с кэшированием и Lazy Loading, характерных для ORM. Логику также необходимо тестировать, чтобы исключить subtle bugs при работе с коллекциями, например HashSet или HashMap.

Если хотите, могу показать пример кода на Java с такой реализацией.