Pull to refresh

Comments 32

Атрибуты в C# немного удобнее и проще, как по мне… За статью спасибо!
Все разработчики на Java дружно рады за вас!
А было бы интересно провести сравнительный анализ аннотаций и атрибутов.
Спасибо за статью, как раз изучаю Java и не понимал, что это, и зачем они нужны.

P.S. заключите код в тег source, а то сливается с текстом ;)
спасибо, проглядел этот тег, поправил.
Спасибо, очень доходчиво обьяснили как работать с аннотациями. Ещё бы пару примеров для чего их стоит использоват в своих проектах, и для чего лучше не недо.
Если кратко, то аннотации — это метаданные на уровне классов. Соответственно их используют, когда хотят вынести часть конфигурации непосредственно в код (как например в Spring и Hibernate), для декларативной валидации бинов (см. например здесь).
В GWT аннотации активно используются в механизме локализации сообщений и привязки контролов к разметке в UiBinder.

Еще один вариант кастомного использования — документирование. Например, у вас в руках есть сущности Hibernate и вы хотите с помощью hbm2doc документировать вашу БД. Вы можете зарегистрировать свою аннотацию @Documentation(""), навесить ее на интересующие поля в entity-классах и написать свой хук для этого экспортера, который будет сканировать классы на наличие аннотации.
как доку прочитал. На мой взгляд такие статью надо писать с примерами посочнее.
Посыпая голову пеплом, прочтя всё, что только возможно, но я так и не понял, ДЛЯ ЧЕГО нужны аннотации в Java.
(Бросил Java за то, что язык стал другим и непонятным)
Может Цейлон Вас заинтересует :)
В рантайме — для более простого маппинга данных/связывания объектов. Ну и аспекты потом прикрутили.
Интроспекция изначально считалось худшим, что возможно в ООП. Это нарушение принципов инкапсуляции ради эффективности. Если эффективность не может быть достигнута средствами ООП, то нужно просто брать и использовать другой язык, а не искажать объективную реальность данного.
Это теория. На практике AspectJ менее удобен, чем Spring AOP.
Кем считалась? Интроспекция интроспекции рознь. Вот, например, контракт JavaBeans нарушает принципы инкапсуляции?
Например, можно использовать @Nullable и @NotNull для контроля значения полей. В IntelliJ IDEA очень на этот счет удобно — автоматические инспекции проверяют, может ли код отдать null и если аннотации совсем нет или указана @NotNull — будет показано нарушение такой-то инспекции, подсвечен подозрительный кусок.

Знаю об удобных инспекциях времени выполнения @ElementsNotNull для коллекций.
@MinValue и @MaxValue — или что-то близкое, — для контроля числовых значений.

В JUnit аннотации используются для отметки функций-тестов (@Test), правил (@Rule), группировки тестов в пакеты.
В общем, как видим, аннотациям можно придумать очень много интересных применений: метаданных очень удобная штука.
Я когда эти @Nullable разрешил поставить в идее, она для этого подключила свой какой-то пакет. А мне почему-то не сильно нравится, когда IDE подключают свои либы. Переносимость на другие IDE становится тогда не шибко приятной. В команде работают как на NetBeans, Eclipse так и на Idea. Стараюсь бить по рукам, когда вижу зависимость от каких либо либ этих IDE. С развитием Мавена эта проблема конечно не так остра, но лично мне режет глаза, когда такие зависимости вижу.
этот самый пакет, а именно annotations.jar, успешно присутствует в мавен репозитории и его можно просто подлючить и не насиловать свои глаза.
есть jsr 305 jcp.org/en/jsr/detail?id=305
там описаны все эти @Nullable. По стандарту они лежат в javax.annotation, распознаются идеей, и наверное эклипсом тоже. Вполне универсальное средство на все IDE.
ага, и она соответственно зависит уже от пакета эклипса.
В настройках Eclipse можно прописать полные имена аннотаций для null и not-null, взятых из любой библиотеки. Так что хоть по JSR.
много для чего они нужны,
например сравните работы со стеком JEE технологий до того, как были введены в язык аннотации и после.
Что быстрее будет сделать, и чревато меньшим количество ошибок разработчика (даже из-за невнимательности),
делать xml файлы для конфигурирования бинов, или же просто заанотировать класс и нужные его поля?

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

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

Раньше метаданные описывались отдельно от кода жуткими простынями xml. Было неудобно, но правильно. Затем изобрели XDoclet, который позволял прописывать метаданные прямо в коде при помощи специальных комментариев, а затем генерировал XML. Затем посчитали это полезным и решили ввести эту фишку прямо в язык ввиде аннотаций. Это удобно, но неправильно с точки зрения теории — код становится «завязан» на контейнер/фреймворк.

Я думаю, лучшим способом будет отказаться от конфигурации контейнера аннотациями и делать это на Java при помощи DSL. Например так делает Guice. В Scala есть интересная ORM Squeryl, которая использует схожий подход. Подобная ORM на Java называется QueryDSL.

P.S. Любителям аннотаций задача: есть модель данных и соответвующие ей джава бины. Нужно: с одной стороны замепить эту модель в базу данных, с другой — сделать вебсервис, работающий с ней. Все при условии, что код модели не дублировать. О том как подружить JPA и JAXB читайте на лучших девелоперских форумах… ))
UFO just landed and posted this here
UFO just landed and posted this here
мне показалось что так лучше будет читаться, чисто на глаз для восприятия,
так что не вижу ничего страшного в таком коде, с учетом того, что это просто пример
Вообще это считается моветоном: неоптимальный и бессмысленный код только загромождает место. Да и по смыслу получается масло маслянное.
вынужден согласиться про масло масляное,
поправил, спасибо.
В статье слабо освещены варианты использования аннотаций.
IMHO, имеет смысл добавить несколько примеров (вкратце), как они используются в современных framework'ах.
Sign up to leave a comment.

Articles

Change theme settings