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

Интерфейсы и абстрактные классы

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

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

⏱ --:--

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

Вопрос 1 из 20

Какое утверждение о механизме «Абстрактное состояние» верно в контексте раздела «Интерфейсы и абстрактные классы»?

Композиция предпочтительнее, когда объект использует поведение другого объекта, но не обязан быть его подтипом. Наследник получает доступное поведение базового класса, но конструкторы не наследуются. Интерфейс описывает доступное поведение; реализация обязана соблюдать не только сигнатуру, но и смысловой контракт. Абстрактный класс может хранить состояние и частичную реализацию, а интерфейс задаёт множественно реализуемый контракт. default-метод позволяет развивать интерфейс, но конфликт одинаковых default-методов из двух интерфейсов надо разрешить явно.

Вопрос 2 из 20

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

// ...
    @Override public boolean add(String s) {
        System.out.println("add " + s);
        return super.add(s);
    }
}

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

Вопрос 3 из 20

Какое утверждение о механизме «Контракты» верно в контексте раздела «Интерфейсы и абстрактные классы»?

Интерфейс описывает доступное поведение; реализация обязана соблюдать не только сигнатуру, но и смысловой контракт. Интерфейс описывает доступное поведение; реализация не обязана соблюдать не только сигнатуру, но и смысловой контракт. Композиция предпочтительнее, когда объект использует поведение другого объекта, но не обязан быть его подтипом. default-метод позволяет развивать интерфейс, но конфликт одинаковых default-методов из двух интерфейсов надо разрешить явно. Наследник получает доступное поведение базового класса, но конструкторы не наследуются.

Вопрос 4 из 20

Какое утверждение о механизме «Выбор механизма» верно в контексте раздела «Интерфейсы и абстрактные классы»?

default-метод позволяет развивать интерфейс, но конфликт одинаковых default-методов из двух интерфейсов надо разрешить явно. Композиция предпочтительнее, когда объект использует поведение другого объекта, но не обязан быть его подтипом. Интерфейс описывает доступное поведение; реализация обязана соблюдать не только сигнатуру, но и смысловой контракт. Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения. Абстрактный класс может хранить состояние и частичную реализацию, а интерфейс задаёт множественно реализуемый контракт.

Вопрос 5 из 20

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

// Фрагмент на ревью
class BadComparator implements java.util.Comparator<Integer> {
    public int compare(Integer a, Integer b) { return a.equals(b) ? 0 : 1; }
}

Переопределить конфликтующий метод и при необходимости вызвать A.super.name() или B.super.name(). Обернуть List в отдельный класс и делегировать только нужные операции. Держать в абстрактном классе только состояние, действительно общее для всех наследников, и защищать его инварианты. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Сформулировать законы контракта и проверить их на наборах значений, а не ограничиваться наличием метода.

Вопрос 6 из 20

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

// Фрагмент на ревью
abstract class Base {
    final int id;
    Base(int id) { this.id = id; }
}
class Child extends Base { Child() { super(42); } }
System.out.println(new Child().id);

Переопределить конфликтующий метод и при необходимости вызвать A.super.name() или B.super.name(). Держать в абстрактном классе только состояние, действительно общее для всех наследников, и защищать его инварианты. Сформулировать законы контракта и проверить их на наборах значений, а не ограничиваться наличием метода. Обернуть List в отдельный класс и делегировать только нужные операции. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов.

Вопрос 7 из 20

Какое изменение сделает код по теме «Методы по умолчанию» в разделе «Интерфейсы и абстрактные классы» надёжнее?

// Фрагмент на ревью
interface A { default String name() { return "A"; } }
interface B { default String name() { return "B"; } }
class C implements A, B {}

Обернуть List в отдельный класс и делегировать только нужные операции. Сформулировать законы контракта и проверить их на наборах значений, а не ограничиваться наличием метода. Переопределить конфликтующий метод и при необходимости вызвать A.super.name() или B.super.name(). Держать в абстрактном классе только состояние, действительно общее для всех наследников, и защищать его инварианты. Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения.

Вопрос 8 из 20

Какой недостаток проектирования есть у такого способа добавить журналирование?

class LoggingNames extends java.util.ArrayList<String> {
    @Override public boolean add(String s) {
        System.out.println("add " + s);
        return super.add(s);
    }
}

Наследование LinkedList только ради журналирования add раскрывает десятки нежелательных операций и хрупко зависит от реализации. Класс C не компилируется, пока не переопределит name() и не выберет или не объединит поведение. Наследование ArrayList только ради журналирования add раскрывает десятки нежелательных операций и хрупко зависит от реализации. Класс компилируется, но реализация compare нарушает антисимметричность и может ломать сортировку. Конструктор Base вызывается при создании Child и инициализирует общее поле id.

Вопрос 9 из 20

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

Узкий контракт облегчает замену реализации, но слишком общий интерфейс переносит ошибки из компиляции во время выполнения. Узкий контракт облегчает замену реализации, но слишком общий интерфейс переносит ошибки из компиляции на этапе компиляции. Общий базовый код сокращает дублирование, но связывает классы одной иерархией и усложняет независимую эволюцию. Интернирование уменьшает дубли строк, но переносит их в глобальный пул и может увеличить удерживаемую память. Обёртки нужны для обобщённых коллекций и состояний, допускающих null, но создают риск распаковки null, лишних объектов и ошибочного сравнения по ссылке.

Вопрос 10 из 20

Что нужно отдельно проверить на границе контракта «Абстрактное состояние» в разделе «Интерфейсы и абстрактные классы»?

// ...
}
class Child extends Base { Child() { super(42); } }
System.out.println(new Child().id);

Нельзя сузить доступность переопределяемого метода или добавить более широкое checked-исключение. Компилятор не доказывает идемпотентность, монотонность или другие смысловые свойства интерфейса. Метод класса имеет приоритет над default-методом интерфейса. Интерфейс не решает проблему автоматически: важны минимальный набор методов и корректная подстановочность. Вызов переопределяемого метода из конструктора базового класса опасен: поля наследника ещё могут быть не инициализированы.

Вопрос 11 из 20

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

Композиция добавляет слой делегирования, зато не позволяет менять реализацию и ограничивать поверхность API. Общий базовый код сокращает дублирование, но связывает классы одной иерархией и усложняет независимую эволюцию. Композиция удаляет слой делегирования, зато позволяет менять реализацию и ограничивать поверхность API. Default полезен для совместимой эволюции API, но состояние и сложную предметную логику лучше не прятать в интерфейсе. Композиция добавляет слой делегирования, зато позволяет менять реализацию и ограничивать поверхность API.

Вопрос 12 из 20

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

Static уместен для чистых служебных операций и общих констант, но не для маскировки состояния конкретного объекта. Композиция добавляет слой делегирования, зато позволяет менять реализацию и ограничивать поверхность API. Узкий контракт облегчает замену реализации, но слишком общий интерфейс переносит ошибки из компиляции во время выполнения. Default полезен для совместимой эволюции API, но состояние и сложную предметную логику лучше не прятать в интерфейсе. Общий базовый код сокращает дублирование, но связывает классы одной иерархией и усложняет независимую эволюцию.

Вопрос 13 из 20

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

abstract class Base {
    final int id;
    Base(int id) { this.id = id; }
}
class Child extends Base { Child() { super(42); } }
System.out.println(new Child().id);

Наследование ArrayList только ради журналирования add раскрывает десятки нежелательных операций и хрупко зависит от реализации. Конструктор Base вызывается при создании Child и инициализирует общее поле id. Класс компилируется, но реализация compare нарушает антисимметричность и может ломать сортировку. Через ссылку Parent вызывается Child.name(), поэтому выводится "child". Класс C не компилируется, пока не переопределит name() и не выберет или не объединит поведение.

Вопрос 14 из 20

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

Композиция предпочтительнее, когда объект использует поведение другого объекта, но не обязан быть его подтипом. default-метод позволяет развивать интерфейс, но конфликт одинаковых default-методов из двух интерфейсов надо разрешить явно. default-метод не позволяет развивать интерфейс, но конфликт одинаковых default-методов из двух интерфейсов надо разрешить явно. Интерфейс описывает доступное поведение; реализация обязана соблюдать не только сигнатуру, но и смысловой контракт. Абстрактный класс может хранить состояние и частичную реализацию, а интерфейс задаёт множественно реализуемый контракт.

Вопрос 15 из 20

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

Вызов переопределяемого метода из конструктора базового класса опасен: поля наследника ещё могут быть не инициализированы. Метод класса имеет приоритет над default-методом интерфейса. Интерфейс не решает проблему автоматически: важны минимальный набор методов и корректная подстановочность. Компилятор не доказывает идемпотентность, монотонность или другие смысловые свойства интерфейса. Кэш Integer обязателен как минимум для диапазона -128..127, но реализация может расширять его.

Вопрос 16 из 20

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

Интерфейс не решает проблему автоматически: важны минимальный набор методов и корректная подстановочность. private-члены существуют в объекте базовой части, но недоступны наследнику напрямую. Метод класса имеет приоритет над default-методом интерфейса. Вызов переопределяемого метода из конструктора базового класса опасен: поля наследника ещё могут быть не инициализированы. Компилятор не доказывает идемпотентность, монотонность или другие смысловые свойства интерфейса.

Вопрос 17 из 20

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

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

Вопрос 18 из 20

Какое изменение сделает код по теме «Выбор механизма» в разделе «Интерфейсы и абстрактные классы» надёжнее?

// Фрагмент на ревью
class LoggingNames extends java.util.ArrayList<String> {
    @Override public boolean add(String s) {
        System.out.println("add " + s);
        return super.add(s);
    }
}

Обернуть List в отдельный класс и делегировать только нужные операции. Переопределить конфликтующий метод и при необходимости вызвать A.super.name() или B.super.name(). Держать в абстрактном классе только состояние, действительно общее для всех наследников, и защищать его инварианты. Использовать Objects.equals(a, b), если допустимы null с обеих сторон. Сформулировать законы контракта и проверить их на наборах значений, а не ограничиваться наличием метода.

Вопрос 19 из 20

Что произойдёт с кодом по теме «Контракты» в разделе «Интерфейсы и абстрактные классы»?

class BadComparator implements java.util.Comparator<Integer> {
    public int compare(Integer a, Integer b) { return a.equals(b) ? 0 : 1; }
}

Наследование ArrayList только ради журналирования add раскрывает десятки нежелательных операций и хрупко зависит от реализации. Класс не компилируется, но реализация compare нарушает антисимметричность и может ломать сортировку. Конструктор Base вызывается при создании Child и инициализирует общее поле id. Класс компилируется, но реализация compare нарушает антисимметричность и может ломать сортировку. Класс C не компилируется, пока не переопределит name() и не выберет или не объединит поведение.

Вопрос 20 из 20

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

interface A { default String name() { return "A"; } }
interface B { default String name() { return "B"; } }
class C implements A, B {}

Наследование ArrayList только ради журналирования add раскрывает десятки нежелательных операций и хрупко зависит от реализации. Конструктор Base вызывается при создании Child и инициализирует общее поле id. Класс C не компилируется, пока не переопределит name() и не выберет или не объединит поведение. Метод Child.value() переопределяет базовый и возвращает Integer, что допустимо как подтип Number. Класс компилируется, но реализация compare нарушает антисимметричность и может ломать сортировку.

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

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

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

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