Рецензия

[livelight]

...на код, присланный мне разработчиком на ревью.

У нас было два Transaction Manager'а, три Kafka Producer'а, три или четыре Rest Template'а...
Не то, чтобы это всё было нужно в приложении, но раз начал коллекционировать бины, то иди в своём увлечении до конца.
Единственное, что меня беспокоило — это аспекты. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек в запое аспектно-ориентированного программирования.

Comments

[livelight]

Если эта логика пишется для конкретного приложения, которое уже на спринге, то есть только два разумных формата для неё: или static class со всеми static методами и без какого-либо состояния, или полноценный бин. Вопрос "зачем нам полный набор минусов спринга здесь, где от него очевидно нет пользы?" имеет смысл только в рамках вопроса, стОит ли вообще писать всё приложение на спринге или чём-то другом, но обсуждать его в сферическом вакууме я не готов.

Если же делается универсальная библиотека, то к ней иногда полезно приделать заодно обёртку в виде спринговых бинов (а к ней 100500 авто-конфигураций и прочее адище) для более удобного втыкания в спринговые приложения. Что, конечно, не мешает выстрелить себе в ногу внутри спринга точно такими же способами, которыми бибилиотека позволяет это сделать без него. Вот, например, мы вкручивали в спринговое приложение Hazelcast, а там под спринговой обёрткой лежит библиотека, в которой есть единое статическое хранилище, которое отдаёт подключения к кластерам по имени конфигурации -- или создаёт конфигурации и подключения по дефолту при первом обращении, а потом хоть обконфигурись, поезд уже ушёл, под этим именем в статике валяется уже другое подключение.