Можно ли добавлять дополнительные методы в Record

В Record разрешено добавлять: 4. Wither-методы (методы создания копии с измененным полем).

🟢 Junior Level

Да, можно. Record в Java — это полноценный тип данных, и вы можете объявлять в нем любые вспомогательные методы.

В Record разрешено добавлять:

Методы экземпляра (Instance methods) для вычисления производных значений на основе полей.
Статические методы (Static methods), например, фабричные методы of(...) или empty().
Приватные методы для декомпозиции внутренней логики.
Wither-методы (методы создания копии с измененным полем).

public record User(String firstName, String lastName, int age) {
    // 1. Метод экземпляра (производное свойство)
    public String fullName() {
        return firstName + " " + lastName;
    }

    // 2. Бизнес-проверка
    public boolean isAdult() {
        return age >= 18;
    }

    // 3. Статический фабричный метод
    public static User anonymous() {
        return new User("John", "Doe", 0);
    }
}

// Использование:
User user = new User("Alice", "Smith", 25);
System.out.println(user.fullName()); // "Alice Smith"
System.out.println(user.isAdult());  // true

Главное ограничение

В Record можно добавлять поведение (методы), но категорически запрещено добавлять состояние (новые нестатические поля). Все состояние записи обязано быть объявлено в ее заголовке.

🟡 Middle Level

1. Паттерн «Wither» (Иммутабельное обновление состояния)

Поскольку поля записи неизменяемы (final), в Record нельзя написать сеттер setAge(int age). Вместо этого используется паттерн Wither: метод возвращает новый экземпляр записи с обновленным значением:

public record Order(UUID id, BigDecimal total, OrderStatus status) {
    // Wither-метод: возвращает копию заказа с новым статусом
    public Order withStatus(OrderStatus newStatus) {
        return new Order(this.id, this.total, newStatus);
    }

    // Wither-метод: возвращает копию с пересчитанной суммой
    public Order withTotal(BigDecimal newTotal) {
        return new Order(this.id, newTotal, this.status);
    }
}

// Пример использования цепочки:
Order pending = new Order(UUID.randomUUID(), BigDecimal.valueOf(100), OrderStatus.PENDING);
Order paid = pending.withStatus(OrderStatus.PAID);

2. Переопределение канонических методов

Вы можете явно переопределить стандартные методы:

toString(): для маскирования чувствительных данных (номеров карт, паролей).
equals() и hashCode(): для нестандартного сравнения (например, без учета регистра строк или сравнения содержимого массивов через Arrays.equals).
Методы-аксессоры (например, public String name()): для защитной нормализации (например, return name.trim()).

public record CreditCard(String cardNumber, String holder, String cvv) {
    // Переопределяем toString, чтобы не скомпрометировать CVV и номер карты в логах:
    @Override
    public String toString() {
        return "CreditCard[holder=" + holder + ", cardNumber=****" + cardNumber.substring(cardNumber.length() - 4) + "]";
    }
}

🔴 Senior Level

Ограничения спецификации языка (JLS §8.10.2)

Спецификация языка Java накладывает на методы Record ряд строгих правил:

Запрет native методов:
```
public record NativeHolder(int value) {
    // public native void doLowLevelWork(); // ❌ Ошибка компиляции: native method not allowed in record
}
```
Почему? Записи спроектированы как математически прозрачные и платформенно-независимые структуры. Нативные методы скрывают реализацию за пределами JVM, что противоречит семантике Record.
Конфликты сигнатур с компонентами: Нельзя объявить метод, имя которого совпадает с компонентом, но возвращаемый тип отличается:
```
public record Point(int x, int y) {
    // public String x() { return "x=" + x; } // ❌ Ошибка: x() in Point cannot override x() in Point; attempting to use incompatible return type
}
```
Опасность рассинхронизации при переопределении аксессора: Если вы переопределяете метод чтения поля:
```
public record User(String name) {
    public String name() {
        return name.toUpperCase(); // Возвращает в верхнем регистре
    }
}
```
[!CAUTION] Автогенерированный метод equals() сравнивает поле this.name напрямую через байткод, а не через вызов метода name(). Если u1 = new User("alice") и u2 = new User("ALICE"), то u1.name().equals(u2.name()) вернет true, однако u1.equals(u2) вернет false! Всегда нормализуйте данные в компактном конструкторе, а не в аксессорах.

Архитектурный баланс: Data Carrier vs Anemic Model

Добавление бизнес-логики в Record — дискуссионная тема в Software Design:

Рекомендуется добавлять: логику вычисления производных атрибутов (Derived attributes: fullName(), area()), предикаты валидности (isExpired()), фабрики и Withers. Это делает Record богатым Value Object в терминологии DDD (Domain-Driven Design).
Категорически не рекомендуется: внедрять зависимости (Spring Services, Repositories), выполнять I/O-операции, вызовы внешних API или мутировать внешние структуры данных. Record должен оставаться чистой функцией от своих аргументов.

4 Tricky Questions

1. Можно ли объявить в Record нативный метод (`public native void doSomething()`)?

Ответ: Нет, нельзя.

Спецификация Java (JLS §8.10.2) прямо запрещает модификатор native для методов в объявлениях record: «It is a compile-time error if a record declaration contains a native method».

Записи спроектированы как сериализуемые, прозрачные и легко оптимизируемые контейнеры данных. Нативные методы связывают класс с машинно-зависимым кодом через JNI, что нарушает концепцию чистого носителя данных.

2. Как в Record правильно реализовать модификацию одного поля (паттерн «Wither»)?

Ответ: Поскольку поля записи являются неизменяемыми (final), классические сеттеры невозможны. Применяется паттерн Wither: объявляется метод с префиксом with..., который принимает новое значение для одного компонента и вызывает канонический конструктор, копируя все остальные поля:

public record Account(UUID id, BigDecimal balance, boolean active) {
    public Account withBalance(BigDecimal newBalance) {
        return new Account(this.id, newBalance, this.active);
    }
}

Этот подход сохраняет потокобезопасность и неизменяемость экземпляра. В рамках Project Amber в будущих версиях Java планируется синтаксис with-выражений (например, account with { balance = newBalance; }).

3. Что произойдет, если переопределить аксессор компонента так, чтобы он возвращал модифицированное значение (например, `return name.toLowerCase()`)?

Ответ: Код скомпилируется (начиная с Java 16 переопределение аксессоров с идентичной сигнатурой разрешено). Однако это создаст критическую скрытую ошибку согласованности:

Автосгенерированный компилятором метод equals() обращается к приватному полю this.name напрямую через байткод getfield, минуя вызов метода name(). Если вы создадите User("ALICE") и User("alice"), метод-аксессор .name() для обоих вернет "alice", создавая видимость идентичности, однако u1.equals(u2) вернет false!

Именно поэтому любая трансформация значений должна производиться в компактном конструкторе на этапе создания объекта, сохраняя в поле уже нормализованное значение.

4. Можно ли в Record перегрузить метод-аксессор (например, объявить `public String name(String prefix)`)?

Ответ: Да, можно.

В Java механизм перегрузки методов (Method Overloading) опирается на полную сигнатуру метода (имя + типы и количество параметров). Метод public String name(String prefix) имеет иной список параметров, чем канонический аксессор public String name(). Компилятор рассматривает его как обычный пользовательский метод экземпляра.

🎯 Шпаргалка для интервью

Главное о методах в Record

Что можно:
- Любые методы экземпляра (public, protected, package-private, private).
- Статические методы и константы (public static of(...)).
- Wither-методы (with...) для иммутабельной модификации.
- Переопределение equals(), hashCode(), toString() и аксессоров.
Чего нельзя:
- Объявлять нестатические (instance) поля.
- Объявлять native методы.
- Менять возвращаемый тип канонических аксессоров.
Правило чистоты: Record должен оставаться Value Object. Никаких сетевых вызовов, обращения к БД или мутаций внутри его методов.

Антипаттерны

❌ Модификация данных внутри геттера (return name.trim()): ломает контракт equals(). Нормализацию делайте в конструкторе!
❌ Попытка сымитировать сеттеры (public void setX(int x)): поля final, мутация невозможна.
❌ Внедрение Spring-бинов внутрь Record: Record — это данные, а не сервисный компонент.