Вариантность — бесплатный тест онлайн

Вопрос 1 из 25

В «Список неизвестного типа» выбрали решение: Использовать `*`, когда тип элемента не нужен, а если нужен — принять параметр типа и сохранить связь с результатом. Какова его реальная цена?

Главная цена решения — необходимость учитывать, что будут выведены `0` и `0`, потому что тип элементов неизвестен. Проекция удобна для инспекции структуры, но быстро приводит к ручным проверкам типов, если алгоритму всё же нужны элементы. Граница полезности решения описывается условием: Первый вызов завершится ClassCastException. Главный риск формулируют так: Второй вызов не компилируется после вывода `List<Int>` по первому вызову. Сопровождение усложнится, если окажется, что код не компилируется: `List<*>` нельзя принимать в функцию.

Вопрос 2 из 25

Почему объект `length` совместим с требуемым типом?

// Проследите фактическое выполнение без изменения кода.
interface Mapper<in A, out B> { fun map(value: A): B }
val length = object : Mapper<CharSequence, Int> {
    override fun map(value: CharSequence) = value.length
}
fun use(m: Mapper<String, Number>) = m.map("abc")
fun main() = println(use(length))

Код не компилируется: параметры типа с разной вариантностью нельзя сочетать. Совместимость возникает только из-за того, что Number и CharSequence оба наследуют Any. Объект совместим, но результат будет приведён к Double. Вызов допустим лишь при небезопасном cast во время выполнения. Он принимает `CharSequence` и возвращает `Int`, что соответствует `in A` и `out B`.

Вопрос 3 из 25

Что точнее описывает механику фрагмента «Проверка producer/consumer API»?

// На ревью требуется объяснить причину поведения.
fun copyAll(from: List<out Number>, to: MutableList<in Number>) {
    from.forEach { to += it }
}

Здесь действует следующее правило: Передать два `MutableList<Int>` и проверить только их одинаковый размер до вызова. Механика примера описывается утверждением: Измерить число байтов класса, не проверяя значения в приёмнике. Ключевым считают контракт: Скомпилировать функцию без вызова: этого достаточно для проверки направления данных. Компиляционные примеры и негативные тесты типов дополняют обычные unit-тесты, потому что часть контракта вариантности проявляется до запуска. Такой результат объясняют тем, что передать пустые списки одного типа и считать отсутствие исключения полным покрытием.

Вопрос 4 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
interface Source<out T> { fun next(): T }
class TextSource : Source<String> { override fun next() = "kt" }
fun readAny(source: Source<Any>) = source.next()
fun main() = println(readAny(TextSource()))

Передать ответственность владельцу вызова, предполагая, что код компилируется только из-за стирания и небезопасен для чтения. Помечать producer-интерфейсы ковариантными, если их публичный контракт только выдаёт значения типа T. Обернуть операцию проверкой и не менять основной контракт: Возникнет ClassCastException при возврате String через Source<Any>. Вынести участок в отдельный метод, считая верным следующее: Вызов не компилируется: generic-типы Kotlin инвариантны независимо от `out`. Оставить структуру прежней, документировав утверждение: Будет выведено имя класса String, потому что значение приводится к Any.

Вопрос 5 из 25

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

Отдельно воспроизвести случай, в котором код не компилируется: контравариантность работает только у функций стандартной библиотеки. Воспроизвести редкий сценарий, где программа напечатает `Any`, так как значение заменяется типом параметра. Проверить границу полезности утверждения: Возникнет ClassCastException внутри accept. Из контравариантного параметра нельзя безопасно вернуть T точнее `Any?`, потому что фактический тип может быть шире ожидаемого. Добавить граничный тест на утверждение: Он подходит, потому что String является супертипом Any.

Вопрос 6 из 25

Какой контракт снимает спор о причине поведения «Поток типов через Mapper»?

// На ревью требуется объяснить причину поведения.
interface Mapper<in A, out B> { fun map(value: A): B }
val length = object : Mapper<CharSequence, Int> {
    override fun map(value: CharSequence) = value.length
}
fun use(m: Mapper<String, Number>) = m.map("abc")
fun main() = println(use(length))

Причина результата в том, что код не компилируется: параметры типа с разной вариантностью нельзя сочетать. Из правил языка или API следует, что совместимость возникает только из-за того, что Number и CharSequence оба наследуют Any. Вариантность должна следовать направлению данных в контракте: вход потребляется, выход производится. Поведение связывают с правилом: Вызов допустим лишь при небезопасном cast во время выполнения. Семантика фрагмента приводит к тому, что объект совместим, но результат будет приведён к Double.

Вопрос 7 из 25

Как превратить неявное предположение в проверяемый контракт «Проверка producer/consumer API»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun copyAll(from: List<out Number>, to: MutableList<in Number>) {
    from.forEach { to += it }
}

Добавить локальную обработку результата, потому что скомпилировать функцию без вызова: этого достаточно для проверки направления данных. Спрятать участок за вспомогательной функцией, сохранив предположение: Измерить число байтов класса, не проверяя значения в приёмнике. Зафиксировать текущее поведение регрессионным тестом: Передать два `MutableList<Int>` и проверить только их одинаковый размер до вызова. Ограничиться поясняющим комментарием о том, что передать пустые списки одного типа и считать отсутствие исключения полным покрытием. Добавить compile-testing пример, который должен отвергать запись неподходящего типа, и обычный тест успешного копирования между разными уровнями иерархии.

Вопрос 8 из 25

Где поведение «Ковариантный источник» требует отдельной проверки?

Добавить тест на состояние, при котором будет выведено имя класса String, потому что значение приводится к Any. Проверить границу полезности утверждения: Вызов не компилируется: generic-типы Kotlin инвариантны независимо от `out`. `out` не делает изменяемую коллекцию безопасно ковариантной: добавление значения более широкого типа сломало бы исходный контейнер. Добавить регрессию на гипотезу: Код компилируется только из-за стирания и небезопасен для чтения. Проверить соседний случай: Возникнет ClassCastException при возврате String через Source<Any>.

Вопрос 9 из 25

Команда собирается выделять consumer-контракт без возврата T, если реализация должна обслуживать значения разных подтипов. Что придётся учитывать после внедрения в «Контравариантный потребитель»?

После правки останется ограничение: Он подходит, потому что String является супертипом Any. Главная цена решения — необходимость учитывать, что код не компилируется: контравариантность работает только у функций стандартной библиотеки. Граница полезности решения описывается условием: Программа напечатает `Any`, так как значение заменяется типом параметра. Контравариантность уменьшает число адаптеров, но непривычное направление подтипизации повышает цену чтения сигнатур. Главный риск формулируют так: Возникнет ClassCastException внутри accept.

Вопрос 10 из 25

Какие числа будут выведены?

// Проследите фактическое выполнение без изменения кода.
fun sizeOf(x: List<*>) = x.size
fun main() {
    println(sizeOf(listOf(1, 2, 3)))
    println(sizeOf(listOf("a")))
}

Второй вызов не компилируется после вывода `List<Int>` по первому вызову. Код не компилируется: `List<*>` нельзя принимать в функцию. Будут выведены `3` и `1`: размер списка не зависит от неизвестного типа элемента. Первый вызов завершится ClassCastException. Будут выведены `0` и `0`, потому что тип элементов неизвестен.

Вопрос 11 из 25

Какой соседний случай отличает устойчивое решение «Проверка producer/consumer API» от удачного примера?

Считать опасной границей ситуацию, где измерить число байтов класса, не проверяя значения в приёмнике. Добавить регрессию на гипотезу: Передать пустые списки одного типа и считать отсутствие исключения полным покрытием. Избыточный `out` на `List` может быть предупреждён как redundant: сам `List` уже ковариантен. Отдельно проверить предположение, что скомпилировать функцию без вызова: этого достаточно для проверки направления данных. Добавить тест на состояние, при котором передать два `MutableList<Int>` и проверить только их одинаковый размер до вызова.

Вопрос 12 из 25

Для «Ковариантный источник» предлагают правку: Помечать producer-интерфейсы ковариантными, если их публичный контракт только выдаёт значения типа T. Какой компромисс нельзя пропустить?

После внедрения придётся исходить из того, что возникнет ClassCastException при возврате String через Source<Any>. Ковариантность делает API гибче для чтения, но ограничивает операции, в которых T выступает потребляемым значением. Цена упрощения проявится, если код компилируется только из-за стирания и небезопасен для чтения. Граница полезности решения описывается условием: Будет выведено имя класса String, потому что значение приводится к Any. Главная цена решения — необходимость учитывать, что вызов не компилируется: generic-типы Kotlin инвариантны независимо от `out`.

Вопрос 13 из 25

Почему `Sink<Any>` подходит функции?

// Проследите фактическое выполнение без изменения кода.
fun interface Sink<in T> { fun accept(value: T) }
fun sendStrings(sink: Sink<String>) { sink.accept("Kotlin") }
fun main() {
    val anySink = Sink<Any> { println(it) }
    sendStrings(anySink)
}

Программа напечатает `Any`, так как значение заменяется типом параметра. Он подходит, потому что String является супертипом Any. Код не компилируется: контравариантность работает только у функций стандартной библиотеки. Контравариантный `in T` позволяет потребителю Any принимать String; программа напечатает `Kotlin`. Возникнет ClassCastException внутри accept.

Вопрос 14 из 25

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

// На ревью требуется объяснить причину поведения.
fun sizeOf(x: List<*>) = x.size
fun main() {
    println(sizeOf(listOf(1, 2, 3)))
    println(sizeOf(listOf("a")))
}

Такой результат объясняют тем, что первый вызов завершится ClassCastException. Из правил языка или API следует, что второй вызов не компилируется после вывода `List<Int>` по первому вызову. Ключевым считают контракт: Будут выведены `0` и `0`, потому что тип элементов неизвестен. Star projection выражает «список неизвестного типа» с безопасным набором операций, не равный `List<Any?>` для записи. Здесь действует следующее правило: Код не компилируется: `List<*>` нельзя принимать в функцию.

Вопрос 15 из 25

Какую точечную правку стоит принять на ревью фрагмента «Поток типов через Mapper»?

// Сохраните назначение фрагмента, но укрепите его контракт.
interface Mapper<in A, out B> { fun map(value: A): B }
val length = object : Mapper<CharSequence, Int> {
    override fun map(value: CharSequence) = value.length
}
fun use(m: Mapper<String, Number>) = m.map("abc")
fun main() = println(use(length))

Оставить структуру прежней, документировав утверждение: Код не компилируется: параметры типа с разной вариантностью нельзя сочетать. Вынести участок в отдельный метод, считая верным следующее: Совместимость возникает только из-за того, что Number и CharSequence оба наследуют Any. Передать ответственность владельцу вызова, предполагая, что вызов допустим лишь при небезопасном cast во время выполнения. Начинать с инвариантного API и добавлять `in`/`out`, когда позиции параметра доказывают безопасность и реальную пользу потребителям. Обернуть операцию проверкой и не менять основной контракт: Объект совместим, но результат будет приведён к Double.

Вопрос 16 из 25

Почему вызов допустим и что он выведет?

// Проследите фактическое выполнение без изменения кода.
interface Source<out T> { fun next(): T }
class TextSource : Source<String> { override fun next() = "kt" }
fun readAny(source: Source<Any>) = source.next()
fun main() = println(readAny(TextSource()))

Возникнет ClassCastException при возврате String через Source<Any>. Будет выведено имя класса String, потому что значение приводится к Any. Ковариантность `out T` позволяет использовать `Source<String>` как `Source<Any>`; будет выведено `kt`. Код компилируется только из-за стирания и небезопасен для чтения. Вызов не компилируется: generic-типы Kotlin инвариантны независимо от `out`.

Вопрос 17 из 25

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

// На ревью требуется объяснить причину поведения.
fun interface Sink<in T> { fun accept(value: T) }
fun sendStrings(sink: Sink<String>) { sink.accept("Kotlin") }
fun main() {
    val anySink = Sink<Any> { println(it) }
    sendStrings(anySink)
}

`in` безопасно расширяет использование потребителя: объект, умеющий принимать Any, умеет принять и String. Семантика фрагмента приводит к тому, что он подходит, потому что String является супертипом Any. Поведение связывают с правилом: Код не компилируется: контравариантность работает только у функций стандартной библиотеки. Причину поведения формулируют так: Программа напечатает `Any`, так как значение заменяется типом параметра. Объяснение опирается на утверждение: Возникнет ClassCastException внутри accept.

Вопрос 18 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
fun sizeOf(x: List<*>) = x.size
fun main() {
    println(sizeOf(listOf(1, 2, 3)))
    println(sizeOf(listOf("a")))
}

Добавить локальную обработку результата, потому что будут выведены `0` и `0`, потому что тип элементов неизвестен. Сохранить API и считать достаточным условие: Первый вызов завершится ClassCastException. Спрятать участок за вспомогательной функцией, сохранив предположение: Второй вызов не компилируется после вывода `List<Int>` по первому вызову. Зафиксировать текущее поведение регрессионным тестом: Код не компилируется: `List<*>` нельзя принимать в функцию. Использовать `*`, когда тип элемента не нужен, а если нужен — принять параметр типа и сохранить связь с результатом.

Вопрос 19 из 25

Какой сценарий выявит скрытое ограничение «Поток типов через Mapper»?

Проверить границу полезности утверждения: Код не компилируется: параметры типа с разной вариантностью нельзя сочетать. Воспроизвести редкий сценарий, где совместимость возникает только из-за того, что Number и CharSequence оба наследуют Any. Добавить тест на состояние, при котором объект совместим, но результат будет приведён к Double. Проверить соседний случай: Вызов допустим лишь при небезопасном cast во время выполнения. Параметр, встречающийся и во входе, и в выходе, обычно должен оставаться инвариантным либо разделяться на два контракта.

Вопрос 20 из 25

Решение для «Проверка producer/consumer API»: Добавить compile-testing пример, который должен отвергать запись неподходящего типа, и обычный тест успешного копирования между разными уровнями иерархии. Что в нём остаётся не бесплатным?

Обратная сторона изменения состоит в том, что передать два `MutableList<Int>` и проверить только их одинаковый размер до вызова. Главная цена решения — необходимость учитывать, что измерить число байтов класса, не проверяя значения в приёмнике. Compile-testing хорошо фиксирует API, но делает тесты чувствительными к формулировкам диагностики и версии компилятора. Сопровождение усложнится, если окажется, что скомпилировать функцию без вызова: этого достаточно для проверки направления данных. После правки останется ограничение: Передать пустые списки одного типа и считать отсутствие исключения полным покрытием.

Вопрос 21 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
fun interface Sink<in T> { fun accept(value: T) }
fun sendStrings(sink: Sink<String>) { sink.accept("Kotlin") }
fun main() {
    val anySink = Sink<Any> { println(it) }
    sendStrings(anySink)
}

Ограничиться поясняющим комментарием о том, что он подходит, потому что String является супертипом Any. Перенести проверку в вызывающий код, исходя из того, что программа напечатает `Any`, так как значение заменяется типом параметра. Оставить реализацию без изменений и закрепить тестом предположение: Возникнет ClassCastException внутри accept. Добавить защитную проверку перед фрагментом, поскольку код не компилируется: контравариантность работает только у функций стандартной библиотеки. Выделять consumer-контракт без возврата T, если реализация должна обслуживать значения разных подтипов.

Вопрос 22 из 25

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

Проверить соседний случай: Будут выведены `0` и `0`, потому что тип элементов неизвестен. Добавить регрессию на гипотезу: Первый вызов завершится ClassCastException. В `MutableList<*>` нельзя безопасно добавить ни произвольное значение, ни `null`: тип допустимого элемента скрыт проекцией и для записи сводится к `Nothing`. Считать опасной границей ситуацию, где второй вызов не компилируется после вывода `List<Int>` по первому вызову. Добавить тест на состояние, при котором код не компилируется: `List<*>` нельзя принимать в функцию.

Вопрос 23 из 25

Команда собирается начинать с инвариантного API и добавлять `in`/`out`, когда позиции параметра доказывают безопасность и реальную пользу потребителям. Что придётся учитывать после внедрения в «Поток типов через Mapper»?

Граница полезности решения описывается условием: Объект совместим, но результат будет приведён к Double. Точная вариантность убирает адаптеры, но слишком хитрая сигнатура может быть хуже двух простых интерфейсов. После внедрения придётся исходить из того, что вызов допустим лишь при небезопасном cast во время выполнения. После правки останется ограничение: Совместимость возникает только из-за того, что Number и CharSequence оба наследуют Any. Главная цена решения — необходимость учитывать, что код не компилируется: параметры типа с разной вариантностью нельзя сочетать.

Вопрос 24 из 25

Что нужно проверить отдельно, чтобы не принять «Проверка producer/consumer API» за универсальное правило?

// Проследите фактическое выполнение без изменения кода.
fun copyAll(from: List<out Number>, to: MutableList<in Number>) {
    from.forEach { to += it }
}

Измерить число байтов класса, не проверяя значения в приёмнике. Передать `List<Int>` и `MutableList<Any>`, затем проверить, что все числа добавлены без cast и исходный список не менялся. Скомпилировать функцию без вызова: этого достаточно для проверки направления данных. Передать два `MutableList<Int>` и проверить только их одинаковый размер до вызова. Передать пустые списки одного типа и считать отсутствие исключения полным покрытием.

Вопрос 25 из 25

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

// На ревью требуется объяснить причину поведения.
interface Source<out T> { fun next(): T }
class TextSource : Source<String> { override fun next() = "kt" }
fun readAny(source: Source<Any>) = source.next()
fun main() = println(readAny(TextSource()))

Из правил языка или API следует, что вызов не компилируется: generic-типы Kotlin инвариантны независимо от `out`. Причина результата в том, что возникнет ClassCastException при возврате String через Source<Any>. Механика примера описывается утверждением: Будет выведено имя класса String, потому что значение приводится к Any. Declaration-site `out` разрешает производить T, но запрещает принимать T во входных позициях, где это нарушило бы ковариантность. Семантика фрагмента приводит к тому, что код компилируется только из-за стирания и небезопасен для чтения.