Связывание перехватчиков обеспечивает определенный уровень косвенности, однако лишает возможности упорядочивать перехватчики, как показано в листинге 2.28 (@Interceptors({I1.class, I2.class})). Согласно CDI 1.1 вы можете приоритизировать их, используя аннотацию @javax.annotation.Priority (либо ее XML-эквивалент в файле beans.xml) вместе со значением приоритета, как показано в листинге 2.33.
@Interceptor
@Loggable
@Priority(200)
public class LoggingInterceptor {
··@Inject
··private Logger logger;
··@AroundInvoke
··public Object logMethod(InvocationContext ic) throws Exception {
····logger.entering(ic.getTarget(). toString(), ic.getMethod(). getName());
····try {
······return ic.proceed();
····} finally {
······logger.exiting(ic.getTarget(). toString(), ic.getMethod(). getName());
····}
··}
}
Аннотация @Priority берет целое число, которое может принимать любое значение. Правило состоит в том, что перехватчики с меньшим приоритетом называются первыми. Java EE 7 определяет приоритеты уровня платформы, после чего ваши перехватчики могут вызываться до или после определенных событий. Аннотация javax.interceptor.Interceptor определяет следующий набор констант:
• PLATFORM_BEFORE = 0 — начинает диапазон для ранних перехватчиков, определяемых платформой Java EE;
• LIBRARY_BEFORE = 1000 — открывает диапазон для ранних перехватчиков, задаваемых библиотеками расширения;
• APPLICATION = 2000 — начинает диапазон для ранних перехватчиков, определяемых приложениями;
• LIBRARY_AFTER = 3000 — открывает диапазон для поздних перехватчиков, задаваемых библиотеками расширения;
• PLATFORM_AFTER = 4000 — начинает диапазон для поздних перехватчиков, определяемых платформой Java EE.
Поэтому, если вы хотите, чтобы ваш перехватчик выполнялся до любого перехватчика приложения, но после любого раннего перехватчика платформы, можете написать следующее:
@Interceptor
@Loggable
@Priority(Interceptor.Priority.LIBRARY_BEFORE + 10)
public class LoggingInterceptor {…}
Декораторы
Перехватчики выполняют задачи сквозной функциональности и идеальны для решения таких технических проблем, как управление транзакциями, безопасность или запись в журнал. По своей природе перехватчики не осведомлены о настоящей семантике перехватываемых действий и поэтому не подходят для отделения задач, связанных с бизнесом. Для декораторов характерно обратное.
Декораторы — общий шаблон проектирования, разработанный группой Gang of Four. Идея состоит в том, чтобы взять класс и обернуть вокруг него другой класс (то есть декорировать его). Таким образом, при вызове декорированного класса вы всегда проходите через окружающий его декоратор, прежде чем достигнете целевого класса. Декораторы позволяют добавлять бизнес-методу дополнительную логику. Они не способны решать технические задачи, которые являются сквозными и касаются многих несхожих типов. Хотя перехватчики и декораторы во многом сходны, они дополняют друг друга.
Для примера возьмем генератор чисел ISSN. ISSN — это восьмизначный номер, замещенный номером ISBN (тринадцатизначным номером). Вместо того чтобы иметь два отдельных генератора чисел (например, как в листинге 2.9 или 2.10), вы можете декорировать генератор ISSN, добавив к нему дополнительный алгоритм, превращающий восьмизначный номер в тринадцатизначный. Листинг 2.34 реализует такой алгоритм как декоратор. Класс FromEightToThirteenDigitsDecorator аннотируется javax.decorator.Decorator, реализует бизнес-интерфейсы (NumberGenerator на рис. 2.3) и перезаписывает метод generateNumber. При этом декоратор может быть объявлен абстрактным классом, чтобы ему не приходилось реализовывать все бизнес-методы интерфейсов, если их несколько. Метод generateNumber() вызывает целевой компонент для генерации ISSN, добавляет бизнес-логику для трансформации такого номера и возвращает номер ISBN.
@Decorator
public class FromEightToThirteenDigitsDecorator implements NumberGenerator {
··@Inject @Delegate
··private NumberGenerator numberGenerator;
··public String generateNumber() {
····String issn = numberGenerator.generateNumber();