Классы и конструкторы — бесплатный тест онлайн

Вопрос 1 из 20

Для «Параметр primary constructor» предлагают правку: Хранить нормализованное значение как отдельное read-only свойство, а исходный параметр не превращать в состояние без необходимости. Какой компромисс нельзя пропустить?

Главный риск формулируют так: Она напечатает пустую строку: `raw` освобождается после вызова конструктора. Цена упрощения проявится, если возникнет ошибка доступа, поскольку параметр конструктора имеет видимость `private`. Короткий primary constructor делает инварианты заметными, но сложное создание объекта лучше вынести в фабрику. Главная цена решения — необходимость учитывать, что код не компилируется, потому что `raw` не объявлен через `val`. Граница полезности решения описывается условием: Она напечатает `AbC`, так как параметры конструктора нельзя преобразовывать до `init`.

Вопрос 2 из 20

Каков результат выполнения?

// Проследите фактическое выполнение без изменения кода.
class Range(val start: Int, val end: Int) {
    init { require(start <= end) { "перевёрнутый диапазон" } }
    val size = end - start + 1
}

fun main() = println(Range(3, 5).size)

Будет выведено `3`: блок `init` подтверждает инвариант, после чего вычисляется `size`. Код не компилируется: `require` нельзя использовать в `init`. Возникнет `IllegalStateException`, поскольку `require` проверяет только локальные переменные. Сначала вычисляется `size`, затем запускается `init`, поэтому результат не определён. Будет выведено `2`, потому что правый конец не включается.

Вопрос 3 из 20

На какой контракт языка или библиотеки опирается «Публичное чтение и закрытая запись»?

// На ревью требуется объяснить причину поведения.
class Counter {
    var value: Int = 0
        private set

    fun add(delta: Int) { value += delta }
}

fun main() {
    val c = Counter()
    c.add(3)
    println(c.value)
}

Объяснение опирается на утверждение: Возникнет ошибка времени выполнения при чтении свойства с приватным setter. Причину поведения формулируют так: Она выведет `0`, потому что `value += delta` вызывает недоступный setter. Видимость getter и setter можно настраивать раздельно; поле backing field существует только там, где оно действительно требуется. Наблюдаемое поведение выводят из того, что код не компилируется без явного getter. Контракт здесь понимают так: Код не компилируется: `private set` запрещает изменять свойство даже методам класса.

Вопрос 4 из 20

Что изменить в «Границы internal и private», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
internal class Parser {
    private fun clean(s: String) = s.trim()
    fun parse(s: String): Int = clean(s).toInt()
}

fun main() = println(Parser().parse(" 42 "))

Обернуть операцию проверкой и не менять основной контракт: Возникнет `IllegalAccessError`, когда JVM увидит internal-класс. Вынести участок в отдельный метод, считая верным следующее: Код не компилируется: публичный метод не может вызывать private-метод. Перенести проверку в вызывающий код, исходя из того, что код не компилируется, потому что `internal` доступен только внутри файла. Оставить структуру прежней, документировав утверждение: Будет выведено `0`, поскольку `clean` недоступен точке входа. Публиковать минимальный API модуля, а детали разбора оставлять `internal` или `private`, не полагаясь только на соглашение имён.

Вопрос 5 из 20

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

// На ревью требуется объяснить причину поведения.
class Range(val start: Int, val end: Int) {
    init { require(start <= end) { "перевёрнутый диапазон" } }
    val size = end - start + 1
}

fun main() = println(Range(3, 5).size)

Причину поведения формулируют так: Сначала вычисляется `size`, затем запускается `init`, поэтому результат не определён. Семантика фрагмента приводит к тому, что будет выведено `2`, потому что правый конец не включается. Объяснение опирается на утверждение: Возникнет `IllegalStateException`, поскольку `require` проверяет только локальные переменные. Поведение связывают с правилом: Код не компилируется: `require` нельзя использовать в `init`. Блоки `init` и инициализаторы свойств выполняются в порядке появления в теле класса после вычисления аргументов конструктора.

Вопрос 6 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
class Counter {
    var value: Int = 0
        private set

    fun add(delta: Int) { value += delta }
}

fun main() {
    val c = Counter()
    c.add(3)
    println(c.value)
}

Зафиксировать текущее поведение регрессионным тестом: Код не компилируется без явного getter. Вынести участок в отдельный метод, считая верным следующее: Код не компилируется: `private set` запрещает изменять свойство даже методам класса. Оставить структуру прежней, документировав утверждение: Она выведет `0`, потому что `value += delta` вызывает недоступный setter. Обернуть операцию проверкой и не менять основной контракт: Возникнет ошибка времени выполнения при чтении свойства с приватным setter. Оставить внешний контракт read-only и проводить изменения через методы, которые защищают инварианты счётчика.

Вопрос 7 из 20

Какой сценарий выявит скрытое ограничение «Границы internal и private»?

Воспроизвести редкий сценарий, где код не компилируется, потому что `internal` доступен только внутри файла. Проверить соседний случай: Возникнет `IllegalAccessError`, когда JVM увидит internal-класс. На JVM `internal` реализуется через соглашения и преобразование имён; Java-код может обойти часть исходных ограничений. Добавить тест на состояние, при котором будет выведено `0`, поскольку `clean` недоступен точке входа. Проверить границу полезности утверждения: Код не компилируется: публичный метод не может вызывать private-метод.

Вопрос 8 из 20

Какой результат даст пример «Параметр primary constructor» без изменения окружения?

// Проследите фактическое выполнение без изменения кода.
class Token(raw: String) {
    val value = raw.trim().lowercase()
}

fun main() = println(Token("  AbC ").value)

Она напечатает `AbC`, так как параметры конструктора нельзя преобразовывать до `init`. Возникнет ошибка доступа, поскольку параметр конструктора имеет видимость `private`. Код не компилируется, потому что `raw` не объявлен через `val`. Она напечатает `abc`: параметр primary constructor доступен в инициализаторах свойств, хотя сам по себе не становится свойством. Она напечатает пустую строку: `raw` освобождается после вызова конструктора.

Вопрос 9 из 20

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

Отдельно проверить предположение, что она выведет `0`, потому что `value += delta` вызывает недоступный setter. Пользовательский getter без backing field вычисляется при каждом обращении и не хранит отдельное значение. Считать опасной границей ситуацию, где код не компилируется без явного getter. Добавить регрессию на гипотезу: Возникнет ошибка времени выполнения при чтении свойства с приватным setter. Добавить тест на состояние, при котором код не компилируется: `private set` запрещает изменять свойство даже методам класса.

Вопрос 10 из 20

Для «Границы internal и private» предлагают правку: Публиковать минимальный API модуля, а детали разбора оставлять `internal` или `private`, не полагаясь только на соглашение имён. Какой компромисс нельзя пропустить?

Цена упрощения проявится, если возникнет `IllegalAccessError`, когда JVM увидит internal-класс. Главная цена решения — необходимость учитывать, что код не компилируется, потому что `internal` доступен только внутри файла. Узкая видимость облегчает эволюцию реализации, но чрезмерное сокрытие усложняет интеграционные тесты и повторное использование. После внедрения придётся исходить из того, что будет выведено `0`, поскольку `clean` недоступен точке входа. Граница полезности решения описывается условием: Код не компилируется: публичный метод не может вызывать private-метод.

Вопрос 11 из 20

Какое правило определяет поведение фрагмента «Параметр primary constructor»?

// На ревью требуется объяснить причину поведения.
class Token(raw: String) {
    val value = raw.trim().lowercase()
}

fun main() = println(Token("  AbC ").value)

Причину поведения формулируют так: Возникнет ошибка доступа, поскольку параметр конструктора имеет видимость `private`. Параметр primary constructor входит в область инициализации класса; свойством он становится только с `val` или `var` в объявлении. Причина результата в том, что код не компилируется, потому что `raw` не объявлен через `val`. Семантика фрагмента приводит к тому, что она напечатает `AbC`, так как параметры конструктора нельзя преобразовывать до `init`. Поведение связывают с правилом: Она напечатает пустую строку: `raw` освобождается после вызова конструктора.

Вопрос 12 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
class Range(val start: Int, val end: Int) {
    init { require(start <= end) { "перевёрнутый диапазон" } }
    val size = end - start + 1
}

fun main() = println(Range(3, 5).size)

Зафиксировать текущее поведение регрессионным тестом: Будет выведено `2`, потому что правый конец не включается. Проверять инварианты до публикации объекта и давать сообщению об ошибке конкретное значение, нарушившее контракт. Ограничиться поясняющим комментарием о том, что возникнет `IllegalStateException`, поскольку `require` проверяет только локальные переменные. Добавить локальную обработку результата, потому что код не компилируется: `require` нельзя использовать в `init`. Сохранить API и считать достаточным условие: Сначала вычисляется `size`, затем запускается `init`, поэтому результат не определён.

Вопрос 13 из 20

Каков результат в пределах того же модуля?

// Проследите фактическое выполнение без изменения кода.
internal class Parser {
    private fun clean(s: String) = s.trim()
    fun parse(s: String): Int = clean(s).toInt()
}

fun main() = println(Parser().parse(" 42 "))

Будет выведено `42`: `internal` виден внутри модуля, а private-метод — внутри своего класса. Возникнет `IllegalAccessError`, когда JVM увидит internal-класс. Код не компилируется, потому что `internal` доступен только внутри файла. Код не компилируется: публичный метод не может вызывать private-метод. Будет выведено `0`, поскольку `clean` недоступен точке входа.

Вопрос 14 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
class Token(raw: String) {
    val value = raw.trim().lowercase()
}

fun main() = println(Token("  AbC ").value)

Обернуть операцию проверкой и не менять основной контракт: Возникнет ошибка доступа, поскольку параметр конструктора имеет видимость `private`. Перенести проверку в вызывающий код, исходя из того, что код не компилируется, потому что `raw` не объявлен через `val`. Оставить структуру прежней, документировав утверждение: Она напечатает пустую строку: `raw` освобождается после вызова конструктора. Хранить нормализованное значение как отдельное read-only свойство, а исходный параметр не превращать в состояние без необходимости. Вынести участок в отдельный метод, считая верным следующее: Она напечатает `AbC`, так как параметры конструктора нельзя преобразовывать до `init`.

Вопрос 15 из 20

Какой дополнительный сценарий нужен для «Инвариант в init»?

Проверить крайний ввод, при котором код не компилируется: `require` нельзя использовать в `init`. Проверить, сохраняется ли контракт, когда сначала вычисляется `size`, затем запускается `init`, поэтому результат не определён. Вызов open-члена из конструктора может попасть в переопределение подкласса до завершения его инициализации. Считать опасной границей ситуацию, где будет выведено `2`, потому что правый конец не включается. Добавить граничный тест на утверждение: Возникнет `IllegalStateException`, поскольку `require` проверяет только локальные переменные.

Вопрос 16 из 20

В «Публичное чтение и закрытая запись» выбрали решение: Оставить внешний контракт read-only и проводить изменения через методы, которые защищают инварианты счётчика. Какова его реальная цена?

Главная цена решения — необходимость учитывать, что возникнет ошибка времени выполнения при чтении свойства с приватным setter. После правки останется ограничение: Она выведет `0`, потому что `value += delta` вызывает недоступный setter. Инкапсулированный setter ограничивает случайные изменения, но слишком много мелких методов-мутаторов может размыть доменную операцию. Главный риск формулируют так: Код не компилируется без явного getter. Сопровождение усложнится, если окажется, что код не компилируется: `private set` запрещает изменять свойство даже методам класса.

Вопрос 17 из 20

Какой сценарий выявит скрытое ограничение «Параметр primary constructor»?

Добавить тест на состояние, при котором она напечатает пустую строку: `raw` освобождается после вызова конструктора. Порядок инициализации следует тексту класса: ранний инициализатор не должен обращаться к свойству, которое ещё не инициализировано. Воспроизвести редкий сценарий, где код не компилируется, потому что `raw` не объявлен через `val`. Проверить соседний случай: Возникнет ошибка доступа, поскольку параметр конструктора имеет видимость `private`. Проверить границу полезности утверждения: Она напечатает `AbC`, так как параметры конструктора нельзя преобразовывать до `init`.

Вопрос 18 из 20

Предложенная правка для «Инвариант в init» звучит так: Проверять инварианты до публикации объекта и давать сообщению об ошибке конкретное значение, нарушившее контракт. Какой недостаток важнее обсудить?

Инвариант в `init` не допускает полусобранный объект, но для ожидаемой ошибки ввода иногда удобнее фабрика с явным результатом. Граница полезности решения описывается условием: Возникнет `IllegalStateException`, поскольку `require` проверяет только локальные переменные. Сопровождение усложнится, если окажется, что будет выведено `2`, потому что правый конец не включается. Главная цена решения — необходимость учитывать, что сначала вычисляется `size`, затем запускается `init`, поэтому результат не определён. После правки останется ограничение: Код не компилируется: `require` нельзя использовать в `init`.

Вопрос 19 из 20

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

// Проследите фактическое выполнение без изменения кода.
class Counter {
    var value: Int = 0
        private set

    fun add(delta: Int) { value += delta }
}

fun main() {
    val c = Counter()
    c.add(3)
    println(c.value)
}

Возникнет ошибка времени выполнения при чтении свойства с приватным setter. Код не компилируется: `private set` запрещает изменять свойство даже методам класса. Она выведет `3`: свойство читается снаружи, а его setter доступен только внутри класса. Она выведет `0`, потому что `value += delta` вызывает недоступный setter. Код не компилируется без явного getter.

Вопрос 20 из 20

Какое правило определяет поведение фрагмента «Границы internal и private»?

// На ревью требуется объяснить причину поведения.
internal class Parser {
    private fun clean(s: String) = s.trim()
    fun parse(s: String): Int = clean(s).toInt()
}

fun main() = println(Parser().parse(" 42 "))

Семантика фрагмента приводит к тому, что код не компилируется: публичный метод не может вызывать private-метод. Причина результата в том, что код не компилируется, потому что `internal` доступен только внутри файла. `private` ограничивает файл или класс, `internal` — модуль компиляции, а `protected` в Kotlin не даёт пакетного доступа. Причину поведения формулируют так: Возникнет `IllegalAccessError`, когда JVM увидит internal-класс. Контракт здесь понимают так: Будет выведено `0`, поскольку `clean` недоступен точке входа.