#java #spring #naming-conventions
#java #spring #соглашения об именовании
Вопрос:
Иногда я нахожу некоторые имена классов, включающие Aware, такие как ApplicationContextAware и MessageSourceAware (spring). Это известно есть какие-либо особые смыслы или это известные правила?
Ответ №1:
Это не классы, это интерфейсы. Имя — это просто соглашение о Spring, означающее, что в этот класс будет введен какой-то специальный объект фреймворка, если он управляется фреймворком.
Непосредственно из документации ApplicationContextAware:
Интерфейс, который должен быть реализован любым объектом, который желает получать уведомления о ApplicationContext, в котором он выполняется.
В этом случае компонент, который реализует этот интерфейс, получит ссылку на ApplicationContext, управляющий приложением.
Комментарии:
1. Большое спасибо! Я начинаю понимать. Например, если вы найдете интерфейс с именем «EmploymentEntityAwareService», вы могли бы подумать, что служба, реализованная любым объектом, имеет объект «Employment» в качестве поля, верно?
2. @yusaku Возможно, это не совсем жесткое правило. Aware — это в основном соглашение Spring, я бы не рекомендовал использовать его в ваших собственных именах классов, если у вас нет действительно веской причины для этого. Что Spring в основном говорит с использованием «Aware», так это «этот класс теперь осознает, что им управляет Spring». Обычно вы хотите избежать прямого использования этих интерфейсов, чтобы ваш код не зависел от Spring Framework. Они предоставляются для обработки отдельных случаев, когда класс должен напрямую взаимодействовать с контейнером Spring.
3. @Jberg Спасибо! Хорошо, я буду осторожен, чтобы использовать его, если мне нужно.
Ответ №2:
Добавление прилагательных типа «aware» в конец — это схема именования, часто используемая для интерфейсов Java. Затем это может быть реализовано классами, и в результате получается код, который более свободно читается людьми, например
class Broker implements ApplicationContextAware { /* ... */ }
где довольно легко увидеть, что этот класс является посредником для чего-то, и он знает, как работать с контекстами приложений. Кроме того, суффикс «Aware» не имеет особого значения с точки зрения Java (компилятора).
Комментарии:
1. В настоящее время я не осведомлен о некоторых, возможно, мне было бы лучше сказать, что «прилагательные» предназначены для интерфейсов, а не уточнять соглашение о суффиксах, используемое в Spring. Hm.
2. @Michael, у меня есть некоторые осведомленные интерфейсы (например, TransactionAware), и я никогда не использовал spring, но я бы не назвал это «часто» используемым.
Ответ №3:
Интерфейсы, которые вы цитируете, похоже, являются специфичным для Spring соглашением, позволяющим объектам взаимодействовать с создавшим их контейнером внедрения зависимостей. Реализуя интерфейс, класс сигнализирует, что он хочет получить определенную информацию из контейнера, и в то же время предоставляет метод, с помощью которого можно передавать эту информацию.
Я бы рассматривал это просто как попытку найти общее имя для интерфейса, который предлагает такую функциональность, не обязательно строгое соглашение с конкретным техническим значением.
Комментарии:
1. Спасибо за ваш ответ. Я проясняю. Если у вас есть больше времени, могу ли я получить какие-либо комментарии по другому моему вопросу, который написан в ответе @mdrg.
Ответ №4:
Концепция осведомленных интерфейсов:
Если я хочу ссылку на объекты классов spring, такие как XmlBeanFactory , ApplicationContext … В 2 или более классах существует 3 возможных способа.
- создание 2
BeanFactoriesв двух классах. - создание в одном классе и совместное использование для всех необходимых классов.
В первом случае мы без необходимости создаем 2 BeanFactories. Во втором случае классы тесно связаны друг с другом.
- Если наш класс реализует
BeanFactoryAwareинтерфейс и переопределяет вызываемый контрактный метод,public BeanFactory setBeanFactory(BeanFactory factory)тогдаIOC containerпосмотрите на этот специальный интерфейс и вызовитеsetBeanFactoryметод, установивBeanFactoryссылку на него.
В 3. случае выше двух проблем нет.