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

Классы и инкапсуляция

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

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

⏱ --:--

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

Вопрос 1 из 20

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

// Фрагмент на ревью
class Counter {
    private int value;
    static void reset() { value = 0; }
}

Сделать reset методом экземпляра либо передавать объект явно. Заменить общий setter предметными операциями с проверкой допустимого перехода состояния. Собрать проверку инвариантов в одном основном конструкторе, а остальные использовать как делегирующие. Определять полиморфное поведение в методах экземпляра, а не пытаться получить его через скрытие static-методов. Скрыть поле и предоставить операцию предметного уровня вместо расширения видимости.

Вопрос 2 из 20

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

class Counter {
    private int value;
    static void reset() { value = 0; }
}

Класс из другого пакета, не являющийся наследником, не может обратиться к protected-полю через обычную ссылку. static reset() не может напрямую обратиться к нестатическому полю value, поэтому код не компилируется. Через ссылку Parent вызывается Child.name(), поэтому выводится "child". Сеттер позволяет получить отрицательный баланс и разрушает условие, на котором опирается withdraw. Конструктор без аргументов делегирует другому конструктору и создаёт объект с именем "guest".

Вопрос 3 из 20

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

Переопределённый метод экземпляра выбирается по фактическому классу объекта во время выполнения. private ограничивает доступ самим классом, package-private — пакетом, protected добавляет доступ наследникам с особыми правилами. Инвариант должен выполняться после завершения конструктора и каждой публичной операции объекта. Вызов this(...) или super(...) должен быть первым оператором конструктора. Метод экземпляра работает с состоянием конкретного объекта, а static-метод не имеет неявной ссылки this.

Вопрос 4 из 20

Что следует изменить в разделе «Классы и инкапсуляция», чтобы сохранить замысел и соблюсти контракт «Инварианты объекта»?

// Фрагмент на ревью
class Account {
    private int balance;
    void setBalance(int value) { balance = value; }
    void withdraw(int amount) {
        if (amount > balance) throw new IllegalStateException();
        balance -= amount;
    }
}

Собрать проверку инвариантов в одном основном конструкторе, а остальные использовать как делегирующие. Сделать reset методом экземпляра либо передавать объект явно. Возвращать новую ссылку, если метод должен заменить объект у вызывающего кода, либо явно мутировать переданный объект. Заменить общий setter предметными операциями с проверкой допустимого перехода состояния. Скрыть поле и предоставить операцию предметного уровня вместо расширения видимости.

Вопрос 5 из 20

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

// Минимальный пример
class Roster {
    private final java.util.List<String> members = new java.util.ArrayList<>();
    Roster(java.util.List<String> initial) {
        if (initial.isEmpty()) throw new IllegalArgumentException();
        members.addAll(initial);
    }
    java.util.List<String> members() { return members; }
}
var roster = new Roster(java.util.List.of("a"));
roster.members().clear();

Если объявлен любой конструктор, компилятор не добавляет неявный конструктор без аргументов. Проверка только в конструкторе недостаточна, если наружу возвращается изменяемая коллекция или массив. protected не означает «доступно всему проекту» и вне пакета связано с наследованием. Статическое поле разделяется всеми экземплярами и может стать скрытым глобальным состоянием. Изменение элемента переданного массива видно снаружи, потому что обе ссылки указывают на один массив.

Вопрос 6 из 20

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

Если объявлен любой конструктор, компилятор не удаляет неявный конструктор без аргументов. Если объявлен любой конструктор, компилятор не добавляет неявный конструктор без аргументов. Проверка только в конструкторе недостаточна, если наружу возвращается изменяемая коллекция или массив. private-члены существуют в объекте базовой части, но недоступны наследнику напрямую. protected не означает «доступно всему проекту» и вне пакета связано с наследованием.

Вопрос 7 из 20

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

// Фрагмент на ревью
class User {
    final String name;
    User() { this("guest"); }
    User(String name) { this.name = name; }
}
System.out.println(new User().name);

Заменить общий setter предметными операциями с проверкой допустимого перехода состояния. Собрать проверку инвариантов в одном основном конструкторе, а остальные использовать как делегирующие. Сделать reset методом экземпляра либо передавать объект явно. Явно вызвать super(value) первой строкой конструктора наследника и передать корректное значение для инициализации базовой части объекта. Скрыть поле и предоставить операцию предметного уровня вместо расширения видимости.

Вопрос 8 из 20

Какое правило Java действует для темы «Конструкторы» в разделе «Классы и инкапсуляция»?

Метод экземпляра работает с состоянием конкретного объекта, а static-метод не имеет неявной ссылки this. Инвариант должен выполняться после завершения конструктора и каждой публичной операции объекта. Вызов this(...) или super(...) должен быть первым оператором конструктора. Наследник получает доступное поведение базового класса, но конструкторы не наследуются. private ограничивает доступ самим классом, package-private — пакетом, protected добавляет доступ наследникам с особыми правилами.

Вопрос 9 из 20

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

private ограничивает доступ самим классом, package-private — пакетом, protected добавляет доступ наследникам с особыми правилами. Метод экземпляра работает с состоянием конкретного объекта, а static-метод не имеет неявной ссылки this. Вызов this(...) или super(...) должен быть первым оператором конструктора. Перегрузка выбирается на этапе компиляции по объявленным типам аргументов и правилам наиболее специфичного применимого метода. Инвариант должен выполняться после завершения конструктора и каждой публичной операции объекта.

Вопрос 10 из 20

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

class User {
    final String name;
    User() { this("guest"); }
    User(String name) { this.name = name; }
}
System.out.println(new User().name);

Класс Child не компилируется: неявный super() отсутствует, потому что у Parent есть только конструктор с параметром. Конструктор без аргументов делегирует другому конструктору и создаёт объект с именем "guest". Сеттер позволяет получить отрицательный баланс и разрушает условие, на котором опирается withdraw. Конструктор без аргументов делегирует другому конструктору и не создаёт объект с именем "guest". Класс из другого пакета, не являющийся наследником, не может обратиться к protected-полю через обычную ссылку.

Вопрос 11 из 20

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

Static уместен для чистых служебных операций и общих констант, но не для маскировки состояния конкретного объекта. Минимальная видимость сохраняет свободу менять реализацию, но чрезмерные геттеры могут фактически раскрыть весь внутренний объект. Наследование полезно для отношения «является», а повторное использование кода без подстановочности лучше решать композицией. Цепочка конструкторов увеличивает дублирование, но слишком много необязательных параметров лучше выразить фабричным методом или объектом-построителем. Цепочка конструкторов уменьшает дублирование, но слишком много необязательных параметров лучше выразить фабричным методом или объектом-построителем.

Вопрос 12 из 20

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

package api;
public class Base { protected int value = 7; }
// другой пакет:
Base b = new Base();
// ...

Поля и static-методы не полиморфны: их выбор зависит от типа ссылки или места обращения. Проверка только в конструкторе недостаточна, если наружу возвращается изменяемая коллекция или массив. Статическое поле разделяется всеми экземплярами и может стать скрытым глобальным состоянием. protected не означает «доступно всему проекту» и вне пакета связано с наследованием. Если объявлен любой конструктор, компилятор не добавляет неявный конструктор без аргументов.

Вопрос 13 из 20

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

package api;
public class Base { protected int value = 7; }
// другой пакет:
Base b = new Base();
System.out.println(b.value);

Переназначение параметра не меняет ссылку в вызывающем коде, но изменение объекта через параметр меняет сам объект. Сеттер позволяет получить отрицательный баланс и разрушает условие, на котором опирается withdraw. Класс из другого пакета, не являющийся наследником, не может обратиться к protected-полю через обычную ссылку. static reset() не может напрямую обратиться к нестатическому полю value, поэтому код не компилируется. Конструктор без аргументов делегирует другому конструктору и создаёт объект с именем "guest".

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

// Фрагмент на ревью
package api;
public class Base { protected int value = 7; }
// другой пакет:
Base b = new Base();
System.out.println(b.value);

Собрать проверку инвариантов в одном основном конструкторе, а остальные использовать как делегирующие. Добавлять @Override, чтобы компилятор обнаружил случайную перегрузку вместо переопределения. Скрыть поле и предоставить операцию предметного уровня вместо расширения видимости. Заменить общий setter предметными операциями с проверкой допустимого перехода состояния. Сделать reset методом экземпляра либо передавать объект явно.

Вопрос 16 из 20

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

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

Вопрос 17 из 20

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

Условие цикла проверяется перед каждой итерацией, а обновление for выполняется после тела. Метод экземпляра работает с состоянием конкретного объекта, а static-метод не имеет неявной ссылки this. private ограничивает доступ самим классом, package-private — пакетом, protected добавляет доступ наследникам с особыми правилами. Инвариант должен выполняться после завершения конструктора и каждой публичной операции объекта. Вызов this(...) или super(...) должен быть первым оператором конструктора.

Вопрос 18 из 20

В каком дополнительном сценарии вывод о теме «Поля и методы» в разделе «Классы и инкапсуляция» может оказаться неверным?

Поле получает значение по умолчанию, а локальная переменная — нет. Если объявлен любой конструктор, компилятор не добавляет неявный конструктор без аргументов. Статическое поле разделяется всеми экземплярами и может стать скрытым глобальным состоянием. protected не означает «доступно всему проекту» и вне пакета связано с наследованием. Проверка только в конструкторе недостаточна, если наружу возвращается изменяемая коллекция или массив.

Вопрос 19 из 20

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

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

Вопрос 20 из 20

Какой дефект инварианта есть у показанного класса Account?

class Account {
    private int balance;
    void setBalance(int value) { balance = value; }
    void withdraw(int amount) {
        if (amount > balance) throw new IllegalStateException();
        balance -= amount;
    }
}

Приведение объекта Cat к Dog компилируется через общий тип Animal, но падает во время выполнения. Сеттер позволяет получить отрицательный баланс и разрушает условие, на котором опирается withdraw. Конструктор без аргументов делегирует другому конструктору и создаёт объект с именем "guest". Класс из другого пакета, не являющийся наследником, не может обратиться к protected-полю через обычную ссылку. Сеттер не позволяет получить отрицательный баланс и разрушает условие, на котором опирается withdraw.

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

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

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

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