Was ist eine POJO-Klasse?

1. Übersicht

In diesem kurzen Tutorial untersuchen wir die Definition von "Plain Old Java Object" oder kurz POJO.

Wir werden uns ansehen, wie ein POJO mit einer JavaBean verglichen wird und wie hilfreich es sein kann, unsere POJOs in JavaBeans umzuwandeln.

2. Einfache alte Java-Objekte

2.1. Was ist ein POJO ?

Wenn wir über ein POJO sprechen, beschreiben wir einen einfachen Typ ohne Verweise auf bestimmte Frameworks. Ein POJO hat keine Namenskonvention für unsere Eigenschaften und Methoden.

Lassen Sie uns ein einfaches Mitarbeiter-POJO erstellen. Es wird drei Eigenschaften haben; Vorname, Nachname und Startdatum:

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

Diese Klasse kann von jedem Java-Programm verwendet werden, da sie nicht an ein Framework gebunden ist.

Wir folgen jedoch keiner wirklichen Konvention zum Erstellen, Zugreifen auf oder Ändern des Status der Klasse.

Dieser Mangel an Konvention verursacht zwei Probleme:

Erstens erhöht es die Lernkurve für Codierer, die versuchen zu verstehen, wie man es verwendet.

Zweitens kann dies die Fähigkeit eines Frameworks einschränken, Konventionen gegenüber Konfigurationen zu bevorzugen, die Verwendung der Klasse zu verstehen und ihre Funktionalität zu erweitern.

Um diesen zweiten Punkt zu untersuchen, arbeiten wir mit EmployeePojo mithilfe von Reflection. Daher werden wir einige seiner Einschränkungen entdecken.

2.2. Reflexion mit einem POJO

Lassen Sie uns das Hinzufügen commons-Beanutils Abhängigkeit zu unserem Projekt:

 commons-beanutils commons-beanutils 1.9.4 

Lassen Sie uns nun die Eigenschaften unseres POJO untersuchen:

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

Wenn wir propertyNames auf der Konsole ausdrucken würden , würden wir nur sehen:

[start] 

Hier sehen wir, dass wir nur als Eigenschaft der Klasse anfangen . PropertyUtils konnte die beiden anderen nicht finden.

Wir würden das gleiche Ergebnis sehen, wenn wir andere Bibliotheken wie Jackson verwenden würden, um EmployeePojo zu verarbeiten .

Im Idealfall werden alle unsere Eigenschaften angezeigt : Vorname , Nachname und Startdatum. Und die gute Nachricht ist, dass viele Java-Bibliotheken standardmäßig die sogenannte JavaBean-Namenskonvention unterstützen.

3. JavaBeans

3.1. Was ist eine JavaBean ?

Eine JavaBean ist immer noch ein POJO, führt jedoch strenge Regeln für die Implementierung ein:

  • Zugangsebenen - unsere Immobilien sind privat und wir setzen Getter und Setter aus
  • Methodennamen - Unsere Getter und Setter folgen der getX- und setX- Konvention (im Fall eines Booleschen Werts kann isX für einen Getter verwendet werden).
  • Standardkonstruktor - Ein Konstruktor ohne Argumente muss vorhanden sein, damit eine Instanz ohne Angabe von Argumenten erstellt werden kann, z. B. während der Deserialisierung
  • Serializable - Durch die Implementierung der Serializable- Schnittstelle können wir den Status speichern

3.2. EmployeePojo als JavaBean

Versuchen wir also, EmployeePojo in eine JavaBean zu konvertieren :

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. Reflexion mit einer JavaBean

Wenn wir unsere Bohne mit Reflexion untersuchen, erhalten wir jetzt die vollständige Liste der Eigenschaften:

[firstName, lastName, startDate]

4. Kompromisse bei der Verwendung von JavaBeans

Wir haben also gezeigt, wie JavaBeans hilfreich sind. Denken Sie daran, dass jede Designauswahl mit Kompromissen verbunden ist.

Wenn wir JavaBeans verwenden, sollten wir auch einige mögliche Nachteile berücksichtigen:

  • Wandelbarkeit - unsere Java Beans sind wandelbar aufgrund ihrer Setter - Methoden - diese in der Parallelität oder Konsistenzprobleme führen könnten
  • Boilerplate - wir müssen Getter für alle Eigenschaften und Setter für die meisten einführen, vieles davon könnte unnötig sein
  • Null-Argument-Konstruktor - Wir benötigen häufig Argumente in unseren Konstruktoren, um sicherzustellen, dass das Objekt in einem gültigen Zustand instanziiert wird. Der JavaBean-Standard verlangt jedoch, dass wir einen Null-Argument-Konstruktor bereitstellen

Angesichts dieser Kompromisse haben sich die Rahmenbedingungen im Laufe der Jahre auch an andere Bohnenkonventionen angepasst.

5. Schlussfolgerung

In diesem Tutorial haben wir POJOs mit JavaBeans verglichen.

Zuerst haben wir gelernt, dass ein POJO ein Java-Objekt ist, das an kein bestimmtes Framework gebunden ist, und dass eine JavaBean ein spezieller POJO-Typ mit strengen Konventionen ist.

Dann haben wir gesehen, wie einige Frameworks und Bibliotheken die JavaBean-Namenskonvention nutzen, um die Eigenschaften einer Klasse zu ermitteln.

Wie üblich sind die Beispiele auf GitHub verfügbar.