Аргументы против аннотаций

Возможно, у вас проблема с избыточными аннотациями , которые находятся по всему коду. С помощью метааннотаций избыточные аннотации могут быть заменены, и ваши аннотации, по крайней мере, СУХИЕ.

Из блога Spring:

@Service
@Scope("request")
@Transactional(rollbackFor=Exception.class)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}

@MyService
public class RewardsService {
…
}

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

Я лично считаю, что аннотации взяли на себя слишком много и отошли от своей первоначальной и сверхполезной цели (например, такие мелочи, как указание на отмену) method) в этот сумасшедший инструмент метапрограммирования. Я не считаю, что механизм JAva достаточно надежен для обработки этих кластеров аннотаций, предшествующих каждому методу. Например, в наши дни я борюсь с аннотациями JUnit, потому что они ограничивают меня способами, которые мне не нравятся

При этом, по моему опыту, конфигурация на основе XML тоже не очень хороша. Итак, процитируя Южный Парк, вы выбираете между гигантским душем и бутербродом.

Я думаю, что главное решение, которое вам нужно принять, - это удобнее ли вам проводить делокализацию конфигурации пружины (т. Е. поддерживать два файла вместо одного), а также используете ли вы инструменты или плагины IDE, которые извлекают выгоду из аннотаций. Другой важный вопрос: действительно ли разработчики, которые будут использовать или поддерживать ваш код, понимают аннотации.

Поначалу я тоже скептически относился к аннотациям, но, увидев их в использовании, они могут оказаться очень полезными. Их также можно использовать чрезмерно.

Главное, что нужно помнить об аннотациях, - это то, что они статичны. Они не могут измениться во время выполнения. Любой другой метод конфигурации (xml, самоописание в коде, что угодно) от этого не страдает. Я видел, что у людей здесь, на SO, есть проблемы со Spring с точки зрения наличия тестовой среды для внедрения тестовых конфигураций и необходимости опускаться до XML, чтобы это сделать.

XML не является полиморфным, унаследованным или чем-то еще, так что в этом смысле это не шаг назад.

Преимущество аннотаций состоит в том, что они могут дать вам больше статической проверки вашей конфигурации и могут избежать множества трудностей, связанных с многословием и координацией в конфигурациях XML (в основном сохраняя вещи СУХИМИ).

Как и XML, аннотации могут быть чрезмерно использованным. Главное - сбалансировать потребности и преимущества каждого. Аннотации, в той степени, в которой они дают вам менее подробный код и код DRYer, являются инструментом, который следует использовать.

РЕДАКТИРОВАТЬ: Что касается комментария об аннотации, заменяющей интерфейс или абстрактный класс, я думаю, что это может быть разумным на граница рамки. В структуре, предназначенной для использования сотнями, если не тысячами проектов, наличие интерфейса или базового класса действительно может помешать работе (особенно базовый класс, хотя, если вы можете делать это с аннотациями, нет никаких причин, по которым вы не могли бы » Я делаю это с помощью обычного интерфейса.

Рассмотрим JUnit4. Раньше вам приходилось расширять базовый класс, у которого был метод установки и удаления. На мой взгляд, не имеет значения, были ли они в интерфейсе или в базовом классе. Теперь у меня есть полностью отдельный проект с собственной иерархией наследования, и все они должны соблюдать этот метод. Во-первых, у них не может быть собственных конфликтующих имен методов (это не имеет большого значения в среде тестирования, но вы меня поняли). Во-вторых, у вас есть цепочка вызовов super полностью вниз, потому что все методы должны быть связаны.

Теперь с JUnit4 вы можете иметь разные методы @Before в разных классах в иерархии, и они могут быть независимыми от каждого Другой. Не существует столь же СУХОГО способа сделать это без аннотаций.

С точки зрения разработчиков JUnit, это катастрофа. Намного лучше иметь определенный тип, который вы можете вызвать setUp и teardown. Но фреймворк не существует для удобства разработчика фреймворка, он существует для удобства пользователя фреймворка.

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

Если, однако, вы собираетесь писать код для чтения этой аннотации в своем собственном проекте, бегите подальше.

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

Если, однако, вы собираетесь писать код для чтения этой аннотации в своем собственном проекте, бегите подальше.

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

Если, однако, вы собираетесь писать код для чтения этой аннотации в своем собственном проекте, бегите подальше.

Проверьте эти ответы на похожие вопросы

Каковы плюсы / минусы аннотаций (без компилятора) по сравнению с конфигурационными файлами xml

Конфигурация XML по сравнению с конфигурацией на основе аннотаций

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