Пригодность для обслуживания аннотаций Java?
Также обратите внимание, что Вы будете компилировать против платформ OS X (где применимый) при создании для средства моделирования, таким образом, Вы могли использовать методы и классы, которые не доступны на версиях iPhone платформ.
Одним примером, о котором я могу думать первое, что пришло на ум, является NSPredicate. Я смог скомпилировать и запустить приложение с помощью NSPredicate в средстве моделирования, но это не скомпилирует для устройства, так как тот класс не доступен.
5 ответов
Я чувствую, что он разбивается на два использования аннотаций: аннотации для предоставления «описания» класса и аннотации для обеспечения «зависимости» класса.
Меня устраивает «описание» использования аннотаций в классе - это то, что принадлежит классу, и аннотация помогает сделать сокращенную версию этого - аннотации JPA подпадают под это.
Однако мне не очень нравятся аннотации «зависимости» - если вы помещаете зависимость непосредственно в класс - даже если она определяется во время выполнения из аннотации, а не во время компиляции в классе - не что ломающая инъекция зависимостей? (возможно, по духу, а не по правилам ...)
Это может быть личное предпочтение, но мне нравится один большой XML-файл, содержащий всю информацию о зависимостях моего приложения - я рассматриваю это как «конфигурацию приложения», а не как «конфигурацию класса». Я лучше буду искать в одном известном месте, чем искать во всех классах приложения.
По моему личному опыту, большинству разработчиков в среднем гораздо проще работать с аннотациями, чем с адом стандартной конфигурации Java XML. Для таких вещей, как тестирование JPA и Spring, они абсолютно спасают жизнь.
Аннотации хороши тем, что они делают конфигурацию ваших классов самодокументированной. Теперь вместо того, чтобы искать в огромном XML-файле, чтобы попытаться выяснить, как фреймворк использует ваш класс, ваш класс сообщает вам.
Обычно проблема с такими изменениями заключается в том, что на их привыкание нужно время. Большинство людей, включая разработчиков, сопротивляются изменениям. Помню, когда я начал работать со Spring. Первые несколько недель я задавался вопросом, зачем кому-то мириться с головной болью, связанной с этим. Затем, несколько недель спустя, я подумал, как я
Я абсолютно люблю аннотации. Я использую их из Hibernate / JPA, Seam, JAXB .... все, что могу. ИМО, нет ничего хуже, чем открыть файл XML, чтобы узнать, как обрабатывается класс.
На мой взгляд, аннотации позволяют классу говорить сам за себя. Кроме того, аннотации (надеюсь) являются частью поддержки содержимого вашей IDE, тогда как с конфигурацией XML вы обычно сами по себе.
Однако это может сводиться к тому, как конфигурации и аннотации XML фактически используются какой-либо конкретной библиотекой (как и большинство предлагают оба), и какая аннотация используется. Я могу представить, что аннотации, определяющие что-то, что является специфическим для сборки (например, пути к файлу / URL-адресам), на самом деле могут быть проще в качестве конфигурации XML.
Я лично считаю, что упомянутый вами конкретный вариант использования (автоматическое создание веб-форм) является отличным вариантом использования аннотаций. Я думаю, что идеальным вариантом использования аннотаций является любой сценарий «фреймворка», в котором вы можете написать упрощенный код и позволить фреймворку выполнять тяжелую (часто повторяющуюся) работу на основе нескольких предложений (также называемых аннотациями).
i Мне любопытно, почему вам не нравятся аннотации в этой ситуации, и что вы считаете «бременем обслуживания»? (и я не пытаюсь оскорбить вашу позицию, просто поймите это).
Это сильно зависит от поддержки IDE. Я считаю, что аннотации должны синхронизироваться с кодом с помощью проверок в IDE, но эта поддержка несколько не хватает.
Например,более старая версия IDEA будет предупреждать, если вы отменяете функцию без @Override, но не удаляла бы тег @Override, если вы изменили подпись метода (или подпись суперкласса, если на то пошло) и разорвали связь.
Без поддержка Я считаю их обременительным способом добавлять метаданные в код.