Data class в Kotlin: почему их нельзя наследовать и как обойти

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Data class в Kotlin: почему их нельзя наследовать и как это обойти (разбор под капотом)

Вы когда-нибудь писали data class User(val name: String), а потом хотели сделать data class Admin extends User? И получали красную ошибку от компилятора? Если да — вы не одиноки. Вопрос «Extend data class in Kotlin» входит в топ самых популярных на Stack Overflow (более 50 000 просмотров).

Сегодня мы не просто дадим готовый ответ. Мы заглянем под капот Kotlin, разберём, почему создатели языка пошли на такое «жестокое» ограничение, и покажем 3 легальных способа обойти его, не ломая архитектуру.

Статья написана для образовательного портала PythonLib — здесь мы любим копать вглубь, а не просто копировать сниппеты.

Почему data class нельзя наследовать? Заглядываем в байт-код

Давайте сразу к делу. Напишем простой data class и посмотрим, что генерирует компилятор:

data class User(val name: String, val age: Int)

Под капотом Kotlin создаёт:

equals() — сравнивает все поля
hashCode() — хеш на основе всех полей
toString() — красивое строковое представление
copy() — функция копирования с изменением полей
componentN() — деструктуризация

А теперь представьте, что вы наследуете data class:

open data class Base(val x: Int)
data class Derived(val x: Int, val y: Int) : Base(x) // Ошибка компиляции!

Котлин выдаёт: «Inheritance of data classes is not allowed». Почему? Давайте разберёмся.

Проблема №1: copy() ломается. Функция copy() генерируется только для полей текущего класса. Если у вас есть Derived, унаследованный от Base, то copy() в Base не знает про поле y. Вызвав base.copy(), вы потеряете данные наследника.

Проблема №2: equals() и hashCode(). Представьте: Base(1) и Derived(1, 2). Должны ли они быть равны? Если да — нарушается симметрия (ведь Derived содержит больше полей). Если нет — нарушается контракт equals/hashCode. Котлин выбрал безопасный путь — запретить наследование.

Проблема №3: componentN(). val (x) = base и val (x, y) = derived — разные количества компонентов. При наследовании возникла бы путаница.

Итог: data class создан для неизменяемых контейнеров данных, а не для иерархий. Это сознательное решение дизайна языка.

Способ №1: Композиция вместо наследования (рекомендуемый)

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

data class Address(val city: String, val street: String)

data class User(
    val name: String,
    val age: Int,
    val address: Address // композиция
)

fun main() {
    val address = Address("Москва", "Тверская")
    val user = User("Анна", 25, address)
    println(user) // User(name=Анна, age=25, address=Address(city=Москва, street=Тверская))
    
    // Копирование работает идеально
    val user2 = user.copy(age = 26)
    println(user2) // User(name=Анна, age=26, address=Address(city=Москва, street=Тверская))
}

Плюсы: всё работает «из коробки», нет сюрпризов с equals/hashCode, код прозрачен.

Минусы: если вам нужно много уровней вложенности, получается «матрёшка». Но это решается нормализацией данных.

Способ №2: Sealed class + data class (для строгих иерархий)

Если вам действительно нужна иерархия (например, разные типы пользователей), используйте sealed class (или sealed interface) в качестве базового типа.

sealed class User {
    abstract val name: String
}

data class RegularUser(override val name: String, val age: Int) : User()

data class AdminUser(override val name: String, val role: String) : User()

fun processUser(user: User) {
    when (user) {
        is RegularUser -> println("Обычный пользователь: ${user.name}, возраст ${user.age}")
        is AdminUser -> println("Админ: ${user.name}, роль ${user.role}")
    }
}

fun main() {
    val users: List<User> = listOf(
        RegularUser("Иван", 30),
        AdminUser("Мария", "superadmin")
    )
    users.forEach { processUser(it) }
}

Плюсы: полный контроль над иерархией, безопасный when (компилятор проверяет все ветки), каждый подтип — полноценный data class.

Минусы: sealed class нельзя наследовать за пределами файла (но это скорее плюс — архитектура становится жёстче).

Способ №3: Отказ от data class — обычный class + вручную equals/hashCode

Если вам позарез нужно наследование и все плюшки data class, перепишите код на обычный класс. Да, придётся написать boilerplate, но Kotlin поможет.

open class Base(val x: Int) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is Base) return false
        return x == other.x
    }

    override fun hashCode(): Int = x

    override fun toString(): String = "Base(x=$x)"

    open fun copy(x: Int = this.x): Base = Base(x)
}

class Derived(x: Int, val y: Int) : Base(x) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is Derived) return false
        if (!super.equals(other)) return false
        return y == other.y
    }

    override fun hashCode(): Int = 31 * super.hashCode() + y

    override fun toString(): String = "Derived(x=$x, y=$y)"

    override fun copy(x: Int = this.x, y: Int = this.y): Derived = Derived(x, y)
}

fun main() {
    val a = Base(1)
    val b = Derived(1, 2)
    println(a) // Base(x=1)
    println(b) // Derived(x=1, y=2)
    println(a == b) // false — разумно!
}

Плюсы: полный контроль, наследование работает.

Минусы: много кода, легко ошибиться в equals/hashCode. Используйте только если композиция и sealed class не подходят.