Рубрики
Без рубрики

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

Знание разницы между POJO и JavaBean может быть ключом к раскрытию потенциала наших классов в ядре Java.

Автор оригинала: baeldung.

1. Обзор

В этом коротком уроке мы рассмотрим определение “Простого старого объекта Java” или POJO для краткости.

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

2. Простые Старые объекты Java

2.1. Что такое POJO?

Когда мы говорим о 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, так как он не привязан ни к какому фреймворку.

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

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

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

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

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

2.2. Отражение с помощью POJO

Давайте добавим | commons-beanutils зависимость в наш проект: 


    commons-beanutils
    commons-beanutils
    1.9.4

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

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

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

[start]

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

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

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

3. JavaBeans

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

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

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

3.2. EmployeePojo как JavaBean

Итак, давайте попробуем преобразовать Employee Pojo в 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

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

[firstName, lastName, startDate]

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

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

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

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

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

5. Заключение

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

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

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

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

Читайте ещё по теме: