Делегирование — бесплатный тест онлайн

Вопрос 1 из 25

На каком входе или состоянии граница «Наблюдаемая семантика делегата» становится заметной?

Считать опасной границей ситуацию, где проверить только значение первого чтения, не наблюдая количество вызовов factory. Тест, проходящий в одном потоке, ничего не доказывает о режиме `LazyThreadSafetyMode.NONE` при конкуренции. Проверить, сохраняется ли контракт, когда мокировать сам стандартный `lazy`, оставив factory невызванной. Добавить регрессию на гипотезу: Добавить `Thread.sleep` и считать, что поздний вывод доказывает ленивость. Проверить крайний ввод, при котором сравнить длину сгенерированного класса с обычным полем.

Вопрос 2 из 25

Какой побочный эффект существеннее остальных после правки «Обёртка через class delegation»: Использовать делегирование для прозрачной обёртки и явно документировать члены, поведение которых меняется?

Обратная сторона изменения состоит в том, что будут напечатаны обе строки автоматически. Сопровождение усложнится, если окажется, что возникнет рекурсия, потому что base.log вызывает PrefixLogger.log. Решение оправдано лишь при условии: Код не компилируется: нельзя сочетать `by` и override. Новый риск связан с тем, что она напечатает `start`, потому что делегированный метод имеет приоритет над override. Композиция через `by` уменьшает шаблонный код, но скрытая генерация методов может удивить при эволюции интерфейса.

Вопрос 3 из 25

Какое значение напечатает «Свойство в Map-делегате»?

// Проследите фактическое выполнение без изменения кода.
class Box {
    private val data = mutableMapOf<String, Any?>()
    var name: String by data
}
fun main() {
    val b = Box(); b.name = "Kotlin"; println(b.name)
}

Код не компилируется: Map нельзя использовать делегатом var. Будет выведено `name`, потому что ключ подставляется вместо значения. Будет выведена вся Map, а не строка. Возникнет NullPointerException при первом присваивании. Будет выведено `Kotlin`: Map-делегат использует имя свойства как ключ.

Вопрос 4 из 25

Что точнее описывает механику фрагмента «Кэширование lazy»?

// На ревью требуется объяснить причину поведения.
val token: String by lazy {
    println("compute")
    "abc"
}
fun main() {
    println(token)
    println(token)
}

Такой результат объясняют тем, что сначала два раза `abc`, затем `compute` при завершении программы. Стандартный `lazy` кэширует успешный результат; режим синхронизации определяет поведение при конкурентном первом доступе. Из правил языка или API следует, что код не компилируется: lazy разрешён только для локальных свойств. Здесь действует следующее правило: `compute` появится дважды, потому что lazy пересчитывается при каждом чтении. Механика примера описывается утверждением: Возникнет ошибка повторного чтения одноразового делегата.

Вопрос 5 из 25

Какая небольшая правка заметно повышает надёжность «Повторное значение observable»?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlin.properties.Delegates
class Model {
    var count: Int by Delegates.observable(0) { _, old, new ->
        println("$old->$new")
    }
}
fun main() { val m = Model(); m.count = 2; m.count = 2 }

Обернуть операцию проверкой и не менять основной контракт: Будет только `0->2`, потому что одинаковые значения автоматически подавляются. Сохранить API и считать достаточным условие: Второе присваивание завершится IllegalStateException. Передать ответственность владельцу вызова, предполагая, что будет `2->0`, затем `2->2`, так как параметры идут new, old. Добавить локальную обработку результата, потому что ничего не будет: делегат работает только для nullable-свойств. Если повторные равные значения не нужны, сравнивать old/new в callback или использовать поток состояния с подходящей семантикой.

Вопрос 6 из 25

Чем завершится выполнение «Обёртка через class delegation»?

// Проследите фактическое выполнение без изменения кода.
interface Logger { fun log(msg: String) }
class ConsoleLogger : Logger { override fun log(msg: String) = println(msg) }
class PrefixLogger(private val base: Logger) : Logger by base {
    override fun log(msg: String) = base.log("[app] $msg")
}
fun main() = PrefixLogger(ConsoleLogger()).log("start")

Она напечатает `start`, потому что делегированный метод имеет приоритет над override. Будет `[app] start`: явный override перехватывает делегированный метод. Код не компилируется: нельзя сочетать `by` и override. Возникнет рекурсия, потому что base.log вызывает PrefixLogger.log. Будут напечатаны обе строки автоматически.

Вопрос 7 из 25

Какое правило определяет поведение фрагмента «Свойство в Map-делегате»?

// На ревью требуется объяснить причину поведения.
class Box {
    private val data = mutableMapOf<String, Any?>()
    var name: String by data
}
fun main() {
    val b = Box(); b.name = "Kotlin"; println(b.name)
}

Поведение связывают с правилом: Возникнет NullPointerException при первом присваивании. Причина результата в том, что код не компилируется: Map нельзя использовать делегатом var. Контракт здесь понимают так: Будет выведена вся Map, а не строка. Делегат свойства получает объект и метаданные `KProperty`; для `var` нужны операции чтения и записи. Семантика фрагмента приводит к тому, что будет выведено `name`, потому что ключ подставляется вместо значения.

Вопрос 8 из 25

Как превратить неявное предположение в проверяемый контракт «Кэширование lazy»?

// Сохраните назначение фрагмента, но укрепите его контракт.
val token: String by lazy {
    println("compute")
    "abc"
}
fun main() {
    println(token)
    println(token)
}

Выбирать `PUBLICATION` или `NONE` только после анализа конкурентного доступа и допустимости повторного вычисления. Добавить локальную обработку результата, потому что `compute` появится дважды, потому что lazy пересчитывается при каждом чтении. Спрятать участок за вспомогательной функцией, сохранив предположение: Возникнет ошибка повторного чтения одноразового делегата. Сохранить API и считать достаточным условие: Сначала два раза `abc`, затем `compute` при завершении программы. Ограничиться поясняющим комментарием о том, что код не компилируется: lazy разрешён только для локальных свойств.

Вопрос 9 из 25

Что добавить в регрессионный набор для «Повторное значение observable»?

Callback выполняется синхронно в потоке присваивания; тяжёлая работа или обратная запись может вызвать задержку и рекурсию. Добавить регрессию на гипотезу: Будет `2->0`, затем `2->2`, так как параметры идут new, old. Проверить крайний ввод, при котором второе присваивание завершится IllegalStateException. Проверить соседний случай: Будет только `0->2`, потому что одинаковые значения автоматически подавляются. Считать опасной границей ситуацию, где ничего не будет: делегат работает только для nullable-свойств.

Вопрос 10 из 25

Команда собирается внедрить factory и счётчик либо fake-делегат, не привязывая проверку к реальным задержкам и планировщику. Что придётся учитывать после внедрения в «Наблюдаемая семантика делегата»?

После правки останется ограничение: Добавить `Thread.sleep` и считать, что поздний вывод доказывает ленивость. Главный риск формулируют так: Сравнить длину сгенерированного класса с обычным полем. Точный тест реализации полезен для собственного делегата, но для стандартного чаще достаточно тестировать поведение класса-потребителя. Главная цена решения — необходимость учитывать, что проверить только значение первого чтения, не наблюдая количество вызовов factory. После внедрения придётся исходить из того, что мокировать сам стандартный `lazy`, оставив factory невызванной.

Вопрос 11 из 25

Что стоит исправить в «Свойство в Map-делегате» перед слиянием?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Box {
    private val data = mutableMapOf<String, Any?>()
    var name: String by data
}
fun main() {
    val b = Box(); b.name = "Kotlin"; println(b.name)
}

Спрятать участок за вспомогательной функцией, сохранив предположение: Возникнет NullPointerException при первом присваивании. Применять Map-делегат для динамических адаптеров осторожно, проверяя тип и наличие ключа на границе. Сохранить API и считать достаточным условие: Код не компилируется: Map нельзя использовать делегатом var. Перенести проверку в вызывающий код, исходя из того, что будет выведена вся Map, а не строка. Ограничиться поясняющим комментарием о том, что будет выведено `name`, потому что ключ подставляется вместо значения.

Вопрос 12 из 25

Какой соседний случай отличает устойчивое решение «Кэширование lazy» от удачного примера?

Добавить регрессию на гипотезу: Возникнет ошибка повторного чтения одноразового делегата. Проверить соседний случай: Сначала два раза `abc`, затем `compute` при завершении программы. Если инициализатор бросил исключение, значение не считается инициализированным и следующий доступ повторит попытку. Добавить тест на состояние, при котором `compute` появится дважды, потому что lazy пересчитывается при каждом чтении. Отдельно проверить предположение, что код не компилируется: lazy разрешён только для локальных свойств.

Вопрос 13 из 25

Какова практическая цена решения «Повторное значение observable»: Если повторные равные значения не нужны, сравнивать old/new в callback или использовать поток состояния с подходящей семантикой?

Практическое ограничение подхода: Ничего не будет: делегат работает только для nullable-свойств. Делегат удобен для локального наблюдения, но не заменяет потокобезопасную реактивную модель для нескольких потребителей. Цена упрощения проявится, если будет `2->0`, затем `2->2`, так как параметры идут new, old. Компромисс состоит в утверждении: Второе присваивание завершится IllegalStateException. После внедрения придётся исходить из того, что будет только `0->2`, потому что одинаковые значения автоматически подавляются.

Вопрос 14 из 25

Как проверить делегат `lazy` без хрупкой зависимости от времени?

// Проследите фактическое выполнение без изменения кода.
class Once<T>(private val factory: () -> T) {
    val value: T by lazy(factory)
}

Сравнить длину сгенерированного класса с обычным полем. Мокировать сам стандартный `lazy`, оставив factory невызванной. Считать вызовы factory: до первого чтения 0, после нескольких чтений 1. Добавить `Thread.sleep` и считать, что поздний вывод доказывает ленивость. Проверить только значение первого чтения, не наблюдая количество вызовов factory.

Вопрос 15 из 25

Какой контракт определяет наблюдаемый результат «Обёртка через class delegation»?

// На ревью требуется объяснить причину поведения.
interface Logger { fun log(msg: String) }
class ConsoleLogger : Logger { override fun log(msg: String) = println(msg) }
class PrefixLogger(private val base: Logger) : Logger by base {
    override fun log(msg: String) = base.log("[app] $msg")
}
fun main() = PrefixLogger(ConsoleLogger()).log("start")

Причину поведения формулируют так: Она напечатает `start`, потому что делегированный метод имеет приоритет над override. Здесь действует следующее правило: Будут напечатаны обе строки автоматически. Делегирование интерфейса передаёт реализацию объекту-делегату; отдельные члены можно переопределить в обёртке. Ключевым считают контракт: Возникнет рекурсия, потому что base.log вызывает PrefixLogger.log. Объяснение опирается на утверждение: Код не компилируется: нельзя сочетать `by` и override.

Вопрос 16 из 25

Какое ограничение сохранится после правки «Кэширование lazy»: Выбирать `PUBLICATION` или `NONE` только после анализа конкурентного доступа и допустимости повторного вычисления?

Отложенная инициализация экономит работу, но переносит ошибку создания на первое использование и усложняет время запуска. Решение оправдано лишь при условии: Возникнет ошибка повторного чтения одноразового делегата. Практическое ограничение подхода: Сначала два раза `abc`, затем `compute` при завершении программы. Цена упрощения проявится, если `compute` появится дважды, потому что lazy пересчитывается при каждом чтении. Компромисс состоит в утверждении: Код не компилируется: lazy разрешён только для локальных свойств.

Вопрос 17 из 25

Что выведет наблюдатель?

// Проследите фактическое выполнение без изменения кода.
import kotlin.properties.Delegates
class Model {
    var count: Int by Delegates.observable(0) { _, old, new ->
        println("$old->$new")
    }
}
fun main() { val m = Model(); m.count = 2; m.count = 2 }

Он выведет `0->2`, затем `2->2`: `observable` вызывается после каждого присваивания. Ничего не будет: делегат работает только для nullable-свойств. Второе присваивание завершится IllegalStateException. Будет только `0->2`, потому что одинаковые значения автоматически подавляются. Будет `2->0`, затем `2->2`, так как параметры идут new, old.

Вопрос 18 из 25

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

// На ревью требуется объяснить причину поведения.
class Once<T>(private val factory: () -> T) {
    val value: T by lazy(factory)
}

Тест делегата должен наблюдать его контракт — число вычислений, порядок уведомлений и поведение при ошибке — через контролируемые эффекты. Наблюдаемое поведение выводят из того, что проверить только значение первого чтения, не наблюдая количество вызовов factory. Ключевым считают контракт: Мокировать сам стандартный `lazy`, оставив factory невызванной. Объяснение опирается на утверждение: Добавить `Thread.sleep` и считать, что поздний вывод доказывает ленивость. Здесь действует следующее правило: Сравнить длину сгенерированного класса с обычным полем.

Вопрос 19 из 25

Что следует изменить прежде всего во фрагменте «Обёртка через class delegation»?

// Сохраните назначение фрагмента, но укрепите его контракт.
interface Logger { fun log(msg: String) }
class ConsoleLogger : Logger { override fun log(msg: String) = println(msg) }
class PrefixLogger(private val base: Logger) : Logger by base {
    override fun log(msg: String) = base.log("[app] $msg")
}
fun main() = PrefixLogger(ConsoleLogger()).log("start")

Оставить структуру прежней, документировав утверждение: Она напечатает `start`, потому что делегированный метод имеет приоритет над override. Передать ответственность владельцу вызова, предполагая, что код не компилируется: нельзя сочетать `by` и override. Добавить локальную обработку результата, потому что возникнет рекурсия, потому что base.log вызывает PrefixLogger.log. Зафиксировать текущее поведение регрессионным тестом: Будут напечатаны обе строки автоматически. Использовать делегирование для прозрачной обёртки и явно документировать члены, поведение которых меняется.

Вопрос 20 из 25

Какой пограничный сценарий обязательно добавить к проверкам «Свойство в Map-делегате»?

Проверить соседний случай: Будет выведена вся Map, а не строка. Ошибка типа в backing Map проявится во время чтения cast-ом, а не в месте, где неверное значение было записано извне. Воспроизвести редкий сценарий, где будет выведено `name`, потому что ключ подставляется вместо значения. Отдельно воспроизвести случай, в котором код не компилируется: Map нельзя использовать делегатом var. Добавить тест на состояние, при котором возникнет NullPointerException при первом присваивании.

Вопрос 21 из 25

Какой контракт определяет наблюдаемый результат «Повторное значение observable»?

// На ревью требуется объяснить причину поведения.
import kotlin.properties.Delegates
class Model {
    var count: Int by Delegates.observable(0) { _, old, new ->
        println("$old->$new")
    }
}
fun main() { val m = Model(); m.count = 2; m.count = 2 }

Объяснение опирается на утверждение: Будет `2->0`, затем `2->2`, так как параметры идут new, old. Ключевым считают контракт: Второе присваивание завершится IllegalStateException. `observable` уведомляет после изменения, а `vetoable` может отклонить новое значение до записи. Причину поведения формулируют так: Будет только `0->2`, потому что одинаковые значения автоматически подавляются. Наблюдаемое поведение выводят из того, что ничего не будет: делегат работает только для nullable-свойств.

Вопрос 22 из 25

Что изменить в «Наблюдаемая семантика делегата», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Once<T>(private val factory: () -> T) {
    val value: T by lazy(factory)
}

Вынести участок в отдельный метод, считая верным следующее: Сравнить длину сгенерированного класса с обычным полем. Внедрить factory и счётчик либо fake-делегат, не привязывая проверку к реальным задержкам и планировщику. Оставить реализацию без изменений и закрепить тестом предположение: Проверить только значение первого чтения, не наблюдая количество вызовов factory. Оставить структуру прежней, документировав утверждение: Мокировать сам стандартный `lazy`, оставив factory невызванной. Перенести проверку в вызывающий код, исходя из того, что добавить `Thread.sleep` и считать, что поздний вывод доказывает ленивость.

Вопрос 23 из 25

Какой пограничный сценарий обязательно добавить к проверкам «Обёртка через class delegation»?

Добавить тест на состояние, при котором будут напечатаны обе строки автоматически. Проверить соседний случай: Возникнет рекурсия, потому что base.log вызывает PrefixLogger.log. Если делегат внутри вызывает собственный метод, вызов не перенаправляется автоматически на override обёртки. Воспроизвести редкий сценарий, где она напечатает `start`, потому что делегированный метод имеет приоритет над override. Проверить границу полезности утверждения: Код не компилируется: нельзя сочетать `by` и override.

Вопрос 24 из 25

Какой риск не исчезает после правки «Свойство в Map-делегате»: Применять Map-делегат для динамических адаптеров осторожно, проверяя тип и наличие ключа на границе?

Практическое ограничение подхода: Будет выведена вся Map, а не строка. Граница полезности решения описывается условием: Код не компилируется: Map нельзя использовать делегатом var. Делегат централизует повторяющуюся механику, но переносит часть поведения свойства из его объявления в другой объект. После внедрения придётся исходить из того, что будет выведено `name`, потому что ключ подставляется вместо значения. Цена упрощения проявится, если возникнет NullPointerException при первом присваивании.

Вопрос 25 из 25

Как поведёт себя фрагмент «Кэширование lazy» при указанных входных данных?

// Проследите фактическое выполнение без изменения кода.
val token: String by lazy {
    println("compute")
    "abc"
}
fun main() {
    println(token)
    println(token)
}

Возникнет ошибка повторного чтения одноразового делегата. `compute` появится дважды, потому что lazy пересчитывается при каждом чтении. Сначала `compute`, затем два раза `abc`: инициализатор lazy выполняется при первом доступе и результат кэшируется. Сначала два раза `abc`, затем `compute` при завершении программы. Код не компилируется: lazy разрешён только для локальных свойств.