Наследование и интерфейсы — бесплатный тест онлайн

Вопрос 1 из 20

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

Проверить соседний случай: Код не компилируется, потому что интерфейс не может объявлять свойства. Добавить регрессию на гипотезу: Она напечатает `null:tag`, поскольку интерфейсное свойство не хранит значения. Считать опасной границей ситуацию, где возникнет конфликт реализаций между `name` и `tag`. Отдельно проверить предположение, что код не компилируется: Kotlin поддерживает только один интерфейс на класс. Если два интерфейса дают одну реализацию с одинаковой сигнатурой, класс обязан разрешить конфликт явным `override` и `super<...>`.

Вопрос 2 из 20

В «Шаблонный метод в abstract class» выбрали решение: Выбирать абстрактный класс, когда реализации действительно делят состояние или жизненный цикл, а не только сигнатуры операций. Какова его реальная цена?

Главная цена решения — необходимость учитывать, что будет выведено `0`, так как `value()` в Metric не имеет тела. Граница полезности решения описывается условием: Возникнет `AbstractMethodError` при вызове `doubled`. Общая реализация сокращает дублирование, но одиночное наследование жёстче связывает модель, чем композиция с интерфейсом. Главный риск формулируют так: Код не компилируется без конструктора в Metric. Сопровождение усложнится, если окажется, что код не компилируется, потому что абстрактный класс не может иметь конкретных методов.

Вопрос 3 из 20

Что в семантике Kotlin или используемого API объясняет «Динамический доступ к open-свойству»?

// На ревью требуется объяснить причину поведения.
open class Base {
    open val name: String = "base"
    fun label() = "[$name]"
}
class Child : Base() {
    override val name = "child"
}
fun main() = println(Child().label())

Механика примера описывается утверждением: Будет выведено `[base]`, потому что непереопределённый метод фиксирует свойства Base. Причина результата в том, что код не компилируется: свойства нельзя делать `open`. Классы и члены закрыты для наследования по умолчанию; динамический вызов применяется только к явно `open` или абстрактным членам. Поведение связывают с правилом: Возникнет ошибка доступа к `name` из метода базового класса. Контракт здесь понимают так: Будет выведено `[null]`, поскольку поле Child ещё не создано после конструктора.

Вопрос 4 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
open class Formatter {
    open fun format(x: Int): String = "n=$x"
}
class HexFormatter : Formatter() {
    override fun format(x: Int): String = x.toString(16)
}
fun main() {
    val f: Formatter = HexFormatter()
    println(f.format(31))
}

Добавить локальную обработку результата, потому что будет выведено `31`, поскольку `override` сохраняет реализацию базового метода. Передать ответственность владельцу вызова, предполагая, что будет выведено `n=31`, потому что переменная имеет тип Formatter. Ограничиться поясняющим комментарием о том, что возникнет `ClassCastException` при виртуальном вызове. Сохранять предусловия и смысл базового контракта, а отличия поведения проверять тестами через ссылку базового типа. Зафиксировать текущее поведение регрессионным тестом: Код не компилируется без `open` у класса HexFormatter.

Вопрос 5 из 20

Чем завершится выполнение «Шаблонный метод в abstract class»?

// Проследите фактическое выполнение без изменения кода.
abstract class Metric {
    abstract fun value(): Int
    fun doubled() = value() * 2
}
class Fixed(private val n: Int) : Metric() {
    override fun value() = n
}
fun main() = println(Fixed(6).doubled())

Будет выведено `0`, так как `value()` в Metric не имеет тела. Код не компилируется без конструктора в Metric. Будет `12`: метод базового класса вызовет реализацию абстрактного метода потомка. Возникнет `AbstractMethodError` при вызове `doubled`. Код не компилируется, потому что абстрактный класс не может иметь конкретных методов.

Вопрос 6 из 20

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

// Сохраните назначение фрагмента, но укрепите его контракт.
open class Base {
    open val name: String = "base"
    fun label() = "[$name]"
}
class Child : Base() {
    override val name = "child"
}
fun main() = println(Child().label())

Вынести участок в отдельный метод, считая верным следующее: Возникнет ошибка доступа к `name` из метода базового класса. Открывать для переопределения небольшой документированный контракт, а не весь класс ради единичного варианта поведения. Перенести проверку в вызывающий код, исходя из того, что будет выведено `[base]`, потому что непереопределённый метод фиксирует свойства Base. Оставить реализацию без изменений и закрепить тестом предположение: Код не компилируется: свойства нельзя делать `open`. Оставить структуру прежней, документировав утверждение: Будет выведено `[null]`, поскольку поле Child ещё не создано после конструктора.

Вопрос 7 из 20

На каком входе или состоянии граница «Виртуальный вызов override» становится заметной?

Добавить регрессию на гипотезу: Будет выведено `n=31`, потому что переменная имеет тип Formatter. Зафиксировать сценарий, где ожидается: Будет выведено `31`, поскольку `override` сохраняет реализацию базового метода. Проверить, сохраняется ли контракт, когда возникнет `ClassCastException` при виртуальном вызове. Проверить крайний ввод, при котором код не компилируется без `open` у класса HexFormatter. Параметры по умолчанию выбираются по статически видимому объявлению, даже когда тело метода выбирается динамически.

Вопрос 8 из 20

Какой риск не исчезает после правки «Свойство и реализация интерфейса»: Разделять небольшие ролевые интерфейсы и не заставлять реализации зависеть от методов, которые им не нужны?

Интерфейсы уменьшают связь с реализацией, но слишком мелкая нарезка контрактов усложняет навигацию и конфигурацию зависимостей. Цена упрощения проявится, если она напечатает `null:tag`, поскольку интерфейсное свойство не хранит значения. Граница полезности решения описывается условием: Код не компилируется, потому что интерфейс не может объявлять свойства. Главный риск формулируют так: Код не компилируется: Kotlin поддерживает только один интерфейс на класс. Практическое ограничение подхода: Возникнет конфликт реализаций между `name` и `tag`.

Вопрос 9 из 20

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

Проверить границу полезности утверждения: Возникнет ошибка доступа к `name` из метода базового класса. Воспроизвести редкий сценарий, где код не компилируется: свойства нельзя делать `open`. Отдельно воспроизвести случай, в котором будет выведено `[base]`, потому что непереопределённый метод фиксирует свойства Base. Вызов open-свойства из конструктора базового класса может обратиться к ещё не инициализированному состоянию подкласса. Проверить соседний случай: Будет выведено `[null]`, поскольку поле Child ещё не создано после конструктора.

Вопрос 10 из 20

Какую обратную сторону имеет решение для «Виртуальный вызов override»: Сохранять предусловия и смысл базового контракта, а отличия поведения проверять тестами через ссылку базового типа?

Решение оправдано лишь при условии: Возникнет `ClassCastException` при виртуальном вызове. Компромисс состоит в утверждении: Код не компилируется без `open` у класса HexFormatter. Практическое ограничение подхода: Будет выведено `n=31`, потому что переменная имеет тип Formatter. Новый риск связан с тем, что будет выведено `31`, поскольку `override` сохраняет реализацию базового метода. Явный `override` защищает от случайного совпадения имён, но глубокая иерархия всё равно затрудняет поиск фактического поведения.

Вопрос 11 из 20

Чем завершится выполнение «Свойство и реализация интерфейса»?

// Проследите фактическое выполнение без изменения кода.
interface Named { val name: String }
interface Tagged { fun tag() = "tag" }
class Item(override val name: String) : Named, Tagged
fun main() = println(Item("book").name + ":" + Item("book").tag())

Она напечатает `book:tag`: класс реализует свойство одного интерфейса и наследует реализацию метода другого. Она напечатает `null:tag`, поскольку интерфейсное свойство не хранит значения. Код не компилируется, потому что интерфейс не может объявлять свойства. Возникнет конфликт реализаций между `name` и `tag`. Код не компилируется: Kotlin поддерживает только один интерфейс на класс.

Вопрос 12 из 20

Какой контракт снимает спор о причине поведения «Шаблонный метод в abstract class»?

// На ревью требуется объяснить причину поведения.
abstract class Metric {
    abstract fun value(): Int
    fun doubled() = value() * 2
}
class Fixed(private val n: Int) : Metric() {
    override fun value() = n
}
fun main() = println(Fixed(6).doubled())

Семантика фрагмента приводит к тому, что возникнет `AbstractMethodError` при вызове `doubled`. Из правил языка или API следует, что код не компилируется, потому что абстрактный класс не может иметь конкретных методов. Поведение связывают с правилом: Код не компилируется без конструктора в Metric. Причина результата в том, что будет выведено `0`, так как `value()` в Metric не имеет тела. Абстрактный класс может хранить состояние, иметь конструктор и частичную реализацию; создать его экземпляр напрямую нельзя.

Вопрос 13 из 20

Как поведёт себя фрагмент «Виртуальный вызов override» при указанных входных данных?

// Проследите фактическое выполнение без изменения кода.
open class Formatter {
    open fun format(x: Int): String = "n=$x"
}
class HexFormatter : Formatter() {
    override fun format(x: Int): String = x.toString(16)
}
fun main() {
    val f: Formatter = HexFormatter()
    println(f.format(31))
}

Будет выведено `n=31`, потому что переменная имеет тип Formatter. Возникнет `ClassCastException` при виртуальном вызове. Будет выведено `1f`: выбор переопределённого метода идёт по фактическому объекту `HexFormatter`. Код не компилируется без `open` у класса HexFormatter. Будет выведено `31`, поскольку `override` сохраняет реализацию базового метода.

Вопрос 14 из 20

Почему поведение «Свойство и реализация интерфейса» не является случайностью?

// На ревью требуется объяснить причину поведения.
interface Named { val name: String }
interface Tagged { fun tag() = "tag" }
class Item(override val name: String) : Named, Tagged
fun main() = println(Item("book").name + ":" + Item("book").tag())

Наблюдаемое поведение выводят из того, что код не компилируется: Kotlin поддерживает только один интерфейс на класс. Здесь действует следующее правило: Она напечатает `null:tag`, поскольку интерфейсное свойство не хранит значения. Такой результат объясняют тем, что возникнет конфликт реализаций между `name` и `tag`. Интерфейс задаёт абстрактные члены и реализации без собственного backing field; класс может реализовать несколько интерфейсов. Объяснение опирается на утверждение: Код не компилируется, потому что интерфейс не может объявлять свойства.

Вопрос 15 из 20

Какая правка устраняет причину риска в «Шаблонный метод в abstract class», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
abstract class Metric {
    abstract fun value(): Int
    fun doubled() = value() * 2
}
class Fixed(private val n: Int) : Metric() {
    override fun value() = n
}
fun main() = println(Fixed(6).doubled())

Спрятать участок за вспомогательной функцией, сохранив предположение: Код не компилируется, потому что абстрактный класс не может иметь конкретных методов. Оставить реализацию без изменений и закрепить тестом предположение: Код не компилируется без конструктора в Metric. Выбирать абстрактный класс, когда реализации действительно делят состояние или жизненный цикл, а не только сигнатуры операций. Добавить защитную проверку перед фрагментом, поскольку будет выведено `0`, так как `value()` в Metric не имеет тела. Перенести проверку в вызывающий код, исходя из того, что возникнет `AbstractMethodError` при вызове `doubled`.

Вопрос 16 из 20

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

Обратная сторона изменения состоит в том, что код не компилируется: свойства нельзя делать `open`. Сопровождение усложнится, если окажется, что возникнет ошибка доступа к `name` из метода базового класса. Наследование удобно для устойчивого полиморфного контракта, но увеличивает число неявных связей между базовым классом и потомками. После правки останется ограничение: Будет выведено `[null]`, поскольку поле Child ещё не создано после конструктора. Решение оправдано лишь при условии: Будет выведено `[base]`, потому что непереопределённый метод фиксирует свойства Base.

Вопрос 17 из 20

Какое изменение лучше всего защищает границу «Свойство и реализация интерфейса»?

// Сохраните назначение фрагмента, но укрепите его контракт.
interface Named { val name: String }
interface Tagged { fun tag() = "tag" }
class Item(override val name: String) : Named, Tagged
fun main() = println(Item("book").name + ":" + Item("book").tag())

Передать ответственность владельцу вызова, предполагая, что код не компилируется, потому что интерфейс не может объявлять свойства. Разделять небольшие ролевые интерфейсы и не заставлять реализации зависеть от методов, которые им не нужны. Сохранить API и считать достаточным условие: Она напечатает `null:tag`, поскольку интерфейсное свойство не хранит значения. Ограничиться поясняющим комментарием о том, что возникнет конфликт реализаций между `name` и `tag`. Добавить локальную обработку результата, потому что код не компилируется: Kotlin поддерживает только один интерфейс на класс.

Вопрос 18 из 20

Где упрощённое объяснение «Шаблонный метод в abstract class» перестаёт работать?

Абстрактный член может быть переопределён ещё раз как абстрактный в промежуточном абстрактном подклассе. Проверить границу полезности утверждения: Возникнет `AbstractMethodError` при вызове `doubled`. Добавить граничный тест на утверждение: Код не компилируется, потому что абстрактный класс не может иметь конкретных методов. Отдельно воспроизвести случай, в котором будет выведено `0`, так как `value()` в Metric не имеет тела. Добавить тест на состояние, при котором код не компилируется без конструктора в Metric.

Вопрос 19 из 20

Чем завершится выполнение «Динамический доступ к open-свойству»?

// Проследите фактическое выполнение без изменения кода.
open class Base {
    open val name: String = "base"
    fun label() = "[$name]"
}
class Child : Base() {
    override val name = "child"
}
fun main() = println(Child().label())

Будет выведено `[null]`, поскольку поле Child ещё не создано после конструктора. Будет выведено `[child]`: `label()` обращается к открытому свойству, и срабатывает переопределение подкласса. Будет выведено `[base]`, потому что непереопределённый метод фиксирует свойства Base. Код не компилируется: свойства нельзя делать `open`. Возникнет ошибка доступа к `name` из метода базового класса.

Вопрос 20 из 20

Почему поведение «Виртуальный вызов override» не является случайностью?

// На ревью требуется объяснить причину поведения.
open class Formatter {
    open fun format(x: Int): String = "n=$x"
}
class HexFormatter : Formatter() {
    override fun format(x: Int): String = x.toString(16)
}
fun main() {
    val f: Formatter = HexFormatter()
    println(f.format(31))
}

Объяснение опирается на утверждение: Будет выведено `n=31`, потому что переменная имеет тип Formatter. `override` обязателен и проверяет совпадение контракта; переопределённый член остаётся открытым, если его не пометить `final`. Здесь действует следующее правило: Будет выведено `31`, поскольку `override` сохраняет реализацию базового метода. Ключевым считают контракт: Возникнет `ClassCastException` при виртуальном вызове. Наблюдаемое поведение выводят из того, что код не компилируется без `open` у класса HexFormatter.