Ключевые методы Optional
Optional предоставляет множество методов для работы с данными:
isPresent(): Возвращает true, если значение присутствует.
isEmpty() (добавлен в Java 11): Возвращает true, если значение отсутствует.
ifPresent(Consumer<? super T> consumer): Выполняет действие, если значение присутствует.
orElse(T other): Возвращает значение, если оно присутствует, или other, если отсутствует.
orElseGet(Supplier<? extends T> supplier): Возвращает значение или результат выполнения Supplier, если значение отсутствует.
orElseThrow(Supplier<? extends X> exceptionSupplier): Возвращает значение или выбрасывает исключение, если значение отсутствует.
map(Function<? super T, ? extends U> mapper): Преобразует значение, если оно присутствует, возвращая новый Optional.
flatMap(Function<? super T, Optional<U>> mapper): Преобразует значение, возвращая Optional, результат которого не оборачивается в дополнительный Optional.
filter(Predicate<? super T> predicate): Возвращает Optional, содержащий значение, если оно удовлетворяет предикату, или пустой Optional.
or(Supplier<? extends Optional<? extends T>> supplier) (добавлен в Java 9): Возвращает текущий Optional, если значение присутствует, или результат Supplier.
Пример использования методов
Преимущества Optional
Безопасность от NPE: Optional явно указывает на возможность отсутствия значения, заставляя разработчика обрабатывать этот случай.
Читаемость кода: Код с Optional более выразителен, так как сигнализирует о потенциальном отсутствии значения.
Избежание явного null: Уменьшает использование проверок if (value != null), делая код чище.
Интеграция с функциональным программированием: Методы map, flatMap и filter позволяют использовать Optional в цепочках обработки данных, интегрируясь с Stream API.
Практическое использование Optional
Интеграция со Stream API
Optional часто используется в связке со Stream API для обработки данных, которые могут отсутствовать. Например:
Обработка вложенных объектов
Optional особенно полезен при работе с цепочками объектов, где каждое звено может быть null. Без Optional код выглядел бы так:
С использованием Optional код становится более компактным:
Метод flatMap полезен, если методы возвращают Optional:
Использование в API
Optional часто применяется в публичных API для возврата значений, которые могут отсутствовать. Например, метод Map.getOrDefault может быть заменен на Optional:
#Java #Training #Medium #Optional
Optional предоставляет множество методов для работы с данными:
isPresent(): Возвращает true, если значение присутствует.
isEmpty() (добавлен в Java 11): Возвращает true, если значение отсутствует.
ifPresent(Consumer<? super T> consumer): Выполняет действие, если значение присутствует.
orElse(T other): Возвращает значение, если оно присутствует, или other, если отсутствует.
orElseGet(Supplier<? extends T> supplier): Возвращает значение или результат выполнения Supplier, если значение отсутствует.
orElseThrow(Supplier<? extends X> exceptionSupplier): Возвращает значение или выбрасывает исключение, если значение отсутствует.
map(Function<? super T, ? extends U> mapper): Преобразует значение, если оно присутствует, возвращая новый Optional.
flatMap(Function<? super T, Optional<U>> mapper): Преобразует значение, возвращая Optional, результат которого не оборачивается в дополнительный Optional.
filter(Predicate<? super T> predicate): Возвращает Optional, содержащий значение, если оно удовлетворяет предикату, или пустой Optional.
or(Supplier<? extends Optional<? extends T>> supplier) (добавлен в Java 9): Возвращает текущий Optional, если значение присутствует, или результат Supplier.
Пример использования методов
Optional<String> name = Optional.ofNullable(getName()); // Может вернуть null
String result = name
.map(String::toUpperCase)
.filter(s -> s.length() > 3)
.orElse("DEFAULT");
System.out.println(result); // Выведет преобразованное значение или "DEFAULT"
Этот пример демонстрирует цепочку вызовов, характерную для функционального программирования, где Optional используется для обработки значения с возможностью отсутствия.
Преимущества Optional
Безопасность от NPE: Optional явно указывает на возможность отсутствия значения, заставляя разработчика обрабатывать этот случай.
Читаемость кода: Код с Optional более выразителен, так как сигнализирует о потенциальном отсутствии значения.
Избежание явного null: Уменьшает использование проверок if (value != null), делая код чище.
Интеграция с функциональным программированием: Методы map, flatMap и filter позволяют использовать Optional в цепочках обработки данных, интегрируясь с Stream API.
Практическое использование Optional
Интеграция со Stream API
Optional часто используется в связке со Stream API для обработки данных, которые могут отсутствовать. Например:
Optional<User> user = findUserById(123);
Stream<User> userStream = user.stream(); // Преобразует Optional в Stream
userStream.forEach(System.out::println);
Метод stream() (добавлен в Java 9) позволяет преобразовать Optional в Stream, содержащий либо одно значение, либо пустой.
Обработка вложенных объектов
Optional особенно полезен при работе с цепочками объектов, где каждое звено может быть null. Без Optional код выглядел бы так:
String city = null;
if (user != null && user.getAddress() != null && user.getAddress().getCity() != null) {
city = user.getAddress().getCity();
}
С использованием Optional код становится более компактным:
String city = Optional.ofNullable(user)
.map(User::getAddress)
.map(Address::getCity)
.orElse("Unknown");
Метод flatMap полезен, если методы возвращают Optional:
Optional<String> city = Optional.ofNullable(user)
.flatMap(u -> Optional.ofNullable(u.getAddress()))
.flatMap(a -> Optional.ofNullable(a.getCity()));
Использование в API
Optional часто применяется в публичных API для возврата значений, которые могут отсутствовать. Например, метод Map.getOrDefault может быть заменен на Optional:
Map<String, String> map = new HashMap<>();
Optional<String> value = Optional.ofNullable(map.get("key"));
#Java #Training #Medium #Optional
Антипаттерны и ограничения
Использование Optional для полей класса: Optional не предназначен для хранения состояния в полях класса, так как он не сериализуем (Optional не реализует Serializable). Вместо этого используйте null для полей или коллекции.
Чрезмерное использование isPresent(): Проверки isPresent() с последующим вызовом get() сводят на нет преимущества Optional:
Вместо этого используйте orElse, orElseGet или map:
Передача Optional в методы: Передача Optional в качестве аргумента метода может усложнить API. Лучше передавать значение или null:
Производительность: Создание объектов Optional в циклах или в высокопроизводительных системах может привести к накладным расходам. В таких случаях рассмотрите использование null или оптимизируйте код.
Сериализация: Optional не реализует Serializable, что делает его непригодным для использования в сериализуемых классах. Если сериализация необходима, преобразуйте Optional в null или значение перед сохранением.
Потокобезопасность: Optional не является потокобезопасным, так как он не предназначен для конкурентного доступа. Если значение внутри Optional изменяется в многопоточной среде, используйте синхронизацию или потокобезопасные альтернативы.
Производительность и оптимизация
Создание объектов: Каждый вызов Optional.of или ofNullable создает новый объект (кроме empty(), который использует синглтон). В критически важных участках кода минимизируйте создание Optional.
Кэширование: Если Optional возвращается часто используемым методом, рассмотрите кэширование результата, чтобы избежать повторного создания объектов.
Ленивые вычисления: Используйте orElseGet вместо orElse, если альтернативное значение требует вычислений:
Рекомендации
- Используйте Optional только там, где это имеет смысл: Применяйте Optional для возвращаемых значений методов, где отсутствие значения — это ожидаемый сценарий. Не используйте его для всех случаев, чтобы избежать ненужной сложности.
- Интеграция с функциональными API: Максимально используйте методы map, flatMap и filter для обработки данных в функциональном стиле. Это улучшает читаемость и поддерживаемость кода.
- Проверка на обратную совместимость: Если вы разрабатываете публичное API, учитывайте, что клиенты на Java 7 и ниже не смогут использовать Optional. В таких случаях предоставляйте альтернативные методы, возвращающие null.
- Тестирование: Убедитесь, что тесты покрывают оба случая — присутствие и отсутствие значения в Optional. Это гарантирует корректную обработку всех сценариев.
- Рефакторинг старого кода: При рефакторинге кода, использующего null, заменяйте проверки на Optional, но только если это улучшает читаемость и безопасность. Не заменяйте null на Optional механически.
Пример реального сценария
Предположим, у нас есть сервис, который возвращает информацию о пользователе:
#Java #Training #Medium #Optional
Использование Optional для полей класса: Optional не предназначен для хранения состояния в полях класса, так как он не сериализуем (Optional не реализует Serializable). Вместо этого используйте null для полей или коллекции.
// Антипаттерн
public class User {
private Optional<String> name; // Не рекомендуется
}
Чрезмерное использование isPresent(): Проверки isPresent() с последующим вызовом get() сводят на нет преимущества Optional:
// Антипаттерн
if (optional.isPresent()) {
return optional.get();
}
Вместо этого используйте orElse, orElseGet или map:
return optional.orElse(defaultValue);
Передача Optional в методы: Передача Optional в качестве аргумента метода может усложнить API. Лучше передавать значение или null:
// Антипаттерн
void process(Optional<String> value) { ... }
// Лучше
void process(String value) { ... }
Производительность: Создание объектов Optional в циклах или в высокопроизводительных системах может привести к накладным расходам. В таких случаях рассмотрите использование null или оптимизируйте код.
Сериализация: Optional не реализует Serializable, что делает его непригодным для использования в сериализуемых классах. Если сериализация необходима, преобразуйте Optional в null или значение перед сохранением.
Потокобезопасность: Optional не является потокобезопасным, так как он не предназначен для конкурентного доступа. Если значение внутри Optional изменяется в многопоточной среде, используйте синхронизацию или потокобезопасные альтернативы.
Производительность и оптимизация
Создание объектов: Каждый вызов Optional.of или ofNullable создает новый объект (кроме empty(), который использует синглтон). В критически важных участках кода минимизируйте создание Optional.
Кэширование: Если Optional возвращается часто используемым методом, рассмотрите кэширование результата, чтобы избежать повторного создания объектов.
Ленивые вычисления: Используйте orElseGet вместо orElse, если альтернативное значение требует вычислений:
// Менее эффективно
String result = optional.orElse(computeExpensiveDefault());
// Более эффективно
String result = optional.orElseGet(() -> computeExpensiveDefault());
Рекомендации
- Используйте Optional только там, где это имеет смысл: Применяйте Optional для возвращаемых значений методов, где отсутствие значения — это ожидаемый сценарий. Не используйте его для всех случаев, чтобы избежать ненужной сложности.
- Интеграция с функциональными API: Максимально используйте методы map, flatMap и filter для обработки данных в функциональном стиле. Это улучшает читаемость и поддерживаемость кода.
- Проверка на обратную совместимость: Если вы разрабатываете публичное API, учитывайте, что клиенты на Java 7 и ниже не смогут использовать Optional. В таких случаях предоставляйте альтернативные методы, возвращающие null.
- Тестирование: Убедитесь, что тесты покрывают оба случая — присутствие и отсутствие значения в Optional. Это гарантирует корректную обработку всех сценариев.
- Рефакторинг старого кода: При рефакторинге кода, использующего null, заменяйте проверки на Optional, но только если это улучшает читаемость и безопасность. Не заменяйте null на Optional механически.
Пример реального сценария
Предположим, у нас есть сервис, который возвращает информацию о пользователе:
public class UserService {
public Optional<User> findUserById(long id) {
// Имитация поиска в базе данных
return id == 123 ? Optional.of(new User("Alice")) : Optional.empty();
}
public Optional<String> getUserCity(long id) {
return findUserById(id)
.flatMap(user -> Optional.ofNullable(user.getAddress()))
.flatMap(address -> Optional.ofNullable(address.getCity()));
}
}
Этот код демонстрирует, как Optional используется для безопасной обработки цепочки объектов, где каждое звено может быть отсутствующим.
#Java #Training #Medium #Optional
Есть предложение встретиться завтра в 16:00 по МСК на лайвкодинг!
Тема будет: MailSender - или как отправить email из Spring
Тема будет: MailSender - или как отправить email из Spring
Anonymous Poll
44%
Да, интересно, я приду!🥳
6%
Блиин, хочу но не могу 🤷♀️
44%
Посмотрю в записи 😋
6%
Не приду, фигню рассматриваете 👎
Всем привет! 👋
Приглашаю всех желающих сегодня собраться в Яндекс.Телемост в 16:00 по МСК!
В этот раз мы рассмотрим один из модулей Spring - MailSender
И даже если раньше вы все это знали, лишним повторить не будет.
Приходите, это хороший шанс позадавать вопросы🧑💻
Как всегда жду всех! 🫡
Приглашаю всех желающих сегодня собраться в Яндекс.Телемост в 16:00 по МСК!
В этот раз мы рассмотрим один из модулей Spring - MailSender
И даже если раньше вы все это знали, лишним повторить не будет.
Приходите, это хороший шанс позадавать вопросы
Как всегда жду всех! 🫡
Please open Telegram to view this post
VIEW IN TELEGRAM
Предлагаем темы для разбора и публикации! 📖
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
🟢 темы, не выше уровня middle, чтоб был интерес общим.
🟢 Один человек - одна тема.
🟢 Тема должна быть отдельным теоретически-практическим вопросом. Готовый проект - это не тема!
Жду Ваших предложений!👏
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
Жду Ваших предложений!
Please open Telegram to view this post
VIEW IN TELEGRAM
Выбираем темы для рассмотрения в следующие выходные! 🤨
Anonymous Poll
32%
Object Mapper
32%
Mockito
21%
IO/NIO
14%
AOP
Please open Telegram to view this post
VIEW IN TELEGRAM
MailSender - как отправить mail из Spring.
Встреча от 22.06.2025
На сегодняшней встрече мы рассмотрели:
🔵 Что такое MailSender и зачем он вообще нужен.
🔵 Прошлись по основным свойствам и настройкам, посмотрели как запустить отправку писем через Mail.ru
🔵 Написали код в котором научились отправлять как просто письма, так и делать рассылку с вложениями, картинками и html-кодом для красивого оформления писем.
🔵 Все это протестировали через Postman.
Более подробное описание всего, что рассмотрели в видео и пример реализации, который можно скачать:
GitHub - https://github.com/Oleborn/MailSender_Research
(понравилось - поставь звездочку ❤️ )
Всем кто пришел и участвовал - моя признательность🙂
Ссылка на Youtube
Ссылка на Рутьюб
Смотрите, ставьте лайки, подписывайтесь на каналы!
Встреча от 22.06.2025
На сегодняшней встрече мы рассмотрели:
Более подробное описание всего, что рассмотрели в видео и пример реализации, который можно скачать:
GitHub - https://github.com/Oleborn/MailSender_Research
Всем кто пришел и участвовал - моя признательность
Ссылка на Youtube
Ссылка на Рутьюб
Смотрите, ставьте лайки, подписывайтесь на каналы!
Please open Telegram to view this post
VIEW IN TELEGRAM
Всем привет!
Небольшой опрос - устраивает ли Вас, что публикуется на канале? Не собираетесь ли вы уходить?
Небольшой опрос - устраивает ли Вас, что публикуется на канале? Не собираетесь ли вы уходить?
Anonymous Poll
59%
Да, вполне, спасибо за контент! 🙂
16%
В целом да, но многое мне еще непонятно 🤷♀️
3%
В целом да, но я это все уже знаю, хочется чего-то более сложного ✌️
3%
Наверно устраивает. Не уверен. 🧼
0%
Я ничего не понимаю и наверное уйду, пожалуй... 👎
6%
Я читаю канал редко, но в целом уходить не собираюсь, все устраивает. 🏝
0%
У меня есть предложение добавить чего не хватает - я напишу в комментариях 🧑💻
13%
Я есть Грут 🗿
Архитектура Maven и философия Convention over Configuration
После первого знакомства с Maven важно не просто уметь пользоваться им, а понимать его архитектуру, принципы работы и идеологию. Это особенно критично для тех, кто хочет углубиться в автоматизацию, CI/CD и масштабирование проектов с помощью Maven.
Maven как декларативная модель
Maven основан на декларативной модели сборки: вы описываете, что должно быть сделано, а не как. Это противоположность императивным сборочным системам вроде Ant, где разработчик пишет шаг за шагом скрипты сборки. В Maven центром управления является файл pom.xml — он описывает структуру проекта, зависимости, плагины, цели сборки и метаинформацию.
Архитектура Maven
Архитектура Maven построена вокруг трёх ключевых сущностей:
1. POM (Project Object Model)
POM — сердце проекта. В нем описано всё: от координат артефакта (groupId, artifactId, version) до зависимостей, плагинов, профилей и модулей. POM определяет не только поведение сборки, но и организацию кода, стратегию управления версиями и способы расширения функциональности проекта.
2. Репозитории
Система Maven разделяет репозитории на три уровня:
Локальный (~/.m2/repository) — кеш библиотек и плагинов, уже использованных разработчиком
Центральный (Maven Central) — основной публичный репозиторий.
Удалённые (корпоративные) — приватные хранилища (Nexus, Artifactory и др.).
При разрешении зависимостей Maven сначала ищет артефакт в локальном репозитории, затем — в удалённых.
3. Плагины и цели (goals)
Maven сам по себе — движок исполнения, не знающий, как компилировать, тестировать или архивировать проект. Всё это делают плагины, привязанные к жизненному циклу. Например, maven-compiler-plugin отвечает за компиляцию, а maven-surefire-plugin — за запуск тестов. Каждый плагин состоит из целей (goals), которые выполняются в рамках фаз сборки.
Жизненный цикл сборки
Основой выполнения в Maven является жизненный цикл сборки (Build Lifecycle) — предопределённая последовательность фаз.
Есть три основных цикла:
default — основной, включает: compile, test, package, install, deploy.
clean — очищает артефакты: pre-clean, clean, post-clean.
site — генерирует документацию: site, site-deploy.
Maven всегда выполняет все фазы до указанной. То есть mvn install запустит validate, compile, test, package, verify, install.
Convention over Configuration
Одной из ключевых идей Maven является принцип «Конвенция важнее конфигурации» (Convention over Configuration):
Maven ожидает, что структура проекта будет стандартной:
Артефакт будет упакован как jar (если не указано иное).
Папки ресурсов и тестов тоже стандартны.
Это означает, что вам не нужно конфигурировать то, что уже стандартизировано. Но при этом Maven предоставляет гибкость, позволяя переопределять любую часть стандартной логики при необходимости.
Maven и расширяемость
Благодаря своей архитектуре, Maven легко адаптируется под различные сценарии.
Расширение происходит через:
Подключение плагинов.
Наследование и агрегацию POM'ов.
Создание собственных плагинов и Mojo.
Подключение профилей и переменных окружения.
Именно такая расширяемость делает Maven удобным не только для простых библиотек, но и для масштабных корпоративных решений.
#Java #middle #Maven
После первого знакомства с Maven важно не просто уметь пользоваться им, а понимать его архитектуру, принципы работы и идеологию. Это особенно критично для тех, кто хочет углубиться в автоматизацию, CI/CD и масштабирование проектов с помощью Maven.
Maven как декларативная модель
Maven основан на декларативной модели сборки: вы описываете, что должно быть сделано, а не как. Это противоположность императивным сборочным системам вроде Ant, где разработчик пишет шаг за шагом скрипты сборки. В Maven центром управления является файл pom.xml — он описывает структуру проекта, зависимости, плагины, цели сборки и метаинформацию.
Архитектура Maven
Архитектура Maven построена вокруг трёх ключевых сущностей:
1. POM (Project Object Model)
POM — сердце проекта. В нем описано всё: от координат артефакта (groupId, artifactId, version) до зависимостей, плагинов, профилей и модулей. POM определяет не только поведение сборки, но и организацию кода, стратегию управления версиями и способы расширения функциональности проекта.
2. Репозитории
Система Maven разделяет репозитории на три уровня:
Локальный (~/.m2/repository) — кеш библиотек и плагинов, уже использованных разработчиком
Центральный (Maven Central) — основной публичный репозиторий.
Удалённые (корпоративные) — приватные хранилища (Nexus, Artifactory и др.).
При разрешении зависимостей Maven сначала ищет артефакт в локальном репозитории, затем — в удалённых.
3. Плагины и цели (goals)
Maven сам по себе — движок исполнения, не знающий, как компилировать, тестировать или архивировать проект. Всё это делают плагины, привязанные к жизненному циклу. Например, maven-compiler-plugin отвечает за компиляцию, а maven-surefire-plugin — за запуск тестов. Каждый плагин состоит из целей (goals), которые выполняются в рамках фаз сборки.
Жизненный цикл сборки
Основой выполнения в Maven является жизненный цикл сборки (Build Lifecycle) — предопределённая последовательность фаз.
Есть три основных цикла:
default — основной, включает: compile, test, package, install, deploy.
clean — очищает артефакты: pre-clean, clean, post-clean.
site — генерирует документацию: site, site-deploy.
Maven всегда выполняет все фазы до указанной. То есть mvn install запустит validate, compile, test, package, verify, install.
Convention over Configuration
Одной из ключевых идей Maven является принцип «Конвенция важнее конфигурации» (Convention over Configuration):
Maven ожидает, что структура проекта будет стандартной:
src/
main/java/
test/java/
Артефакт будет упакован как jar (если не указано иное).
Папки ресурсов и тестов тоже стандартны.
Это означает, что вам не нужно конфигурировать то, что уже стандартизировано. Но при этом Maven предоставляет гибкость, позволяя переопределять любую часть стандартной логики при необходимости.
Maven и расширяемость
Благодаря своей архитектуре, Maven легко адаптируется под различные сценарии.
Расширение происходит через:
Подключение плагинов.
Наследование и агрегацию POM'ов.
Создание собственных плагинов и Mojo.
Подключение профилей и переменных окружения.
Именно такая расширяемость делает Maven удобным не только для простых библиотек, но и для масштабных корпоративных решений.
#Java #middle #Maven
Что выведет код?
#Tasks
import java.util.function.Consumer;
public class Task230625 {
public static void main(String[] args) {
Consumer<String> consumer1 = s -> System.out.print(s.toUpperCase());
Consumer<String> consumer2 = s -> System.out.print("|" + s + "|");
consumer1.andThen(consumer2).accept("test");
}
}
#Tasks
Продолжаем выбирать темы для разбора и голосовать за рассмотрение предложенных! 🤓
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!✌️
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!
Please open Telegram to view this post
VIEW IN TELEGRAM
Что такое Lock и чем он лучше synchronized? 🤓
Ответ:
Интерфейс Lock (например, ReentrantLock) предоставляет более гибкую синхронизацию, чем synchronized.
Поддерживает тайм-ауты (tryLock), неблокирующие операции и возможность прерывания.
Пример:
Lock lock = new ReentrantLock();
lock.lock();
try {
// Критическая секция
} finally {
lock.unlock();
}
В отличие от synchronized, Lock требует явного вызова unlock().
#собеседование
Ответ:
Поддерживает тайм-ауты (tryLock), неблокирующие операции и возможность прерывания.
Пример:
Lock lock = new ReentrantLock();
lock.lock();
try {
// Критическая секция
} finally {
lock.unlock();
}
В отличие от synchronized, Lock требует явного вызова unlock().
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM