Рефлексія в Kotlin — що це і як отримати KClass

1. Що таке рефлексія і коли вона потрібна

Уявіть, що ви пишете програму, у якій наперед неможливо перелічити всі типи й сценарії: плагіни, серіалізація, DI-контейнер, автоматична генерація логів, імпорт/експорт, універсальна діагностика. У таких випадках хочеться вміти запитати програму: «А ти хто взагалі?» — і отримати відповідь.

Рефлексія якраз про це: код, який уміє дивитися на інший код (і на типи) під час виконання. Звучить як сюжет наукової фантастики, але на практиці це інструмент, який або дуже допомагає, або дуже швидко перетворює проєкт на «динамічну кашу», якщо користуватися ним без дисципліни.

Статика і рантайм: два режими мислення

У звичайному Kotlin ви дієте за простим принципом: компілятор усе перевірив — отже, можна сміливо викликати методи. Якщо у вас є Expense, ви пишете expense.amount, і компілятор гарантує, що amount існує та має потрібний тип.

Із рефлексією ви робите крок убік: частину рішень ухвалюють після запуску. Відповідно, гарантій компілятора менше, а перевірок — більше. Тому зручне правило таке: якщо задачу можна розвʼязати статично (звичайним кодом), розвʼязуйте її статично. Рефлексія потрібна там, де статичний підхід стає незручним або неможливим — і ви готові «платити» за це ускладненням та додатковими перевірками.

Ось невеличка схема, щоб мозок перемкнувся:

flowchart LR
    A[Звичайний Kotlin-код] --> B[Компілятор перевірив типи]
    B --> C[Запуск: просто виконуємо]

    D[Рефлексія] --> E[Запуск: дізнаємося тип/члени]
    E --> F[Перевіряємо, що знайшли те, що потрібно]
    F --> G[Тільки потім виконуємо]

2. KClass — точка входу в рефлексію

Коли ви кажете «тип» у Kotlin, то зазвичай думаєте про слова на кшталт String, Int, Expense. Але під час виконання програмі потрібен обʼєкт, який представляє цей тип. У Java це Class<?>. У Kotlin — KClass.

KClass — це обʼєкт-опис класу (і трохи ширше — типу), з яким можна працювати як із даними: порівнювати, читати імʼя, використовувати для діагностики й (у наступних лекціях) шукати властивості/методи та навіть викликати їх.

Важливо: KClass — це стартова точка. Наше сьогоднішнє завдання — навчитися отримувати KClass і виконувати з ним найбезпечніші операції — ті самі «без фанатизму».

Як отримати KClass

Є два найкорисніші способи отримати KClass, і обидва виглядають майже однаково — ніби Kotlin спеціально хотів, щоб ви не розслаблялися.

Коли тип відомий заздалегідь: SomeType::class

Тут ви кажете: «Я знаю тип на етапі компіляції. Просто дай мені його KClass».

import kotlin.reflect.KClass

data class Expense(val id: Int, val amount: Int, val category: String)

fun main() {
    val cls: KClass<Expense> = Expense::class
    println(cls) // class Expense
}

Тут Expense::class має тип KClass<Expense>. Це зручно, коли ви будуєте таблиці/мапи «за типами», реєструєте обробники або просто хочете зробити охайну діагностику.

Коли є обʼєкт: obj::class

Цей спосіб особливо корисний, коли обʼєкт приходить параметром типу Any або базового інтерфейсу, а ви хочете дізнатися його реальний тип у рантаймі.

data class Expense(val id: Int, val amount: Int, val category: String)

fun main() {
    val x: Any = Expense(1, 500, "food")
    println(x::class.simpleName) // Expense
}

Тут x::class — це «паспорт» саме реального обʼєкта, а не того, що написано ліворуч від =.

Нюанс про simpleName

simpleName — річ зручна, але вона nullable: в анонімних обʼєктів і деяких локальних класів імені може не бути. Тому охайний стиль — завжди мати запасний варіант:

fun typeLabel(x: Any): String {
    return x::class.simpleName ?: "<без назви>"
}

fun main() {
    val obj = object { val x = 1 }
    println(typeLabel(obj)) // <без назви>
}

Що можна зробити з KClass без «важкої» рефлексії

Поки ми не ліземо в memberFunctions/memberProperties (це буде в наступній лекції). Але навіть у мінімальному варіанті KClass може бути корисним.

Діагностика: друкуємо імʼя типу в логах

Якщо ви робите консольний застосунок, то «розумні» повідомлення про помилки й діагностику — половина успіху. KClass допомагає писати повідомлення на кшталт «отримали не те».

fun describe(x: Any): String {
    val name = x::class.simpleName ?: "<невідомо>"
    return "Отримали обʼєкт типу: $name"
}

fun main() {
    println(describe("hi")) // Отримали обʼєкт типу: String
    println(describe(123))  // Отримали обʼєкт типу: Int
}

Порівняння типів через KClass

Іноді хочеться сказати: «якщо це точно рядок — роби одне, інакше інше». Тоді можна порівняти KClass:

fun isExactlyString(x: Any): Boolean {
    return x::class == String::class
}

fun main() {
    println(isExactlyString("ok")) // true
    println(isExactlyString(10))   // false
}

Таблиця типів: Map<KClass<*>, ...>

Іноді зручно зробити невеличкий довідник за типами. Зверніть увагу на KClass<*>: це «клас невідомого типу», безпечна форма, коли параметр типу для нас неважливий.

import kotlin.reflect.KClass

fun main() {
    val labels: Map<KClass<*>, String> = mapOf(
        String::class to "рядок",
        Int::class to "ціле число",
        Double::class to "дійсне число"
    )

    val x: Any = 42
    println(labels[x::class] ?: "щось загадкове") // ціле число
}

Такий прийом часто трапляється в логіці диспетчеризації та в діагностиці.

is і ::class == ... — це не одне й те саме

Дуже поширена пастка — думати, що перевірка x is Animal дорівнює x::class == Animal::class. Це не так. І різниця принципова: is враховує наслідування, а порівняння KClass перевіряє точний клас обʼєкта.

Погляньмо:

open class Animal
class Cat : Animal()

fun main() {
    val a: Animal = Cat()

    println(a is Animal)                 // true
    println(a::class == Animal::class)   // false
    println(a::class == Cat::class)      // true
}

У «людських» термінах: is — це «чи є це твариною взагалі?», а ::class == ... — це «це тварина саме класу Animal (без нащадків)?».

Щоб закріпити, ось невеличка таблиця:

x is T

x::class == T::class

3. KClass у консольному проєкті: розумна діагностика

Зараз ми акуратно застосуємо KClass у стилі «не зламай архітектуру». Ми не будуватимемо бізнес-логіку на рефлексії. Натомість додамо те, що майже завжди корисно: діагностичний опис того, що відбувається.

Уявімо (як у вашому практичному проєкті), що в нас є команди й парсер команд. Команди зручно моделювати через sealed interface, щоб компілятор допомагав вам тримати їхній повний список.

sealed interface Command
data class AddExpense(val amount: Int, val category: String) : Command
data object ListExpenses : Command
data class Help(val topic: String?) : Command

Імʼя команди для логів

Тепер зробимо функцію, яка повертає «імʼя команди» для логів або відлагоджувального виводу:

fun commandName(cmd: Command): String {
    return cmd::class.simpleName ?: "<анонімна команда>"
}

fun main() {
    val cmd: Command = AddExpense(500, "food")
    println(commandName(cmd)) // AddExpense
}

Це дрібниця, але вона дивовижно приємна: коли у вас складний ланцюжок «введення → парсинг → виконання → результат», така діагностика допомагає не потонути у власному коді.

Логуємо несподіваний тип результату

Якщо ви повертаєте результати виконання команд через sealed interface, можна логувати, який саме результат прийшов, не друкуючи весь обʼєкт.

sealed interface CommandResult {
    data class Ok(val message: String) : CommandResult
    data class Error(val message: String) : CommandResult
}

fun resultKind(r: CommandResult): String =
    r::class.simpleName ?: "<невідомий результат>"

fun main() {
    val r: CommandResult = CommandResult.Error("Некоректне введення")
    println(resultKind(r)) // Error
}

Знову ж таки: це не «магія», а охайне поліпшення читабельності та відлагодження.

4. Коли потрібен kotlin-reflect

У Kotlin є важливий практичний нюанс: повноцінна рефлексія — це окрема бібліотека kotlin-reflect, і вона не завжди підʼєднується автоматично. Для невеликих програм це плюс: менше залежностей, швидший запуск, менший розмір.

На JVM навіть компілятор має окрему опцію «не додавати reflect у classpath». У документації опцій компілятора є прапорець -no-reflect, який якраз забороняє автоматичне підключення kotlin-reflect.jar.

Чому це важливо вам сьогодні: ::class і базові операції (як-от порівняння та отримання імені) ви можете використовувати майже завжди. Але щойно ви захочете «список членів класу» (members) або доступ до властивостей/методів, зазвичай знадобиться kotlin-reflect.

Приклад доступу до members трапляється навіть у стандартній документації про reified, де використовують T::class.members.

Ми свідомо не заглиблюємося в це зараз. Наша мета — вивчити точку входу (KClass) і не перетворити проєкт на детектив «чому воно не компілюється без ще однієї залежності».

5. KClass і Java Class: як конвертувати типи

Kotlin на JVM живе поруч із Java, тож вам часто потрібно «перекласти» Kotlin-тип у Java-тип і назад. Для цього є дуже зрозумілі мости.

Якщо у вас є KClass, то Java-клас зазвичай можна отримати через .java:

fun main() {
    val javaCls = String::class.java
    println(javaCls.name) // java.lang.String
}

А якщо у вас є обʼєкт, то Java-клас можна отримати через javaClass:

fun main() {
    val x = "hi"
    println(x.javaClass.name) // java.lang.String
}

Це особливо корисно, коли ви використовуєте Java API, які вимагають Class<T> (наприклад, деякі фабрики, реєстри, старі DI-інструменти тощо). Але мислити все одно зручніше, починаючи з Kotlin-сторони: ::class і KClass.

6. Типові помилки під час знайомства з KClass

Помилка №1: плутати is і ::class == ...::class.
Це найпоширеніша логічна пастка. Перевірка is відповідає на питання «чи можна вважати обʼєкт типом T» і враховує наслідування. Порівняння KClass перевіряє точний клас. Якщо переплутати, ви отримаєте дивні розгалуження: код «не впізнає» нащадків і поводиться так, ніби поліморфізм скасували.

Помилка №2: використовувати simpleName!! і отримувати NPE на рівному місці.
В анонімних обʼєктів, локальних класів і деяких спеціальних випадків імʼя може бути недоступним, тому simpleName — nullable. У діагностиці й логах краще мати запасний варіант на кшталт ?: "<без назви>", ніж одного разу впіймати падіння в самій системі логування.

Помилка №3: вважати, що рефлексія завжди доступна, і дивуватися, що members не працює.
Базові речі з KClass ви отримуєте майже завжди, а от розширена рефлексія зазвичай вимагає kotlin-reflect. Якщо проєкт зібраний без неї (або з прапорцем, який забороняє підтягувати її автоматично), то деякі можливості виявляться недоступними. Прапорець -no-reflect у JVM-опціях компілятора — саме про це.

Помилка №4: будувати бізнес-логіку на рядкових іменах типів «заради гнучкості».
На старті здається, що «якщо я ухвалюватиму рішення за simpleName, то це буде гнучко». На практиці це перетворюється на крихкий код: перейменували клас — і логіка змінилася. Якщо ви використовуєте KClass, краще порівнювати саме KClass, а рядки залишати для людиночитних повідомлень.

Помилка №5: робити рефлексію в «гарячій» ділянці коду.
Навіть якщо сьогодні ви використовуєте тільки ::class і simpleName, тримайте в голові просте правило: рефлексія — не безкоштовна. Якщо ви почнете робити її всередині великих циклів і обробки колекцій «для кожного запису», то можете несподівано впертися в продуктивність. Зараз це просто попередження на майбутнє, а не привід панікувати.