Java bean и pojo

Что такое класс POJO?

В этом кратком руководстве мы рассмотрим определение «Обычный старый объект Java» или сокращенно POJO.

Мы рассмотрим, как POJO сравнивается с JavaBean, и как может быть полезно преобразование наших POJO в JavaBeans.

2. Обычные старые объекты Java​

2.1. Что такое ПОЖО ?​

Когда мы говорим о POJO, мы описываем простой тип без ссылок на какие-либо конкретные фреймворки. POJO не имеет соглашения об именах для наших свойств и методов.

Давайте создадим базового сотрудника POJO. У него будет три свойства; имя, фамилия и дата начала:

 public class EmployeePojo     public String firstName;   public String lastName;   private LocalDate startDate;    public EmployeePojo(String firstName, String lastName, LocalDate startDate)    this.firstName = firstName;   this.lastName = lastName;   this.startDate = startDate;   >    public String name()    return this.firstName + " " + this.lastName;   >    public LocalDate getStart()    return this.startDate;   >   > 

Этот класс может использоваться любой программой Java, поскольку он не привязан к какой-либо структуре.

Но мы не следуем никакому реальному соглашению по созданию, доступу или изменению состояния класса.

Это отсутствие условности вызывает две проблемы:

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

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

Чтобы изучить этот второй момент, давайте поработаем с EmployeePojo , используя отражение. Таким образом, мы начнем находить некоторые из его ограничений.

2.2. Отражение с POJO​

 dependency>   groupId>commons-beanutilsgroupId>   artifactId>commons-beanutilsartifactId>   version>1.9.4version>   dependency> 

А теперь давайте проверим свойства нашего POJO:

 ListString> propertyNames =   PropertyUtils.getPropertyDescriptors(EmployeePojo.class).stream()   .map(PropertyDescriptor::getDisplayName)   .collect(Collectors.toList()); 

Если бы нам нужно было вывести в консоль имена свойств , мы бы увидели только:

Здесь мы видим, что мы получаем start только как свойство класса. PropertyUtils не удалось найти два других.

Мы бы увидели тот же результат, если бы использовали другие библиотеки, такие как Jackson , для обработки EmployeePojo.

В идеале мы должны увидеть все наши свойства: firstName , lastName и startDate. И хорошая новость заключается в том, что многие библиотеки Java по умолчанию поддерживают то, что называется соглашением об именах JavaBean.

3. JavaBeans​

3.1. Что такое JavaBean ?​

JavaBean по-прежнему является POJO, но вводит строгий набор правил его реализации:

• Уровни доступа — наши свойства являются частными, и мы выставляем геттеры и сеттеры
• Имена методов — наши геттеры и сеттеры следуют соглашению getX и setX (в случае логического значения isX может использоваться для геттера)
• Конструктор по умолчанию — должен присутствовать конструктор без аргументов, чтобы экземпляр можно было создать без предоставления аргументов, например, во время десериализации.
• Serializable — реализация интерфейса Serializable позволяет нам хранить состояние

3.2. EmployeePojo как JavaBean​

Итак, давайте попробуем преобразовать EmployeePojo в JavaBean:

 public class EmployeeBean implements Serializable     private static final long serialVersionUID = -3760445487636086034L;   private String firstName;   private String lastName;   private LocalDate startDate;    public EmployeeBean()    >    public EmployeeBean(String firstName, String lastName, LocalDate startDate)    this.firstName = firstName;   this.lastName = lastName;   this.startDate = startDate;   >    public String getFirstName()    return firstName;   >    public void setFirstName(String firstName)    this.firstName = firstName;   >    // additional getters/setters    > 

3.3. Отражение с помощью JavaBean​

Когда мы проверяем наш bean-компонент с отражением, мы получаем полный список свойств:

[firstName, lastName, startDate] 

4. Компромиссы при использовании JavaBeans​

Итак, мы показали, как полезны JavaBeans. Имейте в виду, что каждый выбор дизайна сопряжен с компромиссами.

Когда мы используем JavaBeans, мы также должны помнить о некоторых потенциальных недостатках:

• Изменяемость — наши JavaBeans изменяемы из-за их методов установки — это может привести к проблемам параллелизма или согласованности.
• Шаблон — мы должны ввести геттеры для всех свойств и сеттеры для большинства, многое из этого может быть ненужным.
• Конструктор без аргументов — нам часто нужны аргументы в наших конструкторах, чтобы убедиться, что экземпляр объекта создается в действительном состоянии, но стандарт JavaBean требует, чтобы мы предоставили конструктор без аргументов.

Учитывая эти компромиссы, фреймворки с годами также адаптировались к другим соглашениям о компонентах.

5. Вывод​

В этом руководстве мы сравнили POJO с JavaBeans.

Во-первых, мы узнали, что POJO — это объект Java, который не привязан ни к какой конкретной структуре, и что JavaBean — это особый тип POJO со строгим набором соглашений.

Затем мы увидели, как некоторые фреймворки и библиотеки используют соглашение об именах JavaBean для обнаружения свойств класса.

Как обычно, примеры доступны на GitHub .

Источник

Классы poji, pojo и Java Beans в Java

Является аббревиатурой от Plain Old Java Interface, который соответствует стандартному интерфейсу Java, что означает, что эти интерфейсы находятся в контексте предоставления услуг в JEE. Например, услуга OSGI предлагается через POJI в JEE

Другими словами, мы можем сказать, что POJI – это обычный интерфейс без какой-либо специальности, которая не унаследована от какого-либо специального API-интерфейса технологии или интерфейсов платформы.

Пример 1

interface myCustomInterface < public void myMethod(); >interface mySecondCustomInterface extends myCustomInterface

Оба интерфейса будут называться POJI, поскольку они не наследуют какой-либо технологический интерфейс.

Пример 2

interface GFG1 extends java.rmi.Remote < public void myMethod(); >interface GFG2 extends java.beans.AppletInitializer

Оба интерфейса не будут называться POJI, поскольку они наследуют специфический для технологии интерфейс.

POJO против Java Beans в Java

Как мы знаем, в Java POJO ссылается на простой старый объект Java. POJO и класс Bean в Java имеют некоторые общие черты, а именно:

• Оба класса должны быть общедоступными, т.е. доступными для всех.
• Свойства или переменные, определенные в обоих классах, должны быть закрытыми, то есть не могут быть доступны напрямую.
• Оба класса должны иметь конструктор по умолчанию, т.е. не иметь аргумента конструктора.
• Public Getter и Setter должны присутствовать в обоих классах для доступа к переменным / свойствам.

Единственное различие между обоими классами состоит в том, что Java делает объекты Java-бинов сериализованными, чтобы в случае необходимости можно было сохранить состояние класса бинов. Поэтому из-за этого класс Java-бинов должен реализовывать интерфейс Serializable или Externalizable.

В связи с этим указывается, что все JavaBean-компоненты являются POJO, но не все POJO-объекты являются JavaBean-компонентами.

Пример класса Java Bean

public class Employee implements java.io.Serializable < private int id; private String name; public Employee()<>public void setId(int id) public int getId() public void setName(String name) public String getName() >

Пример класса POJO

public class Employee < String name; public String id; private double salary; public Employee(String name, String id,double salary) < this.name = name; this.id = id; this.salary = salary; >public String getName() < return name; >public String getId() < return id; >public Double getSalary() < return salary; >>

Средняя оценка 4.4 / 5. Количество голосов: 7

Спасибо, помогите другим — напишите комментарий, добавьте информации к статье.

Видим, что вы не нашли ответ на свой вопрос.

Напишите комментарий, что можно добавить к статье, какой информации не хватает.

Источник