Энтони Гонсалвес - Изучаем Java EE 7

public class BookService {

··@Inject @ThirteenDigits

··private NumberGenerator numberGenerator;

··public Book createBook(String title, Float price, String description) {

····Book book = new Book(title, price, description);

····book.setIsbn(numberGenerator.generateNumber());

····return book;

··}

}

public class LegacyBookService {

··@Inject @EightDigits

··private NumberGenerator numberGenerator;

··public Book createBook(String title, Float price, String description) {

····Book book = new Book(title, price, description);

····book.setIsbn(numberGenerator.generateNumber());

····return book;

··}

}

Для того чтобы это работало, вам не нужна внешняя конфигурация. Поэтому говорят, что CDI использует строгую типизацию. Вы можете как угодно переименовать ваши реализации или квалификатор — точка внедрения не изменится (так называемая слабая связанность). Как видите, CDI — это аккуратный способ произвести внедрение с сохранением безопасности типов. Но если вы начнете создавать аннотации каждый раз, когда захотите что-либо внедрить, код вашего приложения в итоге чрезмерно разрастется. В этом случае вам помогут квалификаторы, используемые с членами.

Квалификаторы, используемые с членами.Каждый раз, когда вам необходимо выбирать из нескольких реализаций, вы создаете квалификатор (то есть аннотацию). Поэтому, если вам нужны две дополнительные цифры и десятизначный генератор чисел, вы создадите дополнительные аннотации (например, @TwoDigits, @EightDigits, @TenDigits, @ThirteenDigits). Представьте, что генерируемые числа могут быть как четными, так и нечетными. В итоге у вас получится множество разных аннотаций: @TwoOddDigits, @TwoEvenDigits, @EightOddDigits и т. д. Один из способов избежать умножения аннотаций — использовать члены.

В нашем примере мы смогли заменить все эти квалификаторы всего одним — @NumberOfDigits с перечислением в качестве значения и логическими параметрами для проверки четности (листинг 2.13).

@Qualifier

@Retention(RUNTIME)

@Target({FIELD, TYPE, METHOD})

public @interface NumberOfDigits {

··Digits value();

··boolean odd();

}

public enum Digits {

··TWO,

··EIGHT,

··TEN,

··THIRTEEN

}

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

@Inject @NumberOfDigits(value = Digits.THIRTEEN, odd = false)

private NumberGenerator numberGenerator;

Используемая реализация сделает то же самое:

@NumberOfDigits(value = Digits.THIRTEEN, odd = false)

public class IsbnEvenGenerator implements NumberGenerator {…}

Множественные квалификаторы.Другой способ квалифицировать компонент и точку внедрения — указать множественные квалификаторы. Так, вместо множественных квалификаторов для четности (@TwoOddDigits, @TwoEvenDigits) либо квалификатора, применяемого с членами (@NumberOfDigits), мы могли использовать два разных набора квалификаторов: один набор для четности (@Odd и @Even), другой — для количества цифр. Ниже приводится способ, которым вы можете квалифицировать генератор 13 четных чисел:

@ThirteenDigits @Even

public class IsbnEvenGenerator implements NumberGenerator {…}

Точка внедрения использовала бы тот же самый синтаксис:

@Inject @ThirteenDigits @Even

private NumberGenerator numberGenerator;

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

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

Альтернативы — это компоненты, аннотированные специальным квалификатором javax.enterprise.inject.Alternative. По умолчанию альтернативы отключены, и чтобы сделать их доступными для инстанцирования и внедрения, необходимо активизировать их в дескрипторе beans.xml. В листинге 2.14 показана альтернатива имитационного генератора чисел.

@Alternative

public class MockGenerator implements NumberGenerator {

··public String generateNumber() {

····return "MOCK";

··}

}

Как видно из листинга 2.14, MockGenerator, как обычно, реализует интерфейс NumberGenerator. Он сопровождается аннотацией @Alternative, которая означает, что CDI обрабатывает его как альтернативу NumberGenerator по умолчанию. Как и в листинге 2.6, эта альтернатива по умолчанию могла бы использовать встроенный квалификатор @Default следующим образом:

@Alternative @Default

public class MockGenerator implements NumberGenerator {…}

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

@Alternative @ThirteenDigits

public class MockGenerator implements NumberGenerator {…}

По умолчанию компоненты @Alternative отключены, и вам необходимо активизировать их явным образом в дескрипторе beans.xml, как показано в листинге 2.15.

·······xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

·······xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

· ···························http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"

·······version="1.1" bean-discovery-mode="all">

··

····org.agoncal.book.javaee7.chapter02.MockGenerator

··

Что касается точки внедрения, ничего не меняется. Таким образом, на код вашего приложения ничто не влияет. Следующий отрывок кода содержит внедрение реализации генератора чисел по умолчанию. Если альтернатива активизирована, то MockGenerator, определенный в листинге 2.14, будет внедрен.

@Inject

private NumberGenerator numberGenerator;

У вас может быть несколько файлов beans.xml, объявляющих несколько альтернатив, в зависимости от вашей среды (разработка, поддержка готового приложения, тестирование и т. д.).

Я показал вам, как внедрять одни компоненты CDI в другие. Благодаря производителям данных вы также можете внедрять примитивы (такие как int, long, float и т. д.), массивы и любой POJO, не поддерживающий CDI. Под поддержкой CDI я имею в виду любой класс, упакованный в архив, содержащий файл beans.xml.

По умолчанию вы не можете внедрять такие классы, как java.util.Date или java.lang.String. Так происходит потому, что все эти классы упакованы в файл rt.jar (классы среды исполнения Java), а этот архив не содержит дескриптор развертывания beans.xml. Если в архиве в папке META-INF нет файла beans.xml, CDI не инициирует обнаружение компонента и POJO не будут обрабатываться как компоненты, а значит, и внедряться. Единственный способ внедрения POJO состоит в использовании полей и методов производителей данных, как показано в листинге 2.16.