JV Java · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Optional без злоупотреблений

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

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

⏱ --:--

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

Вопрос 1 из 25

Что нужно отдельно проверить на границе контракта «map и flatMap» в разделе «Optional без злоупотреблений»?

// Минимальный пример
java.util.Optional<java.util.Optional<String>> email = findUser(1)
    .map(User::email);

Некоторые оптимизации могут не выполнять peek для каждого элемента, если результат можно получить без обхода. map не вызывает функцию для пустого Optional и превращает null, возвращённый преобразователем, в пустой Optional. flatMap не вызывает функцию для пустого Optional и превращает null, возвращённый преобразователем, в пустой Optional. Predicate.not удобен для отрицания, но не превращает null-небезопасную проверку в безопасную. Optional сам может быть null, если контракт нарушен; тип не защищает от такого присваивания автоматически.

Вопрос 2 из 25

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

Optional хорошо выражает отсутствие результата, но как поле сущности или параметр метода часто усложняет модель и сериализацию. Ленивая запасная ветвь экономит работу, но поставщик должен оставаться предсказуемым и не скрывать важные операции ввода-вывода. Тип делает отсутствие заметным, но не заменяет предметную ошибку там, где значение обязано существовать. Проверка всех ветвей повышает надёжность, но тесты должны утверждать внешний результат, а не повторять внутреннюю цепочку map и flatMap. Цепочка flatMap хорошо описывает зависимые поиски, но длинная последовательность может скрыть причину отсутствия.

Вопрос 3 из 25

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

// Фрагмент на ревью
java.util.Optional<User> findSafely(long id) {
    try { return repository.find(id); }
    catch (DatabaseException e) { return java.util.Optional.empty(); }
}
return findSafely(id).filter(User::active).map(User::name).orElse("guest");

Разделить «не найдено» и «сбой поиска» разными путями и проверить оба. Для дорогого или побочного вычисления выбрать orElseGet. Использовать flatMap для перехода к следующей необязательной операции. Использовать перегрузку, аннотацию о допустимости null или отдельный объект запроса — в зависимости от смысла параметра. Использовать ofNullable на границе API, допускающего null, и не превращать неожиданный null в отсутствие без решения о его предметном смысле.

Вопрос 4 из 25

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

// Фрагмент на ревью
String raw = null;
var value = java.util.Optional.of(raw);
System.out.println(value.orElse("none"));

Использовать flatMap для перехода к следующей необязательной операции. Выносить повторяющиеся проверки в именованные Predicate и отдельно тестировать порядок короткого замыкания и работу с null. Использовать перегрузку, аннотацию о допустимости null или отдельный объект запроса — в зависимости от смысла параметра. Использовать ofNullable на границе API, допускающего null, и не превращать неожиданный null в отсутствие без решения о его предметном смысле. Разделить «не найдено» и «сбой поиска» разными путями и проверить оба.

Вопрос 5 из 25

Какое замечание о сопровождении или производительности темы «map и flatMap» в разделе «Optional без злоупотреблений» справедливо?

Композиция правил уменьшает дублирование, но длинная цепочка без названий скрывает причину отказа. Цепочка flatMap хорошо описывает зависимые поиски, но длинная последовательность может скрыть причину отсутствия. Цепочка map хорошо описывает зависимые поиски, но длинная последовательность может скрыть причину отсутствия. Optional хорошо выражает отсутствие результата, но как поле сущности или параметр метода часто усложняет модель и сериализацию. Тип делает отсутствие заметным, но не заменяет предметную ошибку там, где значение обязано существовать.

Вопрос 6 из 25

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

java.util.Optional<User> findSafely(long id) {
    try {
        return repository.find(id);
    } catch (DatabaseException e) {
        return java.util.Optional.empty();
    }
}

return findSafely(id)
    .filter(User::active)
    .map(User::name)
    .orElse("guest");

filter(User::active) вызывается даже для пустого Optional и поэтому может выбросить исключение. orElse("guest") вычисляет запасное значение только тогда, когда пользователь действительно найден. Optional.empty() сохраняет пойманное исключение внутри объекта и позволяет прочитать его позднее. Отсутствие записи и сбой базы становятся одним empty, поэтому авария маскируется как штатный результат. map(User::name) автоматически превращает любое исключение метода name() в Optional.empty().

Вопрос 7 из 25

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

Ветви Optional надо проверять отдельно: присутствующее значение, отсутствие значения, исключение из функции-преобразователя и стоимость запасного вычисления. Optional.of требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно создаёт отсутствие. Optional прежде всего предназначен для возвращаемого значения, когда отсутствие — нормальная часть контракта. orElse вычисляет запасное значение заранее, orElseGet вызывает поставщик только при пустом Optional. map оборачивает обычный результат функции, flatMap ожидает функцию, уже возвращающую Optional.

Вопрос 8 из 25

Что следует изменить в разделе «Optional без злоупотреблений», чтобы сохранить замысел и соблюсти контракт «map и flatMap»?

// Фрагмент на ревью
java.util.Optional<java.util.Optional<String>> email = findUser(1)
    .map(User::email);

Использовать flatMap для перехода к следующей необязательной операции. Использовать ofNullable на границе API, допускающего null, и не превращать неожиданный null в отсутствие без решения о его предметном смысле. Использовать map для перехода к следующей необязательной операции. Использовать map/filter для чистых преобразований, а наблюдение оставлять временной диагностикой. Для дорогого или побочного вычисления выбрать orElseGet.

Вопрос 9 из 25

Что произойдёт с кодом по теме «Значения по умолчанию» в разделе «Optional без злоупотреблений»?

var name = java.util.Optional.of("ready")
    .orElse(loadDefault());
System.out.println(name);

loadDefault выполняется даже при заполненном Optional, если используется orElse. loadDefault выполняется даже при заполненном Optional, если используется orElseGet. DatabaseException превращается в Optional.empty(), поэтому сбой базы и отсутствие пользователя дают один и тот же результат "guest". Параметр Optional заставляет вызывающего создавать обёртку и всё равно не исключает передачу null. map(User::email), где email возвращает Optional<String>, создаёт Optional<Optional<String>>.

Вопрос 10 из 25

Какое утверждение о механизме «Создание Optional» верно в контексте раздела «Optional без злоупотреблений»?

Optional.of требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно создаёт отсутствие. Optional.of не требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно создаёт отсутствие. Ветви Optional надо проверять отдельно: присутствующее значение, отсутствие значения, исключение из функции-преобразователя и стоимость запасного вычисления. Optional прежде всего предназначен для возвращаемого значения, когда отсутствие — нормальная часть контракта. Optional.of требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно не создаёт отсутствие.

Вопрос 11 из 25

Что произойдёт при вызове send(null), несмотря на тип параметра Optional<String>?

// Минимальный пример
static void send(java.util.Optional<String> address) {
    address.ifPresent(System.out::println);
}
send(null);

Метод завершится NullPointerException при вызове address.ifPresent(...), потому что сам Optional оказался null. Метод напечатает строку "null", а затем вернётся нормально. ifPresent вызовет Consumer с аргументом null. Метод ничего не напечатает: null автоматически преобразуется в Optional.empty(). Компилятор запретит вызов send(null), поскольку параметр имеет тип Optional<String>.

Вопрос 12 из 25

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

orElseGet вычисляет запасное значение заранее, orElseGet вызывает поставщик только при пустом Optional. orElse вычисляет запасное значение заранее, orElseGet вызывает поставщик только при пустом Optional. orElse вычисляет запасное значение заранее, orElse вызывает поставщик только при пустом Optional. Optional.of требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно создаёт отсутствие. map оборачивает обычный результат функции, flatMap ожидает функцию, уже возвращающую Optional.

Вопрос 13 из 25

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

String raw = null;
var value = java.util.Optional.of(raw);
System.out.println(value.orElse("none"));

Optional.of(null) выбрасывает NullPointerException в месте создания. loadDefault выполняется даже при заполненном Optional, если используется orElse. Optional.of(null) выбрасывает IllegalStateException в месте создания. Параметр Optional заставляет вызывающего создавать обёртку и всё равно не исключает передачу null. Компактный конструктор проверяет вход до неявного присваивания компонентам.

Вопрос 14 из 25

Что важно учитывать при применении механизма «Значения по умолчанию» из раздела «Optional без злоупотреблений» в рабочем проекте?

Optional хорошо выражает отсутствие результата, но как поле сущности или параметр метода часто усложняет модель и сериализацию. Тип делает отсутствие заметным, но не заменяет предметную ошибку там, где значение обязано существовать. Ленивая запасная ветвь экономит работу, но поставщик должен оставаться предсказуемым и не скрывать важные операции ввода-вывода. Генеративные проверки инвариантов полезны для объекта-значения, но не заменяют примеры с точными правилами округления и сериализации. Проверка всех ветвей повышает надёжность, но тесты должны утверждать внешний результат, а не повторять внутреннюю цепочку map и flatMap.

Вопрос 15 из 25

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

java.util.Optional<java.util.Optional<String>> email = findUser(1)
    .map(User::email);

Для пустой строки второй предикат не вызывается, потому что первый уже вернул false. loadDefault выполняется даже при заполненном Optional, если используется orElse. map(User::email), где email возвращает Optional<String>, не создаёт Optional<Optional<String>>. flatMap(User::email), где email возвращает Optional<String>, создаёт Optional<Optional<String>>. map(User::email), где email возвращает Optional<String>, создаёт Optional<Optional<String>>.

Вопрос 16 из 25

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

// Фрагмент на ревью
var name = java.util.Optional.of("ready")
    .orElse(loadDefault());
System.out.println(name);

Для дорогого или побочного вычисления выбрать orElseGet. Для дорогого или побочного вычисления выбрать orElseGetGet. Передать Clock или функцию получения времени как зависимость. Для дорогого или побочного вычисления выбрать orElse. Использовать flatMap для перехода к следующей необязательной операции.

Вопрос 17 из 25

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

static void send(java.util.Optional<String> address) {
    address.ifPresent(System.out::println);
}
send(null);

Optional.of(null) выбрасывает NullPointerException в месте создания. Для пустой строки второй предикат не вызывается, потому что первый уже вернул false. Параметр Optional заставляет вызывающего создавать обёртку и всё равно не исключает передачу null. map(User::email), где email возвращает Optional<String>, создаёт Optional<Optional<String>>. DatabaseException превращается в Optional.empty(), поэтому сбой базы и отсутствие пользователя дают один и тот же результат "guest".

Вопрос 18 из 25

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

Optional прежде всего предназначен для возвращаемого значения, когда отсутствие — нормальная часть контракта. Optional.of требует ненулевое значение, ofNullable превращает null в пустой Optional, а Optional.empty явно создаёт отсутствие. Ветви Optional надо проверять отдельно: присутствующее значение, отсутствие значения, исключение из функции-преобразователя и стоимость запасного вычисления. Function<T,R> преобразует T в R; compose выполняет переданную функцию раньше, andThen — позже. orElse вычисляет запасное значение заранее, orElseGet вызывает поставщик только при пустом Optional.

Вопрос 19 из 25

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

Цепочка flatMap хорошо описывает зависимые поиски, но длинная последовательность может скрыть причину отсутствия. Тип делает отсутствие заметным, но не заменяет предметную ошибку там, где значение обязано существовать. Проверка всех ветвей повышает надёжность, но тесты должны утверждать внешний результат, а не повторять внутреннюю цепочку map и flatMap. Композиция полезна для небольших чистых этапов, но не заменяет обработку ошибок и контекстные сообщения. Optional хорошо выражает отсутствие результата, но как поле сущности или параметр метода часто усложняет модель и сериализацию.

Вопрос 20 из 25

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

Проверять только факт наличия значения: содержимое Optional не влияет на внешний контракт. Проверка всех ветвей повышает надёжность, но тесты должны утверждать внешний результат, а не повторять внутреннюю цепочку map и flatMap. Копирование даёт надёжную изоляцию, но на больших структурах требует оценки памяти и возможности структурного разделения. Достаточно протестировать непустой Optional, потому что пустая ветвь не содержит вычислений. Тип делает отсутствие заметным, но не заменяет предметную ошибку там, где значение обязано существовать.

Вопрос 21 из 25

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

// Фрагмент на ревью
static void send(java.util.Optional<String> address) {
    address.ifPresent(System.out::println);
}
send(null);

Использовать ofNullable на границе API, допускающего null, и не превращать неожиданный null в отсутствие без решения о его предметном смысле. Использовать перегрузку, аннотацию о допустимости null или отдельный объект запроса — в зависимости от смысла параметра. Использовать flatMap для перехода к следующей необязательной операции. Хранить минимальные денежные единицы в long либо использовать BigDecimal с согласованными масштабом и правилом округления. Разделить «не найдено» и «сбой поиска» разными путями и проверить оба.

Вопрос 22 из 25

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

flatMap оборачивает обычный результат функции, flatMap ожидает функцию, уже возвращающую Optional. orElse вычисляет запасное значение заранее, orElseGet вызывает поставщик только при пустом Optional. Function<T,R> преобразует T в R; compose выполняет переданную функцию раньше, andThen — позже. map оборачивает обычный результат функции, flatMap ожидает функцию, уже возвращающую Optional. map оборачивает обычный результат функции, map ожидает функцию, уже возвращающую Optional.

Вопрос 23 из 25

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

// Минимальный пример
java.util.Optional<String> value = null;
System.out.println(value.orElse("none"));

Optional сам может быть null, если контракт нарушен; тип не защищает от такого присваивания автоматически. Класс-запись record неизменяем лишь поверхностно: компонент List может ссылаться на изменяемый список. Вызов get без isPresent переносит ошибку в NoSuchElementException без предметного контекста. map не вызывает функцию для пустого Optional и превращает null, возвращённый преобразователем, в пустой Optional. Коллекция Optional обычно хуже пустой коллекции: два уровня отсутствия редко несут полезный смысл.

Вопрос 24 из 25

Что нужно отдельно проверить на границе контракта «Значения по умолчанию» в разделе «Optional без злоупотреблений»?

orElseThrow без аргументов выбрасывает NoSuchElementException, а поставщик не позволяет дать предметную ошибку. orElseThrow без аргументов выбрасывает NoSuchElementException, а поставщик позволяет дать предметную ошибку. orElseGetThrow без аргументов выбрасывает NoSuchElementException, а поставщик позволяет дать предметную ошибку. Collections.unmodifiableList без копии защищает только конкретный путь доступа и отражает изменения исходника. Вызов get без isPresent переносит ошибку в NoSuchElementException без предметного контекста.

Вопрос 25 из 25

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

java.util.Optional<User> findSafely(long id) {
    try { return repository.find(id); }
    catch (DatabaseException e) { return java.util.Optional.empty(); }
}
return findSafely(id).filter(User::active).map(User::name).orElse("guest");

Optional.of(null) выбрасывает NullPointerException в месте создания. DatabaseException превращается в Optional.empty(), поэтому сбой базы и отсутствие пользователя дают один и тот же результат "guest". Обе строки дают ключ "a", поэтому Collectors.toMap без merge-функции выбрасывает IllegalStateException из-за дубликата ключа. loadDefault выполняется даже при заполненном Optional, если используется orElse. Параметр Optional заставляет вызывающего создавать обёртку и всё равно не исключает передачу null.

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

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

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

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