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

Question

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

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

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

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

Удачные выходные.

Джейк

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

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

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

Answer 1

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

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

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

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

Это на самом деле довольно распространено, особенно если объект будет управляемый кодом, который не знает априори объект, с которым он будет манипулировать (посмотрите на пример Hibernate).

Answer 2

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

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

Answer 3

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

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

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

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

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

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