Поддерживаемость аннотаций Java?

Question

Мой проект медленно внедряет аннотации Java. Половина разработчиков, в том числе и я, считают, что выполнение чего-либо сложного с аннотациями, похоже, увеличивает общую нагрузку на обслуживание. Другая половина команды считает, что это колени пчелы.

Каков ваш реальный опыт работы с командами разработчиков, которые могут поддерживать аннотированный код?

Answer 1

Мой личный опыт показывает, что в среднем работа с аннотациями для большинства разработчиков гораздо проще, чем работа со стандартным адом Java Java Configuration. Для таких вещей, как JPA и Spring тестирование, они абсолютно спасают жизнь.

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

Обычно проблема с такими изменениями заключается в том, что привыкание к ним просто требует времени. Большинство людей, включая разработчиков, сопротивляются изменениям. Я помню, когда я начал работать со Spring. В течение первых нескольких недель я задавался вопросом, почему кто-либо смирился с головными болями, связанными с этим. Затем, несколько недель спустя, я подумал, как бы я жил без него.

Answer 2

Я чувствую, что он разбивается на два варианта использования аннотаций - аннотации для предоставления «описания» класса по сравнению с аннотациями для обеспечения «зависимости» класса.

Я согласен с использованием «описания» аннотаций к классу - это то, что принадлежит классу, и аннотация помогает сделать сокращенную версию этого - аннотации JPA подпадают под это.

Однако мне не очень нравятся аннотации «зависимости» - если вы помещаете зависимость непосредственно в класс - даже если она определяется во время выполнения из аннотации, а не во время компиляции в классе - не что ломает инъекцию зависимости? (возможно, по духу, а не по правилу ...)

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

Answer 3

Я лично считаю, что конкретный вариант использования, который вы упомянули (автоматическое создание веб-форм), является отличным вариантом использования для аннотаций. Любой сценарий «фреймворка», в котором вы можете написать упрощенный код и позволить фреймворку выполнять тяжелую (часто повторяющуюся) работу, основанную на нескольких предложениях (или аннотациях), я думаю, является идеальным вариантом использования аннотаций.

Мне любопытно, почему вам не нравятся аннотации в этой ситуации, и что вы считаете "бременем обслуживания"? (и я не пытаюсь оскорбить вашу позицию, просто поймите это).

Answer 4

Это сильно зависит от поддержки IDE. Я чувствую, что аннотации должны синхронизироваться с кодом посредством проверок в IDE, но поддержки для этого несколько не хватает.

например. старая версия IDEA будет предупреждать, если вы переопределите функцию без @Override, но не удалит тег @Override, если вы изменили сигнатуру метода (или, если уж на то пошло, сигнатуру суперкласса) и нарушили отношение.

Без поддержки я считаю их громоздким способом добавления метаданных в код.

Answer 5

Я абсолютно люблю аннотации. Я использую их из Hibernate / JPA, Seam, JAXB .... все, что я могу. ИМО, нет ничего хуже, чем открывать файл XML только для того, чтобы узнать, как обрабатывается класс.

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

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