Антипаттерны: Optional как поле (не сериализуем, лишняя аллокация), как параметр (перекладывает проблему на вызывающего), голый get() без проверки, isPresent + get вместо map и orElse, Optional<List> вместо пустого списка, Optional.of(null) (NPE — нужен ofNullable).
А ещё JPA-сущности: геттер может возвращать Optional, поле — нет
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Замысел был узкий: дать методу способ явно сказать «результата может не быть», чтобы вызывающий не забыл про этот случай. Для полей он не подходит — класс не сериализуется, добавляется лишний уровень косвенности и аллокация на каждый объект. Для параметров он лишь перекладывает проблему: вызывающему теперь нужно оборачивать значение, а внутри всё равно возможен null вместо самого Optional. Вызов get() без проверки возвращает нас к NullPointerException, только под другим именем; современная альтернатива — orElseThrow(), которая говорит о намерении явно. Возврат же Optional из метода поиска — ровно то, ради чего он создавался.
Несколько верных вариантов. Подумайте, потом откройте ответ.
Зачем Optional, orElse против orElseGet, композиция map/flatMap/filter и антипаттерны использования.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto