Java-бины, аннотации: что они делают? Как они мне помогают?

Question

Вот что я понимаю до сих пор:

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

Java-бины имеют методы получения и установки (плохая практика ООП) и являются сериализуемыми.

Что касается аннотаций, я думаю, что пользовательские аннотации не предоставляют никакой функциональности. Некоторые аннотации, такие как @depretiated, вызывают предупреждения компилятора. Могут ли пользовательские аннотации сделать это как-нибудь? Являются ли пользовательские аннотации хорошими для чего-либо, кроме документации? Как я могу их использовать? Есть ли у eclipse или intellij особенность, которая включает аннотации?

Хороших выходных.

Джейк

Обновление: , которое начинает приобретать больше смысла. Может ли кто-нибудь отослать меня к примеру, когда было бы целесообразно использовать формат Java-бина, а когда нет?

Также я где-то читал, что несколько классов могут быть бином, и это способ упаковки классов.

Просто чтобы прояснить еще одну вещь. Я на 95% уверен, что быть Java-бином - это как синглтон (или другой шаблон). Это не влияет на то, что делает компилятор.

Answer 1

Аннотации являются формой декларативного программирования . Во-первых, вы должны воспользоваться преимуществами декларативного программирования, прежде чем станет понятной полезность аннотаций. По сути, вы можете добавить функциональность или поведение в блок кода, просто «объявив», что он имеет определенную характеристику. Это отличается от фактического написания серии утверждений для применения или настройки одинакового поведения.

Аннотации JPA являются примером добавления функциональности с аннотациями. Я не знаю, как "пользователь создал" пример из головы, но аннотации JPA реализованы точно так же, как вы или я бы сделал это.

Что касается Java Beans, то первоначально они использовались для GUI-программирования. «Легким» способом использования JavaBeans было использование соглашений об именах для определения «атрибутов» бина - следовательно, получателей и установщиков. Насколько я знаю, JavaBeans изначально были реализацией для редактирования форм и пользовательского интерфейса на основе графического интерфейса. Таким образом, методы получения и установки позволяют программному интерфейсу легко находить видимые для пользователя или редактируемые атрибуты. С помощью Bean Descriptor вы можете немного изменить работу дескрипторов ...

Причина, по которой они сохраняются по сей день, заключается в том, что они предоставляют фактический способ осмотра объектов на предмет публично выставленных свойств. Неплохо использовать JavaBeans вне GUI. Кажется, в Java предпочтение отдается использованию конструктора no arg, а затем внедряет ваши зависимости, а не в стиле программирования RAII (не то, чтобы он был строго доступен) ...

На самом деле это довольно часто, особенно если объект будет манипулировать кодом, который априори не знает объект, которым он будет манипулировать (посмотрите на Hibernate для хорошего примера).

Answer 2

Я подозреваю, что вы путаете Java bean и EJB (Enterprise Java Beans) - это разные понятия. На самом деле они сейчас почти одинаковы, но так было не всегда - история довольно запутанная.

Джеймс дает хорошее объяснение истории Java-бинов - они намного старше аннотаций (которые были введены в Java 1.5). EJB также намного старше, но они были радикально пересмотрены и теперь в основном являются Java-бинами со специальными аннотациями, выполняемыми в контейнере EJB.

На самом деле это прекрасный пример того, насколько полезными могут быть аннотации.

EJB-компоненты "старого стиля" (до версии 3 спецификации) были ужасными для кода. Вам нужно было определить (IIRC) два интерфейса, один класс реализации (который фактически не реализовывал интерфейсы) и XML-дескриптор, который связал их вместе. И если вы где-нибудь делали опечатку, ошибки компилятора не было - просто загадочная ошибка времени выполнения, которая не помогла вам сузить проблему.

Почему это так? Потому что он позволял EJB-контейнеру контролировать, как был вызван фактический код реализации, и прозрачно выполнять такие вещи, как контроль доступа, транзакции и репликация.

В спецификации EJB 3.0 это было радикально упрощено, так что теперь вам нужен только один класс (который может быть «классическим» Java Bean в случае бинов сущностей), который фактически реализует логику EJB - и аннотации, которые скажите EJB-контейнеру, как с ним обращаться. Вместо отдельного XML-файла информация о коде находится рядом с самим кодом в том же файле, и поскольку синтаксис аннотации проверяется компилятором, во время компиляции обнаруживается много потенциальных ошибок.

Answer 3

JUnit использует аннотации начиная с версии 4 JUnit. Это пример пользовательских аннотаций. Вы добавляете @ Test-annotation к методу, и JUnit-инфраструктура распознает его и выполняет метод как тест.

Бины будут использоваться некоторыми средами для работы с неизвестными объектами. Вот примеры, которые мне приходят в голову - это персистентные фреймворки, которые дублируют некоторые зарегистрированные объекты в базы данных и используют для этого bean-свойства.