Коллекции Kotlin — бесплатный тест онлайн

Вопрос 1 из 20

Что выведет или вернёт код в «Агрегирование groupingBy»?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val words = listOf("a", "bb", "c", "ddd")
    val counts = words.groupingBy { it.length }.eachCount()
    println(counts.toSortedMap())
}

Будет выведено `{1=[a, c], 2=[bb], 3=[ddd]}`, поскольку `eachCount` не меняет значения групп. Код не компилируется: `eachCount` работает только с числами. Будет выведено `{1=2, 2=1, 3=1}`: элементы сгруппированы по длине, затем подсчитаны. Будет выведено `{1=1, 2=1, 3=1}`, потому что одинаковые ключи перезаписываются. Будет выведено `{a=1, bb=2, c=1, ddd=3}`.

Вопрос 2 из 20

Что следует изменить прежде всего во фрагменте «Read-only представление MutableList»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val source = mutableListOf(1, 2)
    val view: List<Int> = source
    source += 3
    println(view)
}

На границе владения возвращать копию или устойчивую неизменяемую структуру, если потребителю нужен снимок. Обернуть операцию проверкой и не менять основной контракт: Код не компилируется: MutableList нельзя присвоить переменной типа List. Зафиксировать текущее поведение регрессионным тестом: Возникнет `UnsupportedOperationException` при изменении source. Оставить структуру прежней, документировав утверждение: Будет напечатано `[1, 2]`, потому что преобразование к `List` создаёт снимок. Добавить локальную обработку результата, потому что будет напечатано `[3]`, так как `+=` заменяет содержимое списка.

Вопрос 3 из 20

Где поведение «Порядок filter и map» требует отдельной проверки?

Порядок `map` и `filter` может менять не только стоимость, но и смысл, особенно если преобразование не является взаимно однозначным. Добавить тест на состояние, при котором будет выведен `[1, 9]`, поскольку фильтр применяется после преобразования. Проверить границу полезности утверждения: Будет выведен `[2, 4]`, потому что `map` не меняет значения. Проверить соседний случай: Будет выведен `[4]`, так как цепочка останавливается после первого совпадения. Добавить регрессию на гипотезу: Код не компилируется: `filter` доступен только для MutableList.

Вопрос 4 из 20

Команда собирается использовать Sequence, когда раннее завершение или длинная цепочка действительно сокращают работу, а не по привычке. Что придётся учитывать после внедрения в «Ленивая бесконечная Sequence»?

Главный риск формулируют так: Код не компилируется: `take` нельзя применять к бесконечной Sequence. Граница полезности решения описывается условием: Лямбда выполнится три раза, но получится `[1, 2, 3]`, поскольку `map` только наблюдает значения. После правки останется ограничение: Лямбда выполнится бесконечно, потому что исходная последовательность не имеет конца. Ленивость экономит промежуточные коллекции, но добавляет накладные вызовы и может быть медленнее на коротких наборах. Главная цена решения — необходимость учитывать, что лямбда выполнится один раз, получится `[2]`, так как Sequence кэширует первый элемент.

Вопрос 5 из 20

Что добавить в регрессионный набор для «Read-only представление MutableList»?

Отдельно проверить предположение, что будет напечатано `[1, 2]`, потому что преобразование к `List` создаёт снимок. Считать опасной границей ситуацию, где возникнет `UnsupportedOperationException` при изменении source. Java-коллекция, пришедшая через interop, может нарушать ожидания об изменяемости и null-элементах. Добавить регрессию на гипотезу: Код не компилируется: MutableList нельзя присвоить переменной типа List. Проверить крайний ввод, при котором будет напечатано `[3]`, так как `+=` заменяет содержимое списка.

Вопрос 6 из 20

Какое ограничение сохранится после правки «Порядок filter и map»: Сохранять ясную цепочку для небольших данных, а при больших объёмах измерить пользу `Sequence` или одного ручного прохода?

Декларативная цепочка проще читается, но длинный конвейер над списками может выделять много промежуточной памяти. Решение оправдано лишь при условии: Код не компилируется: `filter` доступен только для MutableList. Новый риск связан с тем, что будет выведен `[4]`, так как цепочка останавливается после первого совпадения. Компромисс состоит в утверждении: Будет выведен `[1, 9]`, поскольку фильтр применяется после преобразования. Цена упрощения проявится, если будет выведен `[2, 4]`, потому что `map` не меняет значения.

Вопрос 7 из 20

Сколько раз выполнится лямбда `map` и какой список получится?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val result = generateSequence(1) { it + 1 }
        .map { println("map $it"); it * 2 }
        .take(3)
        .toList()
    println(result)
}

Лямбда выполнится один раз, получится `[2]`, так как Sequence кэширует первый элемент. Лямбда выполнится три раза, получится `[2, 4, 6]`: Sequence лениво производит только затребованные элементы. Лямбда выполнится бесконечно, потому что исходная последовательность не имеет конца. Лямбда выполнится три раза, но получится `[1, 2, 3]`, поскольку `map` только наблюдает значения. Код не компилируется: `take` нельзя применять к бесконечной Sequence.

Вопрос 8 из 20

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

// На ревью требуется объяснить причину поведения.
fun main() {
    val words = listOf("a", "bb", "c", "ddd")
    val counts = words.groupingBy { it.length }.eachCount()
    println(counts.toSortedMap())
}

Наблюдаемое поведение выводят из того, что код не компилируется: `eachCount` работает только с числами. Ключевым считают контракт: Будет выведено `{1=[a, c], 2=[bb], 3=[ddd]}`, поскольку `eachCount` не меняет значения групп. Причину поведения формулируют так: Будет выведено `{a=1, bb=2, c=1, ddd=3}`. Объяснение опирается на утверждение: Будет выведено `{1=1, 2=1, 3=1}`, потому что одинаковые ключи перезаписываются. `groupBy` сразу создаёт списки значений, а `groupingBy` поддерживает отложенное агрегирование вроде `eachCount` и `fold`.

Вопрос 9 из 20

Что появится в выводе примера «Порядок filter и map»?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val result = listOf(1, 2, 3, 4)
        .filter { it % 2 == 0 }
        .map { it * it }
    println(result)
}

Будет выведен `[4, 16]`: сначала остаются чётные элементы, затем каждый из них возводится в квадрат. Код не компилируется: `filter` доступен только для MutableList. Будет выведен `[1, 9]`, поскольку фильтр применяется после преобразования. Будет выведен `[4]`, так как цепочка останавливается после первого совпадения. Будет выведен `[2, 4]`, потому что `map` не меняет значения.

Вопрос 10 из 20

Какое утверждение точнее всего объясняет поведение фрагмента «Ленивая бесконечная Sequence»?

// На ревью требуется объяснить причину поведения.
fun main() {
    val result = generateSequence(1) { it + 1 }
        .map { println("map $it"); it * 2 }
        .take(3)
        .toList()
    println(result)
}

Здесь действует следующее правило: Код не компилируется: `take` нельзя применять к бесконечной Sequence. Причину поведения формулируют так: Лямбда выполнится бесконечно, потому что исходная последовательность не имеет конца. Объяснение опирается на утверждение: Лямбда выполнится один раз, получится `[2]`, так как Sequence кэширует первый элемент. Наблюдаемое поведение выводят из того, что лямбда выполнится три раза, но получится `[1, 2, 3]`, поскольку `map` только наблюдает значения. Промежуточные операции Sequence ленивы, а вычисление запускается терминальной операцией и обычно идёт по одному элементу через цепочку.

Вопрос 11 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val words = listOf("a", "bb", "c", "ddd")
    val counts = words.groupingBy { it.length }.eachCount()
    println(counts.toSortedMap())
}

Передать ответственность владельцу вызова, предполагая, что будет выведено `{1=[a, c], 2=[bb], 3=[ddd]}`, поскольку `eachCount` не меняет значения групп. Выбирать агрегирование без списков, если нужны только количества или сводные значения, особенно на больших данных. Оставить структуру прежней, документировав утверждение: Будет выведено `{1=1, 2=1, 3=1}`, потому что одинаковые ключи перезаписываются. Обернуть операцию проверкой и не менять основной контракт: Код не компилируется: `eachCount` работает только с числами. Оставить реализацию без изменений и закрепить тестом предположение: Будет выведено `{a=1, bb=2, c=1, ddd=3}`.

Вопрос 12 из 20

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

После правки останется ограничение: Будет напечатано `[1, 2]`, потому что преобразование к `List` создаёт снимок. Read-only тип делает API уже без обязательной копии, но не подходит как гарантия снимка в конкурентной системе. После внедрения придётся исходить из того, что будет напечатано `[3]`, так как `+=` заменяет содержимое списка. Главная цена решения — необходимость учитывать, что код не компилируется: MutableList нельзя присвоить переменной типа List. Главный риск формулируют так: Возникнет `UnsupportedOperationException` при изменении source.

Вопрос 13 из 20

Что следует изменить прежде всего во фрагменте «Ленивая бесконечная Sequence»?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val result = generateSequence(1) { it + 1 }
        .map { println("map $it"); it * 2 }
        .take(3)
        .toList()
    println(result)
}

Использовать Sequence, когда раннее завершение или длинная цепочка действительно сокращают работу, а не по привычке. Оставить структуру прежней, документировав утверждение: Лямбда выполнится бесконечно, потому что исходная последовательность не имеет конца. Передать ответственность владельцу вызова, предполагая, что лямбда выполнится три раза, но получится `[1, 2, 3]`, поскольку `map` только наблюдает значения. Обернуть операцию проверкой и не менять основной контракт: Лямбда выполнится один раз, получится `[2]`, так как Sequence кэширует первый элемент. Добавить локальную обработку результата, потому что код не компилируется: `take` нельзя применять к бесконечной Sequence.

Вопрос 14 из 20

Где поведение «Агрегирование groupingBy» требует отдельной проверки?

Добавить тест на состояние, при котором будет выведено `{1=1, 2=1, 3=1}`, потому что одинаковые ключи перезаписываются. Проверить границу полезности утверждения: Будет выведено `{a=1, bb=2, c=1, ddd=3}`. Отдельно проверить предположение, что будет выведено `{1=[a, c], 2=[bb], 3=[ddd]}`, поскольку `eachCount` не меняет значения групп. Порядок ключей обычной Map не следует использовать как бизнес-контракт; для вывода нужна явная сортировка или подходящая реализация. Проверить соседний случай: Код не компилируется: `eachCount` работает только с числами.

Вопрос 15 из 20

Каков фактический результат выполнения фрагмента «Read-only представление MutableList»?

// Проследите фактическое выполнение без изменения кода.
fun main() {
    val source = mutableListOf(1, 2)
    val view: List<Int> = source
    source += 3
    println(view)
}

Будет напечатано `[1, 2]`, потому что преобразование к `List` создаёт снимок. Код не компилируется: MutableList нельзя присвоить переменной типа List. Будет напечатано `[3]`, так как `+=` заменяет содержимое списка. Возникнет `UnsupportedOperationException` при изменении source. Будет напечатано `[1, 2, 3]`: `view` ограничивает операции чтением, но указывает на тот же изменяемый объект.

Вопрос 16 из 20

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

// На ревью требуется объяснить причину поведения.
fun main() {
    val result = listOf(1, 2, 3, 4)
        .filter { it % 2 == 0 }
        .map { it * it }
    println(result)
}

Причину поведения формулируют так: Будет выведен `[2, 4]`, потому что `map` не меняет значения. Здесь действует следующее правило: Будет выведен `[4]`, так как цепочка останавливается после первого совпадения. Наблюдаемое поведение выводят из того, что будет выведен `[1, 9]`, поскольку фильтр применяется после преобразования. Ключевым считают контракт: Код не компилируется: `filter` доступен только для MutableList. Операторы обычных коллекций выполняются последовательно и обычно создают промежуточные коллекции на каждом этапе.

Вопрос 17 из 20

Какое ограничение сохранится после правки «Агрегирование groupingBy»: Выбирать агрегирование без списков, если нужны только количества или сводные значения, особенно на больших данных?

Решение оправдано лишь при условии: Будет выведено `{1=[a, c], 2=[bb], 3=[ddd]}`, поскольку `eachCount` не меняет значения групп. Готовые операции группировки уменьшают ручной код, но создание списков в каждой группе может быть заметно дороже точечного агрегата. Цена упрощения проявится, если будет выведено `{a=1, bb=2, c=1, ddd=3}`. Практическое ограничение подхода: Будет выведено `{1=1, 2=1, 3=1}`, потому что одинаковые ключи перезаписываются. Новый риск связан с тем, что код не компилируется: `eachCount` работает только с числами.

Вопрос 18 из 20

Какое правило нужно применить, чтобы объяснить «Read-only представление MutableList»?

// На ревью требуется объяснить причину поведения.
fun main() {
    val source = mutableListOf(1, 2)
    val view: List<Int> = source
    source += 3
    println(view)
}

Из правил языка или API следует, что будет напечатано `[3]`, так как `+=` заменяет содержимое списка. Здесь действует следующее правило: Код не компилируется: MutableList нельзя присвоить переменной типа List. Read-only интерфейс коллекции не равен глубокой неизменяемости и не гарантирует, что другой владелец не изменит объект. Наблюдаемое поведение выводят из того, что будет напечатано `[1, 2]`, потому что преобразование к `List` создаёт снимок. Ключевым считают контракт: Возникнет `UnsupportedOperationException` при изменении source.

Вопрос 19 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
fun main() {
    val result = listOf(1, 2, 3, 4)
        .filter { it % 2 == 0 }
        .map { it * it }
    println(result)
}

Сохранять ясную цепочку для небольших данных, а при больших объёмах измерить пользу `Sequence` или одного ручного прохода. Обернуть операцию проверкой и не менять основной контракт: Будет выведен `[2, 4]`, потому что `map` не меняет значения. Передать ответственность владельцу вызова, предполагая, что будет выведен `[1, 9]`, поскольку фильтр применяется после преобразования. Зафиксировать текущее поведение регрессионным тестом: Будет выведен `[4]`, так как цепочка останавливается после первого совпадения. Добавить локальную обработку результата, потому что код не компилируется: `filter` доступен только для MutableList.

Вопрос 20 из 20

Какой редкий случай способен сломать наивную трактовку «Ленивая бесконечная Sequence»?

Отдельно воспроизвести случай, в котором лямбда выполнится три раза, но получится `[1, 2, 3]`, поскольку `map` только наблюдает значения. Добавить граничный тест на утверждение: Лямбда выполнится один раз, получится `[2]`, так как Sequence кэширует первый элемент. Проверить, сохраняется ли контракт, когда лямбда выполнится бесконечно, потому что исходная последовательность не имеет конца. Повторная терминальная операция обычно повторно выполняет весь конвейер; Sequence не обязана кэшировать значения. Воспроизвести редкий сценарий, где код не компилируется: `take` нельзя применять к бесконечной Sequence.