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

1. Огляд

У цьому короткому навчальному посібнику ми дослідимо визначення поняття "Звичайний старий об'єкт Java" або коротше POJO.

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

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, оскільки він не прив’язаний до жодного середовища.

Але ми не дотримуємось жодної реальної конвенції щодо побудови, доступу або зміни стану класу.

Ця відсутність конвенції викликає дві проблеми:

По-перше, це збільшує криву навчання для програмістів, які намагаються зрозуміти, як ним користуватися.

По-друге, це може обмежити здатність фреймворку надавати перевагу конвенції над конфігурацією, розуміти, як використовувати клас, і збільшувати його функціональність.

Щоб дослідити цей другий момент, давайте працюватимемо з EmployeePojo, використовуючи рефлексію. Таким чином, ми почнемо знаходити деякі його обмеження.

2.2. Роздум за допомогою POJO

Давайте додамо Вікісховища BeanUtils залежність нашого проекту:

 commons-beanutils commons-beanutils 1.9.4 

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

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

Якби ми роздруковували propertyNames на консолі, ми побачили б лише:

[start] 

Тут ми бачимо, що стартуємо лише як властивість класу. PropertyUtils не вдалося знайти інші два.

Ми побачили б такий самий результат, якби ми використовували інші бібліотеки, такі як Джексон, для обробки EmployeePojo.

В ідеалі ми бачили б усі наші властивості: firstName , lastName і startDate. І хороша новина полягає в тому, що багато бібліотек Java підтримують за замовчуванням щось, що називається Конвенцією іменування JavaBean.

3. JavaBeans

3.1. Що таке JavaBean ?

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

  • Рівні доступу - наші властивості приватні, і ми виставляємо геттери та сетери
  • Імена методів - наші методи отримання і установки слідують GetX і Setx конвенції (в разі булево, ISX може використовуватися для геттер)
  • Конструктор за замовчуванням - повинен бути присутній конструктор без аргументів, щоб екземпляр можна було створити без надання аргументів, наприклад під час десеріалізації
  • Серіалізація - реалізація інтерфейсу Серіалізація дозволяє нам зберігати стан

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

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

[firstName, lastName, startDate]

4. Компроміси при використанні JavaBeans

Отже, ми показали, як JavaBeans є корисним. Майте на увазі, що кожен вибір дизайну має компроміси.

Коли ми використовуємо JavaBeans, ми також повинні пам’ятати про деякі потенційні недоліки:

  • Змінюваність - наші JavaBeans змінні завдяки своїм методам встановлення - це може призвести до проблем одночасності або узгодженості
  • Панель - ми повинні ввести геттери для всіх властивостей, а сетери для більшості, багато з цього може бути непотрібним
  • Конструктор нульового аргументу - нам часто потрібні аргументи в наших конструкторах, щоб забезпечити екземпляр об’єкта у допустимому стані, але стандарт JavaBean вимагає від нас конструктора нульового аргументу

З огляду на ці компроміси, рамки також адаптувались до інших конвенцій про боби протягом багатьох років.

5. Висновок

У цьому посібнику ми порівняли POJO з JavaBeans.

По-перше, ми дізналися, що POJO - це об’єкт Java, який не пов’язаний з певною структурою, і що JavaBean - це особливий тип POJO із суворим набором умов.

Потім ми побачили, як деякі фреймворки та бібліотеки використовують механізм іменування JavaBean для виявлення властивостей класу.

Як зазвичай, приклади доступні на GitHub.