В каких случаях не стоит использовать data class

Когда использование Data Class не является оптимальным выбором

Классы данных (data class) в Kotlin — это мощный инструмент для создания моделей, предназначенных преимущественно для хранения состояния. Они автоматически генерируют методы equals(), hashCode(), toString(), copy() и функции компонентов. Однако их использование не всегда целесообразно. Рассмотрим ключевые случаи, когда data class может быть не лучшим решением.

1. Классы с сложной логикой или поведением

Основная цель data class — представлять данные (state), а не поведение (behavior). Если ваш класс содержит множество методов, сложную бизнес-логику или должен реализовывать определенные интерфейсы с нетривиальной реализацией, обычный class будет более подходящим.

// Неудачный вариант: data class с чрезмерной логикой
data class PaymentProcessor(
    val amount: Double,
    val currency: String
) {
    fun processPayment() {
        // Сложная логика взаимодействия с API, валидации, etc.
        if (amount <= 0) throw IllegalArgumentException()
        // ... 50 строк кода
    }

    fun refundPayment() { /* другая сложная логика */ }
    fun generateReport(): String { /* формирование отчетов */ }
}

// Более правильный подход: разделение на data class и service class
data class PaymentData(val amount: Double, val currency: String) // Только данные

class PaymentProcessor { // Класс, отвечающий за поведение
    fun processPayment(data: PaymentData) { /* логика */ }
    fun refundPayment(data: PaymentData) { /* логика */ }
}

2. Классы, требующие особой реализации equals()/hashCode()

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

// Проблема: все поля участвуют в equals/hashCode, что может быть неверно
data class User(
    val id: Long,         // Уникальный, постоянный идентификатор
    val name: String,     // Может меняться
    val email: String     // Может меняться
)

// Два объекта с одинаковым ID, но разными email будут считаться разными.
// В некоторых системах это некорректно (пользователь один, данные обновились).

В таких случаях лучше использовать обычный class и самостоятельно переопределить equals() и hashCode(), основываясь только на поле id.

3. Сущности с изменяемым состоянием, где copy() может быть опасен

Метод copy() создает новый объект, что подразумевает immutable (неизменяемый) подход. Если ваш класс предназначен для mutable (изменяемого) состояния и предполагает частые модификации существующего объекта, data class может ввести в заблуждение. Кроме того, неаккуратное использование copy() может привести к созданию множества почти идентичных объектов и повысить расход памяти.

data class MutableConfig(var timeout: Int, var retries: Int) // Проблематично

fun updateConfig(config: MutableConfig) {
    // Хочется изменить исходный объект, но легко случайно сделать copy()
    val newConfig = config.copy(timeout = 5000) // Создан новый объект!
    // Старый config остался неизменным, что может быть ошибкой.
}

Для изменяемых моделей лучше использовать обычный class с полями var.

4. Классы-наследники (наследование)

data class не может быть open или abstract. Следовательно, их нельзя расширять другими data class. Если вам нужна иерархия классов для представления данных, придется использовать обычные классы и самостоятельно обеспечивать стандартные методы.

// Невозможно сделать иерархию data class
open abstract class BaseEntity(val id: Long) // Можно наследовать

data class DerivedEntity(val id: Long, val name: String) // Не может наследовать BaseEntity

5. Классы с минимальным количеством полей или без полей

Создание data class без полей или с одним полем часто бессмысленно, так как основная выгода — автоматическая генерация для нескольких свойств. Для классов-синглтонов, фабрик или классов без состояния используйте обычный class или object.

data class SingletonService(val instanceName: String) // Странно, это не data объект

// Более корректно:
object SingletonService { /* ... */ }

6. Структуры, где toString() должен быть особенным

Автоматически генерированный toString() выводит все поля. В случаях, когда требуется форматированный вывод, скрытие некоторых полей (например, паролей) или другой формат, data class придется переопределять, что снижает пользу от его использования.

7. Энтити в Domain-Driven Design (DDD) или сложные бизнес-модели

В DDD Entity часто имеет уникальный идентификатор и сложную инкапсулированную бизнес-логику внутри. Использование data class может нарушить инкапсуляцию, так как он автоматически предоставляет доступ ко всем полям через функции компонентов (component1(), component2()), и его логика "равенства" может не совпадать с доменной.

Заключение

data class — отличный выбор для:

• Value objects (объекты-значения)
• DTO (Data Transfer Objects)
• POJO (Plain Old Java Objects)
• Моделей ответа API
• Параметров запроса
• Неизменяемых конфигурационных объектов

Но когда требуется наследование, изменяемое состояние, специфическая логика равенства, сложное поведение или инкапсуляция доменной модели, предпочтительнее использовать обычный class, обеспечивая необходимую функциональность вручную. Выбор инструмента должен соответствовать архитектурной роли класса в системе.