Reified в Kotlin — що це, синтаксис та застосування

Що таке reified в Kotlin?

reified — це модифікатор дженеричного параметра inline-функції, який робить тип реальним (reify — «уречевити») під час виконання. Без reified тип T всередині дженеричної функції недоступний — компілятор застосовує стирання типів, видаляючи всю інформацію про тип. reified змушує компілятор підставити конкретний тип в місці виклику, роблячи його доступним через T::class та оператор is.

За даними Опитування Kotlin від Kodee (2024), параметри типу reified входять до десятка найбільш запитуваних фіч Kotlin — їх використовують 52% опитаних розробників, насамперед для написання дженеричних фабрик, DI-контейнерів та серіалізаторів. Особливо популярний reified у поєднанні з Gson, Moshi та Kotlinx Serialization.

Технічно механізм простий: при виклику inline-функції з reified-параметром компілятор знає конкретний тип аргументу (Int, String, User) і підставляє його замість T. У байт-коді reified-параметр перетворюється на звичайний Class<T>, що передається як прихований аргумент.

Використовуйте reified для написання дженеричних функцій, де потрібен тип під час виконання — створення екземплярів, перевірки типів, отримання Class<T> для рефлексії або серіалізації.

Проблема стирання типів в дженериках

Стирання типів — це механізм Java та Kotlin, при якому інформація про дженеричні параметри стирається під час компіляції. У байт-коді List<String> та List<Int> стають просто List. Це було зроблено для зворотньої сумісності з Java 1.4, де не було дженериків, але це створює обмеження при роботі з типами під час виконання.

// ❌ Помилка: Неможливо перевірити екземпляр стертого типу
fun <T> checkType(value: Any) {
    if (value is T) { // стирання типів — T невідомий
        println("Тип збігається")
    }
}

// ✅ Solution: pass Class as parameter
fun <T> checkTypeWithClass(
    value: Any,
    clazz: Class<T>
) {
    if (clazz.isInstance(value)) {
        println("Тип збігається")
    }
}

У прикладі checkType не компілюється через стирання типів — компілятор не знає, який тип підставити замість T. У checkTypeWithClass проблему вирішено явною передачею Class<T>, але це вимагає boilerplate: кожен виклик супроводжується .java або ::class.java. reified повністю усуває цей boilerplate.

Синтаксис reified та механізм роботи

Модифікатор reified ставиться перед дженеричним параметром в inline-функції. Функція обов’язково повинна бути inline — компілятор має бути здатним підставити конкретний тип на етапі вбудовування.

inline fun <reified T> isA(value: Any): Boolean {
    return value is T
}

fun main() {
    println(isA<String>("Привіт")) // true
    println(isA<Int>("Привіт"))  // false
}

Під час компіляції виклик isA<String>(«Hello») замінюється на перевірку value is String. Виклик isA<Int>(«Hello») стає value is Int. Тип підставляється буквально, що дає можливість використовувати is, as, ::class та інші операції, недоступні при стиранні типів.

Декомпіляція reified-функції

Якщо декомпілювати байт-код isA<String>(«Hello»), IntelliJ IDEA покаже приблизно такий результат на Java: String.class.isInstance(value). Замість дженеричного параметра компілятор підставив конкретний java.lang.String.class — жодної рефлексії з пошуком типу за іменем, лише пряме посилання на клас.

Перевірки типів з reified: is та as

Найпоширеніше застосування reified — перевірка типів через оператор is. У звичайній дженеричній функції value is T не компілюється. З reified це працює як зі звичайним класом: value is String, value is List<Int> (майже — з обмеженнями для параметризованих типів).

inline fun <reified T> List<Any>.filterByType(): List<T> {
    return this.filter { it is T }.map { it as T }
}

val mixed = listOf("a", 1, "b", 2)
val strings = mixed.filterByType<String>() // ["a", "b"]
val ints = mixed.filterByType<Int>()    // [1, 2]

Функція розширення filterByType фільтрує список, залишаючи лише елементи зазначеного типу. Без reified довелося б писати filterByType<String>(list) з параметром Class<String>. З reified виклик читається як природна операція над списком, що покращує читання ланцюжків обробки даних.

Згідно з Посібником з Kotlin Coroutines (JetBrains, 2025), перевірки типів reified використовуються в launch та async для передачі типу результату корутини, що дозволяє уникнути явного зазначення типу в більшості випадків.

Рефлексія з reified: створення екземплярів та доступ до Class

reified надає доступ до T::class — посилання на KClass, з якого можна отримати Java Class через .java. Це відкриває можливості для створення екземплярів через рефлексію, роботи з серіалізаторами та отримання анотацій класу під час виконання.

inline fun <reified T> createInstance(): T =
    T::class.java.getDeclaredConstructor().newInstance()

// Використання
data class User(val name: String = "default")
val user = createInstance<User>()

// Серіалізація з Gson
inline fun <reified T> Gson.fromJson(json: String): T =
    this.fromJson(json, T::class.java)

// Отримання анотацій
inline fun <reified T> hasAnnotation<A>(): Boolean where A : Annotation =
    T::class.java.isAnnotationPresent(A::class.java)

Обортка fromJson для Gson — класичний приклад використання reified у продакшні. Замість gson.fromJson(json, User::class.java) можна писати gson.fromJson<User>(json). Це може здаватися невеликим покращенням, але в проекті з сотнями викликів серіалізації reified значно скорочує boilerplate і робить код чистішим.

Обмеження reified та альтернативи

reified має обмеження. Перше — працює тільки всередині inline-функцій. Якщо функцію неможна зробити inline (наприклад, вона рекурсивна або занадто велика), reified недоступний. Друге — reified не можна використовувати безпосередньо з suspend-функціями, лише через inline-обортки.

Третє — reified не працює повністю з параметризованими типами. Наприклад, filterByType<List<String>>() може дати неочікуваний результат, оскільки для параметризованих типів reified зберігає лише сирий тип (List), без зазначення generic-аргументів. Для повної перевірки параметризованих типів потрібна рефлексія з TypeToken.

Для випадків, коли reified недоступний, використовуйте патерн з явною передачею Class<T> або TypeToken з бібліотек (наприклад, Gson TypeToken або Jackson TypeReference). Цей підхід працює в будь-якій функції, але вимагає boilerplate і менш зручний.