JV Java · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Наследование и полиморфизм

Проверяет основу темы «Наследование и полиморфизм» через чтение кода, предсказание результата и выбор корректной конструкции. Вопросы перемешаны: встречаются трассировка, ошибка компиляции, выбор правки, граничный сценарий и оценка инженерного компромисса. Базовая версия — Java 25 LTS; если версия не названа отдельно, используются устойчивые правила, совместимые с Java 21.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант; близкие ответы различаются стадией ошибки, порядком действий или границей контракта. После завершения вы увидите общий результат, результаты по 4 тематическим шкалам и объяснения.

Вопрос 1 из 20

Как поведёт себя фрагмент по теме «Динамический вызов» при разборе раздела «Наследование и полиморфизм»?

class Parent { String name() { return "parent"; } }
class Child extends Parent { String name() { return "child"; } }
Parent p = new Child();
System.out.println(p.name());

Класс Child не компилируется: неявный super() отсутствует, потому что у Parent есть только конструктор с параметром. Через ссылку Parent вызывается Child.name(), поэтому выводится "child". Приведение объекта Cat к Dog компилируется через общий тип Animal, но падает во время выполнения. static reset() не может напрямую обратиться к нестатическому полю value, поэтому код не компилируется. Метод Child.value() переопределяет базовый и возвращает Integer, что допустимо как подтип Number.

Вопрос 2 из 20

Как поведёт себя фрагмент по теме «Безопасное приведение» при разборе раздела «Наследование и полиморфизм»?

interface Animal {}
class Cat implements Animal {}
class Dog implements Animal {}
Animal a = new Cat();
Dog d = (Dog) a;

Приведение объекта Cat к Dog компилируется через общий тип Animal, но падает на этапе компиляции. Через ссылку Parent вызывается Child.name(), поэтому выводится "child". Приведение объекта Cat к Dog компилируется через общий тип Animal, но падает во время выполнения. Класс C не компилируется, пока не переопределит name() и не выберет или не объединит поведение. Приведение объекта Cat к Dog не компилируется через общий тип Animal, но падает во время выполнения.

Вопрос 3 из 20

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

// Фрагмент на ревью
class Parent { Parent(int id) {} }
class Child extends Parent {
    Child() {}
}

Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Держать в абстрактном классе только состояние, действительно общее для всех наследников, и защищать его инварианты. Использовать полиморфный метод или сопоставление с образцом через instanceof, если поведение действительно зависит от подтипа.

Вопрос 4 из 20

Что нужно отдельно проверить на границе контракта «Переопределение» в разделе «Наследование и полиморфизм»?

Поля и static-методы не полиморфны: их выбор зависит от типа ссылки или места обращения. Нельзя сузить доступность переопределяемого метода или добавить более широкое unchecked-исключение. Вызов переопределяемого метода из конструктора базового класса опасен: поля наследника ещё могут быть не инициализированы. private-члены существуют в объекте базовой части, но недоступны наследнику напрямую. Нельзя сузить доступность переопределяемого метода или добавить более широкое checked-исключение.

Вопрос 5 из 20

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

Интерфейс описывает доступное поведение; реализация обязана соблюдать не только сигнатуру, но и смысловой контракт. Приведение ссылки проверяется во время выполнения и выбрасывает ClassCastException при несовместимом фактическом типе. Приведение ссылки проверяется на этапе компиляции и выбрасывает ClassCastException при несовместимом фактическом типе. Приведение ссылки проверяется во время выполнения и выбрасывает ArrayStoreException при несовместимом фактическом типе. Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения.

Вопрос 6 из 20

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

class Parent { Number value() { return 1; } }
class Child extends Parent {
    @Override Integer value() { return 2; }
}
System.out.println(new Child().value());

Метод Child.value() переопределяет базовый и возвращает String, что допустимо как подтип Number. Метод Child.value() переопределяет базовый и не возвращает Integer, что допустимо как подтип Number. Конструктор Base вызывается при создании Child и инициализирует общее поле id. Метод Child.value() переопределяет базовый и возвращает Integer, что допустимо как подтип Number. Класс Child не компилируется: неявный super() отсутствует, потому что у Parent есть только конструктор с параметром.

Вопрос 7 из 20

Что важно учитывать при применении механизма «Безопасное приведение» из раздела «Наследование и полиморфизм» в рабочем проекте?

Default полезен для совместимой эволюции API, но состояние и сложную предметную логику лучше не прятать в интерфейсе. Узкий контракт облегчает замену реализации, но слишком общий интерфейс переносит ошибки из компиляции во время выполнения. Приведение иногда нужно на границах старого API, но частые cast обычно показывают, что модель типов не выражает нужный контракт. Динамический вызов делает расширение естественным, но усложняет локальное чтение, если иерархия глубокая и контракт размыт. Наследование полезно для отношения «является», а повторное использование кода без подстановочности лучше решать композицией.

Вопрос 8 из 20

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

// Минимальный пример
class Parent { String name() { return "parent"; } }
class Child extends Parent { String name() { return "child"; } }
Parent p = new Child();
System.out.println(p.name());

Проверка instanceof для null возвращает false и не выбрасывает исключение. Поля и static-методы не полиморфны: их выбор зависит от типа ссылки или места обращения. Нельзя сузить доступность переопределяемого метода или добавить более широкое checked-исключение. Статическое поле разделяется всеми экземплярами и может стать скрытым глобальным состоянием. private-члены существуют в объекте базовой части, но недоступны наследнику напрямую.

Вопрос 9 из 20

Как поведёт себя фрагмент по теме «Наследование через extends» при разборе раздела «Наследование и полиморфизм»?

class Parent { Parent(int id) {} }
class Child extends Parent {
    Child() {}
}

Конструктор без аргументов делегирует другому конструктору и создаёт объект с именем "guest". Класс Child не компилируется: неявный super() отсутствует, потому что у Parent есть только конструктор с параметром. Через ссылку Parent вызывается Child.name(), поэтому выводится "child". Приведение объекта Cat к Dog компилируется через общий тип Animal, но падает во время выполнения. Метод Child.value() переопределяет базовый и возвращает Integer, что допустимо как подтип Number.

Вопрос 10 из 20

Какое утверждение о механизме «Наследование через extends» верно в контексте раздела «Наследование и полиморфизм»?

Переопределяющий метод должен сохранять совместимую сигнатуру; возвращаемый ссылочный тип может быть ковариантным. Приведение ссылки проверяется во время выполнения и выбрасывает ClassCastException при несовместимом фактическом типе. Наследник получает доступное поведение базового класса, но конструкторы не наследуются. Вызов this(...) или super(...) должен быть первым оператором конструктора. Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения.

Вопрос 11 из 20

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

// Фрагмент на ревью
class Parent { String name() { return "parent"; } }
class Child extends Parent { String name() { return "child"; } }
Parent p = new Child();
System.out.println(p.name());

Сделать reset методом экземпляра либо передавать объект явно. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов. Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения. Использовать полиморфный метод или сопоставление с образцом через instanceof, если поведение действительно зависит от подтипа.

Вопрос 12 из 20

Какой инженерный компромисс характерен для темы «Наследование через extends» в разделе «Наследование и полиморфизм»?

Динамический вызов делает расширение естественным, но усложняет локальное чтение, если иерархия глубокая и контракт размыт. Приведение иногда нужно на границах старого API, но частые cast обычно показывают, что модель типов не выражает нужный контракт. Наследование полезно для отношения «является», а повторное использование кода без подстановочности лучше решать композицией. Переопределение даёт полиморфизм, но контракт базового типа важнее удобства отдельного наследника. Общий базовый код сокращает дублирование, но связывает классы одной иерархией и усложняет независимую эволюцию.

Вопрос 13 из 20

Какое изменение сделает код по теме «Безопасное приведение» в разделе «Наследование и полиморфизм» надёжнее?

// Фрагмент на ревью
interface Animal {}
class Cat implements Animal {}
class Dog implements Animal {}
Animal a = new Cat();
Dog d = (Dog) a;

Сравнивать содержимое через equals, а intern использовать только при осознанном управлении множеством повторяющихся строк. Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Использовать полиморфный метод или сопоставление с образцом через instanceof, если поведение действительно зависит от подтипа. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов.

Вопрос 14 из 20

Какое ограничение механизма «Безопасное приведение» нельзя упускать при работе с разделом «Наследование и полиморфизм»?

// ...
class Dog implements Animal {}
Animal a = new Cat();
Dog d = (Dog) a;

Проверка instanceof для null не возвращает false и не выбрасывает исключение. Проверка instanceof для null возвращает false и не выбрасывает исключение. Статическое поле разделяется всеми экземплярами и может стать скрытым глобальным состоянием. Проверка только в конструкторе недостаточна, если наружу возвращается изменяемая коллекция или массив. Проверка instanceof для null возвращает true и не выбрасывает исключение.

Вопрос 15 из 20

Что нужно отдельно проверить на границе контракта «Наследование через extends» в разделе «Наследование и полиморфизм»?

Нельзя сузить доступность переопределяемого метода или добавить более широкое checked-исключение. Проверка instanceof для null возвращает false и не выбрасывает исключение. private-члены существуют в объекте базовой части, но недоступны наследнику напрямую. Если объявлен любой конструктор, компилятор не добавляет неявный конструктор без аргументов. Поля и static-методы не полиморфны: их выбор зависит от типа ссылки или места обращения.

Вопрос 16 из 20

Что важно учитывать при применении механизма «Динамический вызов» из раздела «Наследование и полиморфизм» в рабочем проекте?

Static уместен для чистых служебных операций и общих констант, но не для маскировки состояния конкретного объекта. Динамический вызов делает расширение естественным, но усложняет локальное запись, если иерархия глубокая и контракт размыт. Приведение иногда нужно на границах старого API, но частые cast обычно показывают, что модель типов не выражает нужный контракт. Динамический вызов делает расширение естественным, но усложняет локальное чтение, если иерархия глубокая и контракт размыт. Переопределение даёт полиморфизм, но контракт базового типа важнее удобства отдельного наследника.

Вопрос 17 из 20

Какое изменение сделает код по теме «Переопределение» в разделе «Наследование и полиморфизм» надёжнее?

// Фрагмент на ревью
class Parent { Number value() { return 1; } }
class Child extends Parent {
    @Override Integer value() { return 2; }
}
System.out.println(new Child().value());

Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения. Изменить имя, набор параметров или объединить поведение в один метод с ясным контрактом. Использовать полиморфный метод или сопоставление с образцом через instanceof, если поведение действительно зависит от подтипа. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов.

Вопрос 18 из 20

Какой инженерный компромисс характерен для темы «Переопределение» в разделе «Наследование и полиморфизм»?

Переопределение даёт полиморфизм, но контракт базового типа важнее удобства отдельного наследника. Наследование полезно для отношения «является», а повторное использование кода без подстановочности лучше решать композицией. Динамический вызов делает расширение естественным, но усложняет локальное чтение, если иерархия глубокая и контракт размыт. Композиция добавляет слой делегирования, зато позволяет менять реализацию и ограничивать поверхность API. Приведение иногда нужно на границах старого API, но частые cast обычно показывают, что модель типов не выражает нужный контракт.

Вопрос 19 из 20

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

Приведение ссылки проверяется во время выполнения и выбрасывает ClassCastException при несовместимом фактическом типе. Метод экземпляра работает с состоянием конкретного объекта, а static-метод не имеет неявной ссылки this. Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения. Переопределённый метод экземпляра выбирается по фактическому классу объекта на этапе компиляции. Переопределённый метод экземпляра выбирается по объявленному типу объекта во время выполнения.

Вопрос 20 из 20

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

Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения. Наследник получает доступное поведение базового класса, но конструкторы не наследуются. Переопределяющий метод должен сохранять совместимую сигнатуру; возвращаемый ссылочный тип может быть ковариантным. Сигнатура метода включает имя и типы параметров, но не возвращаемый тип. Переопределяющий метод должен сохранять совместимую сигнатуру; возвращаемый ссылочный тип может быть инвариантным.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу