Co to jest klasa POJO?

1. Przegląd

W tym krótkim tutorialu przyjrzymy się definicji „zwykłego starego obiektu Java” lub w skrócie POJO.

Przyjrzymy się, jak POJO porównuje się z JavaBean i jak pomocne może być przekształcenie naszych POJO w JavaBeans.

2. Zwykłe stare obiekty Java

2.1. Co to jest POJO ?

Kiedy mówimy o POJO, to, co opisujemy, jest prostym typem bez odniesień do żadnych konkretnych frameworków. POJO nie ma konwencji nazewnictwa naszych właściwości i metod.

Stwórzmy podstawowego pracownika POJO. Będzie miał trzy właściwości; imię, nazwisko i data rozpoczęcia:

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; } }

Ta klasa może być używana przez dowolny program Java, ponieważ nie jest powiązana z żadną strukturą.

Ale nie przestrzegamy żadnej prawdziwej konwencji konstruowania, uzyskiwania dostępu lub modyfikowania stanu klasy.

Ten brak konwencji powoduje dwa problemy:

Po pierwsze, zwiększa krzywą uczenia się dla programistów próbujących zrozumieć, jak go używać.

Po drugie, może ograniczyć zdolność frameworka do faworyzowania konwencji nad konfiguracją, zrozumienia, jak używać klasy i rozszerzać jej funkcjonalność.

Aby zbadać ten drugi punkt, popracujmy z EmployeePojo przy użyciu refleksji. Dlatego zaczniemy odkrywać niektóre z jego ograniczeń.

2.2. Odbicie z POJO

Dodajmy do naszego projektu zależność commons-beanutils :

 commons-beanutils commons-beanutils 1.9.4 

A teraz sprawdźmy właściwości naszego POJO:

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

Gdybyśmy mieli wydrukować nazwy właściwości na konsoli, zobaczylibyśmy tylko:

[start] 

Tutaj widzimy, że tylko się uruchomić jako właściwość klasy. PropertyUtils nie znalazł pozostałych dwóch.

Zobaczylibyśmy taki sam rezultat, gdybyśmy użyli innych bibliotek, takich jak Jackson, do przetwarzania EmployeePojo.

Idealnie byłoby, gdybyśmy zobaczyli wszystkie nasze właściwości: firstName , lastName i startDate. Dobra wiadomość jest taka, że ​​wiele bibliotek Java domyślnie obsługuje coś, co nazywa się konwencją nazewnictwa JavaBean.

3. JavaBeans

3.1. Co to jest JavaBean ?

JavaBean nadal jest POJO, ale wprowadza ścisły zestaw reguł dotyczących tego, jak go implementujemy:

  • Poziomy dostępu - nasze właściwości są prywatne i udostępniamy metody pobierające i ustawiające
  • Nazwy metod - nasze pobierające i ustawiające śledzić getX i setX konwencję (w przypadku wartości logicznej, ISX mogą być wykorzystywane do getter)
  • Konstruktor domyślny - musi istnieć konstruktor bez argumentów, aby można było utworzyć instancję bez podawania argumentów, na przykład podczas deserializacji
  • Serializable - implementacja interfejsu Serializable pozwala nam przechowywać stan

3.2. EmployeePojo jako JavaBean

Spróbujmy więc przekonwertować EmployeePojo na 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. Odbicie z JavaBean

Kiedy przyjrzymy się naszej fasoli z odbiciem, otrzymamy teraz pełną listę właściwości:

[firstName, lastName, startDate]

4. Tradeoffs When Using JavaBeans

So, we've shown a way in which JavaBeans are helpful. Keep in mind that every design choice comes with tradeoffs.

When we use JavaBeans we should also be mindful of some potential disadvantages:

  • Mutability – our JavaBeans are mutable due to their setter methods – this could lead to concurrency or consistency issues
  • Boilerplate – we must introduce getters for all properties and setters for most, much of this might be unnecessary
  • Zero-argument Constructor – we often need arguments in our constructors to ensure the object gets instantiated in a valid state, but the JavaBean standard requires us to provide a zero-argument constructor

Given these tradeoffs, frameworks have also adapted to other bean conventions over the years.

5. Conclusion

W tym samouczku porównaliśmy POJO z JavaBeans.

Po pierwsze, dowiedzieliśmy się, że POJO to obiekt Java, który nie jest powiązany z żadną określoną strukturą, oraz że JavaBean jest specjalnym typem POJO ze ścisłym zestawem konwencji.

Następnie zobaczyliśmy, jak niektóre frameworki i biblioteki wykorzystują konwencję nazewnictwa JavaBean do odkrywania właściwości klasy.

Jak zwykle przykłady są dostępne na GitHub.