Рефлексия и аннотации — бесплатный тест онлайн

Вопрос 1 из 30

Какой пограничный сценарий обязательно добавить к проверкам «Конкурентный кэш метаданных»?

Добавить тест на состояние, при котором kClass не удерживает ClassLoader, поэтому утечка кэша невозможна. Отдельно воспроизвести случай, в котором concurrentHashMap автоматически делает любой объект Meta immutable. Воспроизвести редкий сценарий, где computeIfAbsent гарантирует один вызов mapping function при всех реализациях и рекурсивных зависимостях. В плагинной системе сильные ссылки на классы в глобальном кэше могут удерживать старый ClassLoader после перезагрузки. Проверить соседний случай: После кэширования reflection можно вызывать без обработки ошибок доступа.

Вопрос 2 из 30

Какой дополнительный сценарий нужен для «Runtime-класс объекта»?

Добавить граничный тест на утверждение: Она создаст новый ClassLoader для объекта. Проверить крайний ввод, при котором она вернёт статический тип параметра `Any`. Считать опасной границей ситуацию, где она гарантированно вернёт `List<Int>` вместе с generic-аргументом. Зафиксировать сценарий, где ожидается: Код не компилируется без зависимости kotlin-reflect для `::class`. У локальных и анонимных классов `simpleName` может быть null, поэтому строка имени не является надёжным идентификатором.

Вопрос 3 из 30

Какой побочный эффект существеннее остальных после правки «Typed property reference»: Передавать typed property references для маппинга и сортировки вместо строк имён, когда набор свойств известен компилятору?

Ссылка на свойство безопаснее строки и рефакторится IDE, но динамический обход всё равно дороже прямого доступа. Новый риск связан с тем, что будет выведено `name`, потому что ссылка хранит только имя. Обратная сторона изменения состоит в том, что будет выведено `User`, поскольку receiver игнорируется. Решение оправдано лишь при условии: Код не компилируется: ссылку можно брать только на mutable-свойство. Сопровождение усложнится, если окажется, что возникнет IllegalAccessException для публичного свойства.

Вопрос 4 из 30

Куда попадёт `Mark` в этом объявлении?

// Проследите фактическое выполнение без изменения кода.
@Target(AnnotationTarget.FIELD, AnnotationTarget.PROPERTY_GETTER)
annotation class Mark

class Model(@get:Mark val id: String)

Она применяется к классу Model, потому что стоит в primary constructor. Она попадёт одновременно на поле, параметр конструктора и getter. Код не компилируется: use-site target нельзя указывать у val. Она существует только в Kotlin metadata и недоступна Java reflection независимо от retention. Аннотация применена к getter свойства благодаря use-site target `@get:`; поле отдельно не помечается.

Вопрос 5 из 30

Какой контракт определяет наблюдаемый результат «Динамический обход properties»?

// На ревью требуется объяснить причину поведения.
import kotlin.reflect.*
fun values(obj: Any): List<Any?> = obj::class.members
    .filterIsInstance<kotlin.reflect.KProperty1<Any, *>>()
    .map { it.get(obj) }

Причину поведения формулируют так: Рефлексия выполняется на этапе компиляции и не имеет runtime-стоимости. Наблюдаемое поведение выводят из того, что kClass.members гарантирует порядок primary constructor на всех платформах. Здесь действует следующее правило: FilterIsInstance доказывает, что каждый getter чистый и публичный. Ключевым считают контракт: Результат автоматически сериализуем и стабилен между версиями. Reflection переносит часть проверки на время выполнения, требует metadata/библиотеки и может конфликтовать с shrinker/Native-ограничениями.

Вопрос 6 из 30

Как сделать ответственность во фрагменте «Чтение runtime-аннотации» понятной следующему разработчику?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.PROPERTY_GETTER)
annotation class JsonName(val value: String)

class User(@get:JsonName("user_name") val name: String)

Спрятать участок за вспомогательной функцией, сохранив предположение: Создать User и сравнить его toString с названием аннотации. Оставить реализацию без изменений и закрепить тестом предположение: Считать успешную компиляцию доказательством RUNTIME retention. Ограничиться поясняющим комментарием о том, что проверить только наличие текста `@get:JsonName` в исходном файле. Перенести проверку в вызывающий код, исходя из того, что мокировать KClass.members, не читая скомпилированную модель. Добавить небольшой fixture-модуль со shrinker/обфускацией, если имена и runtime retention критичны в выпуске.

Вопрос 7 из 30

Какой побочный эффект существеннее остальных после правки «Runtime-класс объекта»: Использовать явные типовые токены или sealed-регистрацию вместо сравнения `simpleName`, которое нестабильно при обфускации?

Решение оправдано лишь при условии: Она вернёт статический тип параметра `Any`. После правки останется ограничение: Она создаст новый ClassLoader для объекта. KClass удобен для инфраструктуры и DI, но динамическое ветвление по классам слабее обычного полиморфизма. Новый риск связан с тем, что она гарантированно вернёт `List<Int>` вместе с generic-аргументом. Обратная сторона изменения состоит в том, что код не компилируется без зависимости kotlin-reflect для `::class`.

Вопрос 8 из 30

Что появится в выводе примера «Typed property reference»?

// Проследите фактическое выполнение без изменения кода.
data class User(val name: String, var age: Int)
fun main() {
    val p = User::name
    println(p.get(User("Ada", 36)))
}

Код не компилируется: ссылку можно брать только на mutable-свойство. Будет выведено `User`, поскольку receiver игнорируется. Будет выведено `name`, потому что ссылка хранит только имя. Возникнет IllegalAccessException для публичного свойства. Будет выведено `Ada`: ссылка на свойство `KProperty1<User, String>` читает его у переданного receiver.

Вопрос 9 из 30

Что точнее описывает механику фрагмента «Use-site target getter»?

// На ревью требуется объяснить причину поведения.
@Target(AnnotationTarget.FIELD, AnnotationTarget.PROPERTY_GETTER)
annotation class Mark

class Model(@get:Mark val id: String)

Механика примера описывается утверждением: Она существует только в Kotlin metadata и недоступна Java reflection независимо от retention. Use-site target выбирает конкретный JVM/Kotlin-элемент свойства: field, get, set, param, delegate и другие. Из правил языка или API следует, что код не компилируется: use-site target нельзя указывать у val. Ключевым считают контракт: Она попадёт одновременно на поле, параметр конструктора и getter. Такой результат объясняют тем, что она применяется к классу Model, потому что стоит в primary constructor.

Вопрос 10 из 30

Как укрепить «Динамический обход properties», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlin.reflect.*
fun values(obj: Any): List<Any?> = obj::class.members
    .filterIsInstance<kotlin.reflect.KProperty1<Any, *>>()
    .map { it.get(obj) }

Оставить реализацию без изменений и закрепить тестом предположение: KClass.members гарантирует порядок primary constructor на всех платформах. Кэшировать проверенные метаданные, ограничить допустимые классы и предпочитать generated adapters для горячего пути. Добавить защитную проверку перед фрагментом, поскольку рефлексия выполняется на этапе компиляции и не имеет runtime-стоимости. Оставить структуру прежней, документировав утверждение: Результат автоматически сериализуем и стабилен между версиями. Вынести участок в отдельный метод, считая верным следующее: FilterIsInstance доказывает, что каждый getter чистый и публичный.

Вопрос 11 из 30

Какой тест лучше всего защищает край контракта «Чтение runtime-аннотации»?

Unit-тест без release-настроек может пройти, а shrinker удалит метаданные или переименует элемент. Добавить регрессию на гипотезу: Создать User и сравнить его toString с названием аннотации. Отдельно проверить предположение, что проверить только наличие текста `@get:JsonName` в исходном файле. Зафиксировать сценарий, где ожидается: Считать успешную компиляцию доказательством RUNTIME retention. Проверить крайний ввод, при котором мокировать KClass.members, не читая скомпилированную модель.

Вопрос 12 из 30

Что станет новой точкой внимания после изменения «Конкурентный кэш метаданных»: Строить immutable Meta локально, ограничить ключи жизненным циклом приложения и обработать циклические модели без рекурсивного deadlock?

После внедрения придётся исходить из того, что concurrentHashMap автоматически делает любой объект Meta immutable. Новый риск связан с тем, что после кэширования reflection можно вызывать без обработки ошибок доступа. Цена упрощения проявится, если computeIfAbsent гарантирует один вызов mapping function при всех реализациях и рекурсивных зависимостях. Практическое ограничение подхода: KClass не удерживает ClassLoader, поэтому утечка кэша невозможна. Кэш ускоряет горячий путь, но усложняет инвалидацию и может превратить небольшую reflection-утилиту в глобальное состояние.

Вопрос 13 из 30

Что точнее описывает механику фрагмента «Typed property reference»?

// На ревью требуется объяснить причину поведения.
data class User(val name: String, var age: Int)
fun main() {
    val p = User::name
    println(p.get(User("Ada", 36)))
}

Такой результат объясняют тем, что будет выведено `User`, поскольку receiver игнорируется. Ключевым считают контракт: Код не компилируется: ссылку можно брать только на mutable-свойство. Здесь действует следующее правило: Будет выведено `name`, потому что ссылка хранит только имя. Ссылки `::property` типобезопасны; полная рефлексия даёт обход членов, доступность и аннотации с дополнительной стоимостью. Из правил языка или API следует, что возникнет IllegalAccessException для публичного свойства.

Вопрос 14 из 30

Какую правку выбрать, чтобы сохранить назначение «Use-site target getter» и убрать хрупкость?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Target(AnnotationTarget.FIELD, AnnotationTarget.PROPERTY_GETTER)
annotation class Mark

class Model(@get:Mark val id: String)

Оставить структуру прежней, документировав утверждение: Она попадёт одновременно на поле, параметр конструктора и getter. Сверить target с потребителем фреймворка и добавить reflection/compile-test, который читает аннотацию тем же способом. Обернуть операцию проверкой и не менять основной контракт: Она применяется к классу Model, потому что стоит в primary constructor. Передать ответственность владельцу вызова, предполагая, что код не компилируется: use-site target нельзя указывать у val. Зафиксировать текущее поведение регрессионным тестом: Она существует только в Kotlin metadata и недоступна Java reflection независимо от retention.

Вопрос 15 из 30

Какой контрпример точнее всего показывает границу «Динамический обход properties»?

Обфускация, удаление неиспользуемых членов и разные платформы меняют доступность имён и reflection API. Проверить границу полезности утверждения: Результат автоматически сериализуем и стабилен между версиями. Воспроизвести редкий сценарий, где filterIsInstance доказывает, что каждый getter чистый и публичный. Отдельно воспроизвести случай, в котором kClass.members гарантирует порядок primary constructor на всех платформах. Проверить, сохраняется ли контракт, когда рефлексия выполняется на этапе компиляции и не имеет runtime-стоимости.

Вопрос 16 из 30

Какую обратную сторону имеет решение для «Чтение runtime-аннотации»: Добавить небольшой fixture-модуль со shrinker/обфускацией, если имена и runtime retention критичны в выпуске?

Компромисс состоит в утверждении: Создать User и сравнить его toString с названием аннотации. Практическое ограничение подхода: Проверить только наличие текста `@get:JsonName` в исходном файле. Интеграционный тест медленнее, но защищает границу между исходной аннотацией и фактическим артефактом. Обратная сторона изменения состоит в том, что считать успешную компиляцию доказательством RUNTIME retention. Решение оправдано лишь при условии: Мокировать KClass.members, не читая скомпилированную модель.

Вопрос 17 из 30

Что нужно доказать у такого кэша?

// Проследите фактическое выполнение без изменения кода.
import kotlin.reflect.*
class MetadataCache {
    private val cache = java.util.concurrent.ConcurrentHashMap<KClass<*>, Meta>()
    fun forClass(type: KClass<*>): Meta = cache.computeIfAbsent(type) { inspect(it) }
}

KClass не удерживает ClassLoader, поэтому утечка кэша невозможна. После кэширования reflection можно вызывать без обработки ошибок доступа. ConcurrentHashMap автоматически делает любой объект Meta immutable. `inspect` должна быть потокобезопасной и не публиковать частично собранный `Meta`. ComputeIfAbsent гарантирует один вызов mapping function при всех реализациях и рекурсивных зависимостях.

Вопрос 18 из 30

Что примерно вернёт функция для обычного списка?

// Проследите фактическое выполнение без изменения кода.
fun nameOf(x: Any): String? = x::class.simpleName
fun main() = println(nameOf(listOf(1, 2)))

Она гарантированно вернёт `List<Int>` вместе с generic-аргументом. Она создаст новый ClassLoader для объекта. Она вернёт статический тип параметра `Any`. Она вернёт простое имя фактического класса реализации, если оно доступно. Код не компилируется без зависимости kotlin-reflect для `::class`.

Вопрос 19 из 30

Какой сценарий выявит скрытое ограничение «Use-site target getter»?

Проверить соседний случай: Код не компилируется: use-site target нельзя указывать у val. Отдельно проверить предположение, что она существует только в Kotlin metadata и недоступна Java reflection независимо от retention. Без явного target компилятор выбирает допустимую цель по правилам, и библиотека, читающая поля, может не увидеть аннотацию getter. Проверить границу полезности утверждения: Она попадёт одновременно на поле, параметр конструктора и getter. Добавить тест на состояние, при котором она применяется к классу Model, потому что стоит в primary constructor.

Вопрос 20 из 30

Какой побочный эффект существеннее остальных после правки «Динамический обход properties»: Кэшировать проверенные метаданные, ограничить допустимые классы и предпочитать generated adapters для горячего пути?

Обратная сторона изменения состоит в том, что kClass.members гарантирует порядок primary constructor на всех платформах. Сопровождение усложнится, если окажется, что filterIsInstance доказывает, что каждый getter чистый и публичный. Динамический механизм уменьшает ручной glue-код, но платит стартовым временем, сложной диагностикой и слабой переносимостью. После правки останется ограничение: Результат автоматически сериализуем и стабилен между версиями. Новый риск связан с тем, что рефлексия выполняется на этапе компиляции и не имеет runtime-стоимости.

Вопрос 21 из 30

Как проверить контракт аннотации?

// Проследите фактическое выполнение без изменения кода.
@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.PROPERTY_GETTER)
annotation class JsonName(val value: String)

class User(@get:JsonName("user_name") val name: String)

Мокировать KClass.members, не читая скомпилированную модель. Создать User и сравнить его toString с названием аннотации. Считать успешную компиляцию доказательством RUNTIME retention. Проверить только наличие текста `@get:JsonName` в исходном файле. Через reflection найти getter `name`, прочитать `JsonName` и проверить `user_name`.

Вопрос 22 из 30

Какое утверждение точнее всего объясняет поведение фрагмента «Конкурентный кэш метаданных»?

// На ревью требуется объяснить причину поведения.
import kotlin.reflect.*
class MetadataCache {
    private val cache = java.util.concurrent.ConcurrentHashMap<KClass<*>, Meta>()
    fun forClass(type: KClass<*>): Meta = cache.computeIfAbsent(type) { inspect(it) }
}

Кэш метаданных меняет разовую динамическую стоимость на память и вопросы безопасной публикации, рекурсии и выгрузки классов. Причину поведения формулируют так: ComputeIfAbsent гарантирует один вызов mapping function при всех реализациях и рекурсивных зависимостях. Контракт здесь понимают так: ConcurrentHashMap автоматически делает любой объект Meta immutable. Здесь действует следующее правило: После кэширования reflection можно вызывать без обработки ошибок доступа. Объяснение опирается на утверждение: KClass не удерживает ClassLoader, поэтому утечка кэша невозможна.

Вопрос 23 из 30

Какой контракт снимает спор о причине поведения «Runtime-класс объекта»?

// На ревью требуется объяснить причину поведения.
fun nameOf(x: Any): String? = x::class.simpleName
fun main() = println(nameOf(listOf(1, 2)))

Механика примера описывается утверждением: Она вернёт статический тип параметра `Any`. Причина результата в том, что код не компилируется без зависимости kotlin-reflect для `::class`. Семантика фрагмента приводит к тому, что она создаст новый ClassLoader для объекта. Из правил языка или API следует, что она гарантированно вернёт `List<Int>` вместе с generic-аргументом. `KClass` описывает runtime-класс; часть базовых операций доступна без полного `kotlin-reflect`, а generic-аргументы объекта обычно стёрты.

Вопрос 24 из 30

Что стоит исправить в «Typed property reference» перед слиянием?

// Сохраните назначение фрагмента, но укрепите его контракт.
data class User(val name: String, var age: Int)
fun main() {
    val p = User::name
    println(p.get(User("Ada", 36)))
}

Добавить защитную проверку перед фрагментом, поскольку будет выведено `User`, поскольку receiver игнорируется. Спрятать участок за вспомогательной функцией, сохранив предположение: Код не компилируется: ссылку можно брать только на mutable-свойство. Передавать typed property references для маппинга и сортировки вместо строк имён, когда набор свойств известен компилятору. Перенести проверку в вызывающий код, исходя из того, что возникнет IllegalAccessException для публичного свойства. Ограничиться поясняющим комментарием о том, что будет выведено `name`, потому что ссылка хранит только имя.

Вопрос 25 из 30

Какой риск есть у такого универсального извлечения?

// Проследите фактическое выполнение без изменения кода.
import kotlin.reflect.*
fun values(obj: Any): List<Any?> = obj::class.members
    .filterIsInstance<kotlin.reflect.KProperty1<Any, *>>()
    .map { it.get(obj) }

KClass.members гарантирует порядок primary constructor на всех платформах. Рефлексия выполняется на этапе компиляции и не имеет runtime-стоимости. Рефлексия дороже прямого доступа, слабее типизирована, а getter может иметь побочный эффект. Результат автоматически сериализуем и стабилен между версиями. FilterIsInstance доказывает, что каждый getter чистый и публичный.

Вопрос 26 из 30

Почему поведение «Чтение runtime-аннотации» не является случайностью?

// На ревью требуется объяснить причину поведения.
@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.PROPERTY_GETTER)
annotation class JsonName(val value: String)

class User(@get:JsonName("user_name") val name: String)

Наблюдаемое поведение выводят из того, что создать User и сравнить его toString с названием аннотации. Объяснение опирается на утверждение: Проверить только наличие текста `@get:JsonName` в исходном файле. Такой результат объясняют тем, что считать успешную компиляцию доказательством RUNTIME retention. Тест аннотации должен использовать тот же канал, что потребитель: Java reflection, Kotlin reflection, KSP или compiler plugin. Ключевым считают контракт: Мокировать KClass.members, не читая скомпилированную модель.

Вопрос 27 из 30

Какую точечную правку стоит принять на ревью фрагмента «Конкурентный кэш метаданных»?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlin.reflect.*
class MetadataCache {
    private val cache = java.util.concurrent.ConcurrentHashMap<KClass<*>, Meta>()
    fun forClass(type: KClass<*>): Meta = cache.computeIfAbsent(type) { inspect(it) }
}

Оставить структуру прежней, документировав утверждение: KClass не удерживает ClassLoader, поэтому утечка кэша невозможна. Вынести участок в отдельный метод, считая верным следующее: ComputeIfAbsent гарантирует один вызов mapping function при всех реализациях и рекурсивных зависимостях. Передать ответственность владельцу вызова, предполагая, что после кэширования reflection можно вызывать без обработки ошибок доступа. Оставить реализацию без изменений и закрепить тестом предположение: ConcurrentHashMap автоматически делает любой объект Meta immutable. Строить immutable Meta локально, ограничить ключи жизненным циклом приложения и обработать циклические модели без рекурсивного deadlock.

Вопрос 28 из 30

Что стоит исправить в «Runtime-класс объекта» перед слиянием?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun nameOf(x: Any): String? = x::class.simpleName
fun main() = println(nameOf(listOf(1, 2)))

Добавить защитную проверку перед фрагментом, поскольку она создаст новый ClassLoader для объекта. Ограничиться поясняющим комментарием о том, что она вернёт статический тип параметра `Any`. Спрятать участок за вспомогательной функцией, сохранив предположение: Код не компилируется без зависимости kotlin-reflect для `::class`. Сохранить API и считать достаточным условие: Она гарантированно вернёт `List<Int>` вместе с generic-аргументом. Использовать явные типовые токены или sealed-регистрацию вместо сравнения `simpleName`, которое нестабильно при обфускации.

Вопрос 29 из 30

Какой дополнительный сценарий нужен для «Typed property reference»?

Принудительный `isAccessible = true` обходит исходную видимость и может быть запрещён модульной системой или окружением. Добавить граничный тест на утверждение: Возникнет IllegalAccessException для публичного свойства. Проверить крайний ввод, при котором будет выведено `name`, потому что ссылка хранит только имя. Зафиксировать сценарий, где ожидается: Код не компилируется: ссылку можно брать только на mutable-свойство. Проверить, сохраняется ли контракт, когда будет выведено `User`, поскольку receiver игнорируется.

Вопрос 30 из 30

Какой риск не исчезает после правки «Use-site target getter»: Сверить target с потребителем фреймворка и добавить reflection/compile-test, который читает аннотацию тем же способом?

Точное размещение улучшает interop, но привязывает модель к механизму конкретного фреймворка. Цена упрощения проявится, если код не компилируется: use-site target нельзя указывать у val. Практическое ограничение подхода: Она существует только в Kotlin metadata и недоступна Java reflection независимо от retention. Граница полезности решения описывается условием: Она попадёт одновременно на поле, параметр конструктора и getter. После внедрения придётся исходить из того, что она применяется к классу Model, потому что стоит в primary constructor.