Многие разработчики попадают в ловушку дублирования методов -> один для синхронного использования, другой для асинхронного. На первый взгляд это кажется нормальным, но на деле удваивает работу по поддержке и может привести к скрытым багам, если один из путей обновить, а другой забыть.
Более умный подход заключается в том, чтобы один раз спроектировать основную логику и дать клиентам самим выбрать, как её использовать. Самый простой паттерн заключается в том, чтобы сделать асинхронную версию основным методом. Она может возвращать
CompletableFuture или реактивный тип вроде Mono в Spring. Клиенты, которым нужен асинхронный вызов, используют его напрямую. Клиенты, которым нужен синхронный вариант, просто вызывают .join() или .get().Таким образом, у тебя есть только один кодовый путь для поддержки. Асинхронные клиенты получают неблокирующую производительность, синхронные получают удобство блокирующих вызовов, а API остаётся чистым и устойчивым к будущим изменениям.
👉 Золотое правило здесь -> логику пишем один раз, используем её двумя способами.
👉 Java Portal