Введение в контексты и внедрение зависимостей (CDI)

Именно здесь @Produces в @Produces аннотация @Produces :

 public class BufferedReaderProducer { @Produces BufferedReader getBufferedReader() { return new BufferedReader(new InputStreamReader(System.in)); } } 

В двух словах, класс BufferedReaderProducer — это простая фабрика, которая создает объект BufferedReader . Учитывая, что метод getBufferedReader() был аннотирован аннотацией @Produces , в терминологии CDI этот метод называется производителем .

Как и в этом случае, класс BufferedReader не является реализатором какого-либо интерфейса, в частности, CDI сначала вызывает соответствующий метод производителя для получения рассматриваемого объекта, а затем внедряет его в клиентский класс.

Очевидно, что методы продюсера являются очень мощной функцией CDI, так как они представляют собой аккуратную реализацию фабричного шаблона , заключенного в границы одной единственной аннотации. Но CDI предоставляет еще более полезные и расширенные функции для определения точек впрыска, такие как пользовательские квалификаторы.

Работа с пользовательскими классификаторами

Пользовательские квалификаторы необходимы, если вы хотите создать более семантические, выборочные и значимые точки внедрения в приложении. Хотя имя слегка пугает, пользовательский квалификатор — это просто простая аннотация, связанная с конкретной реализацией. На первый взгляд это похоже на аннотацию @Named которая всегда используется с одним и тем же @Named строки.

Например, для классов текстового процессора квалификаторы могут быть определены следующим образом:

 @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface LowercaseTextProcessor { } @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface UppercaseTextProcessor { } @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface ReverseTextProcessor { } 

Аннотация @Qualifier сообщает CDI, что они будут использоваться для инъекций. Но сначала их нужно применить к реализации, чтобы CDI знал, с какими типами они связаны:

 @LowercaseTextProcessor public class LowercaseTextProcessor implements TextProcessor { ... } @UppercaseTextProcessor public class UppercaseTextProcessor implements TextProcessor { ... } @ReverseTextProcessor public class ReverseTextProcessor implements TextProcessor { ... } 

Теперь, когда CDI стало известно, что, например, @UppercaseTextProcessor (аннотация) внедряет UppercaseTextProcessor (реализация), соответствующая точка внедрения может выглядеть следующим образом:

 @Inject public TextApplication( @UppercaseTextProcessor TextProcessor textProcessor, BufferedReader userInputReader) { ... } 

Довольно просто, правда? Самые большие преимущества использования пользовательских квалификаторов по сравнению с более простыми аннотациями, такими как @Named , можно свести к следующим моментам:

1. Сделайте безопасность типов еще сильнее . Например, привязка пользовательского квалификатора к подклассу базового класса в данной иерархии гарантирует, что только подтип будет введен. @Default , @Alternative и @Named настоящее время не поддерживают эту функцию. Кроме того, ни один из них не может быть связан с политикой хранения или с юридической целью, но могут быть настроены пользовательские квалификаторы, что облегчает создание более целевых классификаторов.

2. Разрешить инъекционные исключения неопределенности . Создать неоднозначные ситуации легко, например, если несколько реализаций помечены @Default или с @Default и тем же квалификатором для @Named . По понятным причинам в таких случаях CDI не сможет определить во время выполнения, какая реализация должна быть внедрена в целевой объект (процесс внедрения неоднозначен), и, таким образом, вызовет исключение развертывания — в терминологии CDI — внедрение зависимости исключение неоднозначности . Пользовательские квалификаторы позволяют избежать этих двусмысленностей с помощью семантических аннотаций, которые содержат метаданные, связанные с инъекциями.

3. Соберите метаданные и свяжите их с инъекционными классами . Это включает в себя политику хранения и юридические цели, к которым могут применяться квалификаторы, такие как поля и методы.

На данный момент легко увидеть, что пользовательские квалификаторы являются более совершенным и эффективным механизмом для привязки реализаций к точкам внедрения. Но у них также есть недостаток, на который стоит обратить внимание: они могут легко привести к экспоненциальному распространению аннотаций интерфейса, тем самым излишне загрязняя ваш код.

Примерно то же самое можно сказать и о методах производителя: вы не хотите, чтобы несколько фабрик были разбросаны по всему вашему приложению, только потому, что вы можете, верно?

Как правило, используйте эти функции, когда они действительно необходимы, и только в том @Default , @Named аннотации @Default , @Alternative и @Named просто не соответствуют вашим потребностям.

Резюме

Как и многие другие шаблоны проектирования, внедрение зависимостей является не зависящей от языка парадигмой, которая играет фундаментальную роль в объектно-ориентированном проектировании. Проще говоря: если вы делаете хороший объектно-ориентированный дизайн, вы просто не можете жить без DI.

В этом уроке я познакомил вас с доступным руководством по использованию CDI / Weld очень прагматичным способом. Вы научились делать безболезненный DI, используя основные функции стандарта, такие как аннотации @Default и @Alternative , а также работая с более совершенными, включая методы производителя и пользовательские квалификаторы.

Вполне возможно, что наиболее привлекательным аспектом CDI (и всех его реализаций) является то, что он выполняет то, что обещает, по номинальной стоимости, без каких-либо условий: простой аккуратный DI без использования внешней структуры. Более того, учитывая, что любой объект может стать инъецируемым компонентом, если он использует аннотации стандарта, довольно просто использовать CDI гораздо более продуктивным способом.

Очевидно, что использование CDI / Weld в качестве основного механизма DI в Java SE может быть освоено без удара головой о стену. Вам, конечно, будет интересно, как использовать CDI в реальном случае использования. Построение приложения для разбора строк, которое запускается в консоли, все хорошо с дидактической точки зрения и, безусловно, может быть использовано в качестве отправной точки для ознакомления с основными фактами стандарта.

Но есть еще много возможностей для покрытия. Как я уже говорил во введении, CDI позволяет вводить ресурсы Java EE с той же легкостью, что и при внедрении POJO . Эта присущая способность может быть использована для использования CDI при разработке приложений на основе базы данных.

Чтобы проиллюстрировать это, во второй части мы узнаем, как использовать стандарт для разработки приложений на основе JPA.

Будьте на связи!