equals/ hashCode/ toString для entity

1. Роль equals/hashCode/toString в entity

Если вы только начинаете, очень хочется думать так: «Ну подумаешь, equals и hashCode… IDE же умеет сгенерировать, а toString вообще для красоты». В обычных DTO это часто прокатывает. В entity — нет. Entity живёт в мире, где объект в памяти связан с записью в БД, где идентичность меняется по ходу жизненного цикла, а “просто вывести объект в лог” может внезапно привести к неожиданным действиям. Поэтому мы сегодня будем не “генерировать как обычно”, а проектировать эти методы так, чтобы они соответствовали persistence‑реальности.

Начнём с очень короткой, но полезной таблички. Она не заменяет понимание, но помогает не потеряться:

И да, это тот редкий случай, когда “просто нажать Alt+Insert → Generate equals/hashCode” может быть не помощником, а скрытым вредителем.

2. Идентичность: объект, id и business key

Чтобы не писать equals/hashCode на ощущениях, нужно понимать, что именно мы считаем «одинаковым». В Java у объекта есть объектная идентичность: два разных new Product() — это два разных объекта, даже если у них одинаковые поля. В базе данных идентичность обычно задаётся первичным ключом (id). А в бизнесе часто есть ещё “естественная” идентичность: sku у товара, code у категории, orderNumber у заказа. Вот эта тройка и создаёт путаницу, если пытаться писать equals/hashCode “как для DTO”.

Удобно держать в голове такую схему (без фанатизма, просто как ориентир):

flowchart TD
  A["Object identity
в JVM"] -->|"equals/hashCode должны быть стабильными"| B["Collections: Set/Map"]
  C["Database identity
id в БД"] -->|"появляется не сразу"| D["Entity lifecycle"]
  E["Business identity
sku/code..."] -->|"может быть стабильной"| F["Безопасная база для equals/hashCode"]

Теперь привяжем это к состояниям из лекции 1. Когда Product только создан через new, у него обычно нет id. В managed‑состоянии он уже связан с persistence‑контекстом и со строкой в БД (и тогда id уже есть или появится при вставке). В detached объект по‑прежнему живёт в Java, но JPA его не отслеживает. То есть если вы пишете equals/hashCode “по id”, вы фактически привязываете равенство к полю, которое у объекта не всегда есть и которое может появиться позже.

И вот тут начинается “магия”, но не Hibernate — а наша собственная, человеческая: мы хотим, чтобы коллекции и сравнения работали стабильно, а сами выбираем основу, которая нестабильна.

3. Антипример №1: equals/hashCode только по generated id

Сначала покажем самый частый “дефолт из интернета”: сравнение только по id. Код выглядит логично, особенно если вы мысленно воспринимаете entity как «строку таблицы». Но проблема в том, что для нового объекта id == null, а потом вдруг становится не null. И вот тогда HashSet начинает смотреть на вас с немым укором.

Рискованный вариант (выглядит прилично, но ведёт к сюрпризам):

import java.util.Objects;

@Override
public boolean equals(Object o) {
    if (this == o) return true; // быстрый путь: один и тот же объект в памяти
    if (!(o instanceof Product other)) return false; // instanceof безопаснее для ORM-прокси
    return Objects.equals(id, other.id); // ВНИМАНИЕ: у transient-объекта id == null
}

import java.util.Objects;

@Override
public int hashCode() {
    // ВНИМАНИЕ: если id меняется после persist/flush, то hashCode тоже меняется
    return Objects.hashCode(id);
}

На бумаге всё красиво. На практике — смотрим поведение коллекции. Представим, что вы где-то держите Set<Product> (это вообще обычная история: список уникальных позиций, уникальных товаров в заказе, уникальных категорий и т.д.). Сценарий такой: вы добавили transient‑объект в HashSet, потом сохранили его, и id появился.

Мини‑демо, которое показывает саму идею поломки (в реальном приложении id появится из JPA, а не от рук):

import java.util.HashSet;
import java.util.Set;

Set<Product> set = new HashSet<>();

Product p = new Product();
p.setSku("PHONE-1");
set.add(p); // объект попал в "корзину" HashSet по текущему hashCode (id == null)

p.setId(1L); // представим, что id появился после persist/flush
System.out.println(set.contains(p)); // false: hashCode изменился, HashSet ищет в другой "корзине"

Если вы сейчас подумали “ну я же не буду делать setId руками”, то вы мыслите правильно. Но JPA сделает “похожее” за вас: объект лежит в HashSet, а поле, участвующее в hashCode, меняется из‑за сохранения. С точки зрения HashSet это примерно как если бы вы положили ключ в один ящик, а потом тихо подменили у ключа форму, и он стал подходить к другому ящику.

Проблема становится особенно коварной, когда баг проявляется не сразу. Днём вы добавили объект в set, вечером сделали save, ночью пошли проверять contains, и внезапно “товара нет”. И это не баг Java — это следствие нарушенного контракта: объект, который является ключом в hash‑коллекции, должен иметь стабильный hashCode, пока он там лежит.

4. Антипример №2: hashCode по изменяемым полям

После осознания проблемы с id новички часто делают следующий “логичный” шаг: «Окей, id меняется. Тогда возьму name или price! Они же есть сразу». И вот тут начинается второй уровень боли. Потому что имя и цена — изменяемые поля. И если hashCode зависит от них, вы снова нарушаете контракт HashSet/HashMap, только теперь уже своими руками, обычным сеттером.

Например, вот так делать не надо:

import java.util.Objects;

@Override
public int hashCode() {
    // ВНИМАНИЕ: name — изменяемое поле, значит hashCode будет "плавать" после обновлений
    return Objects.hash(name);
}

И опять демо на чистом Java, чтобы не прятаться за ORM:

import java.util.HashSet;
import java.util.Set;

Set<Category> set = new HashSet<>();

Category c = new Category();
c.setCode("phones");
c.setName("Phones");
set.add(c); // объект добавлен в HashSet по hashCode, зависящему от name (если вы так сделали)

c.setName("Smartphones"); // обычное бизнес-обновление меняет hashCode
System.out.println(set.contains(c)); // false: HashSet ищет объект по старому hashCode

Обратите внимание на “психологическую ловушку”: вам кажется, что вы просто переименовали категорию. Но HashSet считает иначе: вы поменяли “координаты” объекта в структуре данных.

В нашем mini‑shop как раз будут сценарии изменения имени товара, изменения цены и активации/деактивации. Это нормальные бизнес‑операции. Поэтому делать hashCode зависящим от этих полей — значит заранее закладывать в проект “странные баги в коллекциях”.

5. Здоровый baseline: equals/hashCode по business key

Теперь к хорошей новости: в большинстве прикладных систем есть естественные уникальные признаки, которые удобны как опора для сравнения. В нашем проекте это sku для Product и code для Category. Такие поля обычно уникальны (в идеале закреплены UNIQUE в БД), задаются при создании и не меняются каждую минуту. То есть это хорошая кандидатура для “business identity” — той самой идентичности, которую бизнес действительно считает важной.

Но тут нужно честно проговорить условия, иначе мы просто поменяем одну магию на другую. Для business key как базы equals/hashCode важно, чтобы он был устойчивым: вы задаёте его один раз и дальше не меняете (или меняете крайне осознанно и точно не когда объект лежит в HashSet). В учебном проекте мы принимаем простое правило: sku и code — стабильные.

Посмотрим на базовую реализацию для Product. Она специально “защищается” от null: два новых товара без sku не должны считаться равными.

import java.util.Objects;

@Override
public boolean equals(Object o) {
    if (this == o) return true; // один и тот же объект в памяти
    if (!(o instanceof Product other)) return false; // поддержка сравнения с ORM-прокси
    return sku != null && sku.equals(other.sku); // null не считаем "равным null", чтобы не склеить два transient
}

import java.util.Objects;

@Override
public int hashCode() {
    // Стабильность hashCode достигается тем, что sku считаем неизменяемым business key
    return Objects.hashCode(sku);
}

И сразу важный момент: Objects.hashCode(sku) вернёт 0, если sku == null. Это нормально, потому что equals при sku == null вернёт false (кроме случая this == o). То есть два разных “пустых” объекта не станут равными только потому, что их hashCode одинаковый. Одинаковый hashCode — это разрешено, Java‑коллекции это переживают, главное чтобы equals был корректным.

Давайте на минутку сравним поведение:

Product a = new Product();
Product b = new Product();

// Два transient-объекта без sku НЕ должны считаться равными
System.out.println(a.equals(b)); // false

Product a = new Product();
a.setSku("PHONE-1");

Product b = new Product();
b.setSku("PHONE-1");

// Два объекта с одинаковым sku считаются "одним и тем же товаром" по business key
System.out.println(a.equals(b)); // true

Вторая строчка кажется спорной: “как это — два разных объекта равны?” А вот так: с точки зрения business‑идентичности это “тот же товар”, потому что sku — уникален. В этом и смысл business key.

Таблица выбора основы

Чтобы не запоминать правила как заклинания, держим компактную матрицу:

instanceof vs getClass() и прокси

В обычных Java‑классах многие любят писать equals с проверкой getClass(): мол, “сравниваем только объекты ровно одного класса, без наследников”. В мире ORM это может неожиданно сыграть против вас, потому что Hibernate иногда возвращает не “чистый” объект класса Product, а специальный объект‑обёртку (прокси), который выглядит как Product, но класс у него другой (технически — наследник).

Пока мы не ушли в будущие темы, достаточно одной простой мысли: в JPA/Hibernate объект, который вы видите, иногда может быть не “ровно ваш класс”, а его прокси‑версия. И тогда getClass() сравнение ломается.

Плохой (слишком строгий) кусочек, который может подставить:

@Override
public boolean equals(Object o) {
    // ВНИМАНИЕ: для ORM-прокси getClass() может отличаться, хотя по смыслу это та же сущность
    if (o == null || getClass() != o.getClass()) return false;
    // ...
    return true;
}

В рамках нашего курса более практичный baseline — использовать instanceof (а в Java 25 ещё и с pattern matching, чтобы не кастовать руками). Так сравнение останется корректным, даже если одна из сторон — прокси.

@Override
public boolean equals(Object o) {
    if (this == o) return true; // быстрый путь
    if (!(o instanceof Product other)) return false; // instanceof "дружит" с прокси-наследниками
    return sku != null && sku.equals(other.sku); // сравниваем по стабильному business key
}

Если у вас сейчас ощущение “я не до конца понял, что такое прокси”, это нормально: нам не нужно нырять в байткод и внутренности. Достаточно запомнить инженерное правило: для entity чаще безопаснее instanceof, чем getClass(), если вы не делаете отдельный курс по “идеальной теории equals”.

toString() для entity: коротко и безопасно

С toString ситуация коварна по‑своему. Он кажется “безопасным”, потому что “ну это же просто строка”. Но toString активно вызывается в самых неожиданных местах: когда вы логируете объект, когда IDE показывает его в дебаге, когда исключение выводит контекст, когда вы случайно сделали log.info("product={}", product). Поэтому плохой toString — это не просто некрасиво, это часто дорого и иногда даже опасно.

Начнём с простого правила: toString должен быть коротким и не должен тащить за собой весь граф объектов. Даже если сегодня у нас нет связей, завтра они появятся (и вы совершенно не хотите получить бесконечную рекурсию “Product → Category → Products → Category → …”). Да, мы ещё не изучали связи — и правильно. Но toString лучше сделать аккуратным сразу.

Хороший toString для Product обычно включает несколько диагностически полезных полей: id (если есть), sku, name. Без описаний на полстраницы.

@Override
public String toString() {
    // ВНИМАНИЕ: не выводим связи (category, items и т.п.), чтобы не словить рекурсию и ленивые загрузки
    return "Product{id=%s, sku='%s', name='%s'}"
            .formatted(id, sku, name);
}

Если захотите проверить, как это выглядит:

Product p = new Product();
p.setSku("PHONE-1");
p.setName("Phone");

// Удобная диагностика: id=null сразу показывает, что объект ещё не сохранён
System.out.println(p); // Product{id=null, sku='PHONE-1', name='Phone'}

Заметьте, как красиво id=null говорит нам “объект ещё не сохранён” (то есть в терминах лекции 1 — он transient). Это отличный пример того, как toString помогает диагностике, не вмешиваясь в бизнес‑логику.

Плохой toString обычно “честный”: туда включают все поля, включая длинные тексты, служебные флаги и всё подряд. На старте кажется удобно: “видно всё”. Через неделю логи превращаются в кашу, а дебаг становится болью.

6. Правила для shop-data-jpa: Category и Product

Теперь, чтобы это не осталось теорией, зафиксируем стиль в коде наших сущностей. Мы не переписываем весь класс целиком одним полотном, а добавляем “правильные куски” точечно. Заодно дисциплинируем модель: sku и code — это не “любые строки”, это именно наши business keys, и они должны быть уникальными и обязательными (на уровне @Column мы это уже начали делать).

Product: равенство по sku, короткий toString

Фрагменты, которые должны появиться в Product:

import java.util.Objects;

@Override
public boolean equals(Object o) {
    if (this == o) return true; // один и тот же объект
    if (!(o instanceof Product other)) return false; // поддержка прокси/наследников
    return sku != null && sku.equals(other.sku); // business key; null не считаем равным null
}

import java.util.Objects;

@Override
public int hashCode() {
    // ВАЖНО: sku должен быть стабильным, иначе HashSet/HashMap будут "ломаться" при изменении sku
    return Objects.hashCode(sku);
}

@Override
public String toString() {
    // Короткий toString: помогает в логах и дебаге и не тянет граф объектов
    return "Product{id=%s, sku='%s', name='%s'}"
            .formatted(id, sku, name);
}

Если вы ведёте себя как взрослый инженер (а мы к этому стремимся), вы ещё и минимально дисциплинируете доступ к business key. Например, вы можете убрать публичный setSku, или хотя бы договориться “SKU не меняем после создания”. В учебном проекте достаточно договорённости, но помнить об этом нужно.

Category: равенство по code, короткий toString

Для Category — та же идея, только ключ другой:

import java.util.Objects;

@Override
public boolean equals(Object o) {
    if (this == o) return true; // быстрый путь
    if (!(o instanceof Category other)) return false; // сравнение с учётом ORM-прокси
    return code != null && code.equals(other.code); // business key; null не считаем равным null
}

import java.util.Objects;

@Override
public int hashCode() {
    // ВАЖНО: code должен быть стабильным, иначе коллекции на хэшах начнут вести себя непредсказуемо
    return Objects.hashCode(code);
}

@Override
public String toString() {
    // Коротко и без связей: логируем только то, что реально помогает диагностике
    return "Category{id=%s, code='%s', name='%s'}"
            .formatted(id, code, name);
}

Про @Data и автогенерацию

Если вы где-то видели совет “просто поставь Lombok @Data и всё будет классно”, то для entity это прям очень спорная рекомендация. @Data генерирует equals/hashCode/toString по всем полям. Это почти гарантированно приводит к тому, что hashCode зависит от изменяемых полей, а toString начинает печатать всё подряд. Так что в нашем курсе мы лучше потратим 10 минут на ручной, осознанный код — и сэкономим часы на отладке.

7. Типичные ошибки при equals/hashCode/toString

Ошибка №1: “Сгенерирую equals/hashCode по id, ведь id — это же ключ в БД”.
Логика понятная, но в JPA id у нового объекта сначала null, а потом становится реальным числом. Если hashCode зависит от id, то после сохранения объект может “пропасть” из HashSet или перестать быть ключом в HashMap. Баг выглядит как мистика, но это всего лишь нарушенный контракт hash‑коллекций.

Ошибка №2: “Тогда возьму name/price — они же есть сразу”.
Это ещё опаснее, потому что имя и цена по бизнесу меняются регулярно, и вы сами же будете ломать hashCode обычными обновлениями. В результате коллекции начинают вести себя непредсказуемо, а вы тратите время на расследование “как это set.contains вернул false для того же объекта”.

Ошибка №3: забыть про null в business key и сделать два “пустых” объекта равными.
Если написать return Objects.equals(sku, other.sku);, то два новых товара без sku (оба null) окажутся равными. Это выглядит как мелочь, но ломает ожидания: вы можете случайно считать, что “добавили два разных объекта”, а Set оставит один.

Ошибка №4: сделать toString огромным и включить туда всё.
Это превращает логи в бесконечную простыню и затрудняет отладку. toString должен помогать быстро понять “что это за объект”, а не рассказывать биографию товара с детского сада. Достаточно id, business key и пары коротких полей.

Ошибка №5: использовать getClass() в equals и потом удивляться, почему сравнение иногда не работает.
В ORM мире у объекта иногда бывает “техническая оболочка” (прокси), и строгое сравнение классов начинает мешать. Для нашего baseline безопаснее instanceof + business key. Это не “идеальная теория для всех случаев”, но это практично и стабильно для учебного и обычного коммерческого кода.