Comments 19
Расширю вопрос выше: зачем вообще в конфигурации прописывать конкретные списки инжектируемых реализаций?
Как по мне, так инъекция коллекции для того и нужна чтобы получить сразу все реализации.
Если вам нужны не все, то и реализовывать это нужно явно не через прибивание гвоздями того что нужно в код "конфигурации".
Если отказаться от хард-кода, то сразу появляется несколько вариантов, включающие как использование аннотаций @Qualifier, так и инъекция через конструктор с модификацией полной коллекции до требуемого варианта — в зависимости от конкретных потребностей.
P.S.
В документации к @Autowired явно указано как он будет работать для вариантов с инъекцией коллекций:
In case of a {@link java.util.Collection} or {@link java.util.Map}
dependency type, the container will autowire all beans matching the
declared value type. In case of a Map, the keys must be declared as
type String and will be resolved to the corresponding bean names.
2) Qualifier не позволит создать несколько разных бинов с одним именем, каким образом вы предлагаете их заинжектить?
3) По поводу решения с inject'ом того, что предлагает Spring: я правильно понимаю, что вы предлагаете фильтровать каждый раз полученный List? Тогда логика отбора нужных бинов уйдет в сервис, который должен их лишь использовать, что тоже выглядит странно.
1) Вопрос «зачем» звучал про конкретную реализацию, а не паззлеры в общем. В Вашем примере в системе будут жить два Терминатора и два Рембо: один в виде самостоятельного Bean и ещё один как элемент коллекции. Какие проблемы могут возникнуть когда программист случайно подумает что их в системе только 1 штука, одному Гэндальфу известно.
2) Сам Spring, а не Qualifier не позволит создать несколько разных Bean с одним именем.
3) Совсем не обязательно, например, можно передавать в конструктор класса, требующего список action-героев, два параметра:
Map<String, Hero>– коллекция порождённых системой Bean'ов- Некий Bean, содержащий логику принадлежности к action-героям:
(String, Hero) -> boolean. Или, если мудрить,(String, Hero) -> Set<EnumHeroType>
Естественно, процесс отображения всех hero-Bean'ов в список action-героев произойдёт один раз, во время инициализации системы.
1) Зачем? А зачем вообще курсы нужны, зачем какие-то пазлеры проводят, зачем у коллег спрашивают, если есть документация?)
Документация для того и нужна чтобы её читать и использовать инструмент по назначению, а не получать странное поведение, с которым потом приходится бороться странными методами.
А пазлеры не относятся к текущей статье.
2) Qualifier не позволит создать несколько разных бинов с одним именем, каким образом вы предлагаете их заинжектить?
@Qualifier не создаёт бины — он подсказывает какие именно бины нужно инжектить.
Требования уникальности имён бинов, как уже сказали выше, зашито в самом фреймворке.
3) По поводу решения с inject'ом того, что предлагает Spring: я правильно понимаю, что вы предлагаете фильтровать каждый раз полученный List? Тогда логика отбора нужных бинов уйдет в сервис, который должен их лишь использовать, что тоже выглядит странно.
Если сервису нужен какой-то срез коллекции всех бинов определённого типа, то так и так получается что именно сервис определяет логику этого среза.
В данной статье в качестве решения этой задачи (организации среза коллекции) предлагают зашить эту логику в конфигурацию в результате:
- логика прибита гвоздями к коду и никак не настраивается
- этот срез выдаёт одинаковый результат и на продовом коде и на тестовом — чтобы добавить тестовый бин в этот срез нужно перерабатывать саму конфигурацию, вместо того чтобы просто добавить бин в тестовом скопе
Есть решения более подходящие, на мой взгляд, например:
- Инжектить промежуточный бин, который в себя инжектит всю коллекцию, а возвращает необходимый срез
- Инжектить всю коллекцию плюс бин обеспечивающий фильтрацию, передавать одно во второе и получить необходимый срез
Наверняка есть и ещё более корректные и функциональные варианты, но вариант описанный в статье выглядит явно велосипедным.
По моему мнению, статья решает неправильную проблему неправильными средствами.
И да, я повторюсь, все нюансы инжекта бинов в списки и мапы описаны в документации — достаточно её прочитать чтобы понять как оно работает, вместо того что раскрывать всем глаза на особенности реализации.
Если вы это используете в рамках обучения как пример что такое Qualifier я вам рекомендую придумать другой пример.
Я не представляю где такой паттерн может понадобиться, и лишь запутает учеников, которые ведь постараются его использовать поломав всю архитектуру. Вам нужен или список всех бинов одного типа (i.e., представлящих один интерфейс) ИЛИ нужно несколько заведомо известных конкретных бинов. Но список из конкретных бинов это какая-то странная смесь, и скорее всего означает что проблема в архитектуре, не надо к ней подталкивать.
К слову, я начал использовать Spring еще с версии 1.0, сделал на нем думаю не менее тысячи малых и не очень сервисов с тех пор, но ни разу не сталкивался с такой задачей где это было бы применимо. Qualifier отдельно, списки отдельно.
@Autowired(required = false)
private List<Hero> actionHeroes = ImmutableList.of(); //List.of() - from Java 9
Тогда инициализация контекста не свалится если в контексте не будет не одного герояю
Некоторые тонкости injection'а коллекций в Spring'е