Optional и работа с null

var present = Optional.of("значение есть");

present.orElse(expensive());        // expensive() вызвана 1 раз
present.orElseGet(S4::expensive);   // вызвана 0 раз
Optional.empty().orElseGet(S4::expensive);  // вызвана 1 раз

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #optional_null1 / 5
   Почему Optional.get() без проверки считается плохой практикой?

   A)Get() возвращает null для пустого Optional, из-за чего снова возникает та же проблема с NPE

   B)Get() изменяет состояние Optional, делая его пустым после первого вызова, поэтому повторно не работает

   C)Бросит NoSuchElementException, если Optional пуст — теряется смысл Optional

   D)Get() медленно работает, так как каждый раз заново разворачивает обёртку через тяжёлую рефлексию

   показать ответ и разбор

   +C)Бросит NoSuchElementException, если Optional пуст — теряется смысл Optional

   // разбор: get() возвращает значение, но на ПУСТОМ Optional бросает NoSuchElementException. Вызывать его без предварительной проверки isPresent() — по сути тот же необработанный «null», ради ухода от которого Optional и придуман. Идиоматично вместо get() использовать безопасные методы: map/flatMap/filter (преобразования), orElse/orElseGet (значение по умолчанию), orElseThrow (осмысленное исключение), ifPresent/ifPresentOrElse (действие). isPresent()+get() — это «замаскированная null-проверка», обычно её переписывают функционально.

2. #optional_null2 / 5
   Чем flatMap отличается от map у Optional?

   A)Map применяется к пустому Optional, а flatMap — только к непустому, в этом их различие

   B)FlatMap разворачивает значение в null, а map оставляет его в обёртке, поэтому flatMap опаснее

   C)Map и flatMap идентичны для Optional; flatMap оставлен лишь для совместимости со стримами

   D)flatMap для функции, возвращающей Optional (иначе вложенность Optional<Optional<T>>)

   показать ответ и разбор

   +D)flatMap для функции, возвращающей Optional (иначе вложенность Optional<Optional<T>>)

   // разбор: map(f) применяет f к значению и оборачивает результат в Optional (T→U даёт Optional<U>). Если f сама возвращает Optional<U> (например, метод findParent(): Optional<...>), то map дал бы неудобный Optional<Optional<U>>. flatMap ожидает функцию T→Optional<U> и «сплющивает» результат в Optional<U>. Так строят цепочки методов, каждый из которых может не вернуть значение: user.flatMap(User::getAddress).flatMap(Address::getCity). Аналогия — flatMap у стримов, но для «0 или 1» элемента.

3. #optional_null3 / 5
   Что делает ifPresent(consumer) у Optional?

   A)Выполняет действие со значением, только если оно присутствует

   B)Возвращает true или false в зависимости от того, присутствует ли значение внутри Optional

   C)Бросает исключение, если значение отсутствует, вынуждая вызывающего обработать пустой случай

   D)Выполняет переданное действие, подставляя null вместо значения, когда Optional пуст

   показать ответ и разбор

   +A)Выполняет действие со значением, только если оно присутствует

   // разбор: ifPresent(consumer) выполняет переданное действие с содержащимся значением, ЕСЛИ оно есть, и ничего не делает, если Optional пуст — это функциональная замена «if (opt.isPresent()) use(opt.get())». Есть расширенный ifPresentOrElse(consumer, emptyAction) для обеих веток. isPresent() же лишь возвращает boolean. Использование ifPresent/map/orElseGet вместо ручных проверок на наличие делает работу с Optional чище и снижает риск случайного get() на пустом.

4. #optional_null4 / 5
   Чем отличаются Optional.of(x) и Optional.ofNullable(x)?

   A)Of и ofNullable одинаковы, но of работает быстрее, так как не проверяет аргумент на null

   B)of бросит NPE, если x == null; ofNullable вернёт пустой Optional

   C)Of оборачивает значение, а ofNullable оборачивает null в специальное непустое значение-заглушку

   D)OfNullable бросает исключение при null, а of молча создаёт пустой Optional в этом случае

   показать ответ и разбор

   +B)of бросит NPE, если x == null; ofNullable вернёт пустой Optional

   // разбор: Optional.of(x) требует, чтобы x был НЕ null: при null он сразу бросает NullPointerException — используют, когда null «невозможен» и его появление — это баг, который нужно поймать рано. Optional.ofNullable(x) безопасно оборачивает потенциально null-значение: при null возвращает Optional.empty(), иначе — Optional с x. Ещё есть Optional.empty(). Выбор — по контракту: точно не null → of (быстрый отказ при ошибке); может быть null → ofNullable.

5. #optional_null5 / 5
   Хорошая ли идея — использовать Optional в качестве поля класса или параметра метода?

   A)Да, поля типа Optional — рекомендуемый стандарт, они делают все классы автоматически потокобезопасными

   B)Да, параметры Optional обязательны везде, где значение может отсутствовать, — это требование Java

   C)Нет: Optional задуман для возвращаемых значений, для полей/параметров он не рекомендуется

   D)Да, Optional-поля сериализуются лучше обычных, поэтому их используют во всех DTO и entity-классах

   показать ответ и разбор

   +C)Нет: Optional задуман для возвращаемых значений, для полей/параметров он не рекомендуется

   // разбор: Optional спроектирован как ТИП ВОЗВРАЩАЕМОГО значения, чтобы явно сигналить «может не быть». Для ПОЛЕЙ его не советуют: он не Serializable, добавляет обёртку/аллокацию на каждый экземпляр и усложняет модель (поле «Optional пустой» vs «поле null» — двусмысленность). Для ПАРАМЕТРОВ тоже: чище дать перегрузку метода или принять обычное значение/null с проверкой. Итог: Optional — на границе (возврат из find/get), а внутри моделей и параметров — обычные типы.