Wat is een POJO-les?

1. Overzicht

In deze korte tutorial, we zullen de definitie van "gewoon oud Java-object" onderzoeken of kortweg POJO.

We zullen bekijken hoe een POJO zich verhoudt tot een JavaBean, en hoe het nuttig kan zijn om onze POJO's om te zetten in JavaBeans.

2. Gewone oude Java-objecten

2.1. Wat is een POJO?

Als we het hebben over een POJO, dan is wat we beschrijven een rechttoe rechtaan type zonder verwijzingen naar bepaalde frameworks. Een POJO heeft geen naamgevingsconventie voor onze eigenschappen en methoden.

Laten we een basis POJO voor werknemers maken. Het zal drie eigenschappen hebben; voornaam, achternaam en startdatum:

openbare klasse EmployeePojo {public String firstName; openbare tekenreeks achternaam; privé LocalDate startDate; openbare EmployeePojo (String firstName, String lastName, LocalDate startDate) {this.firstName = firstName; this.lastName = achternaam; this.startDate = startDate; } public String name () {retourneer this.firstName + "" + this.lastName; } openbare LocalDate getStart () {retourneer this.startDate; }}

Deze klasse kan door elk Java-programma worden gebruikt, omdat het niet aan een raamwerk is gekoppeld.

Maar we volgen geen echte conventie voor het construeren, openen of wijzigen van de status van de klasse.

Dit gebrek aan conventie veroorzaakt twee problemen:

Ten eerste vergroot het de leercurve voor codeerders die proberen te begrijpen hoe ze het moeten gebruiken.

Tweede, het kan het vermogen van een raamwerk beperken om de voorkeur te geven aan conventie boven configuratie, te begrijpen hoe de klasse moet worden gebruikt en de functionaliteit ervan te vergroten.

Laten we, om dit tweede punt te onderzoeken, aan de slag gaan met Medewerker Pojo met behulp van reflectie. Daarom zullen we enkele van zijn beperkingen gaan ontdekken.

2.2. Reflectie met een POJO

Laten we de commons-beanutils afhankelijkheid naar ons project:

 commons-beanutils commons-beanutils 1.9.4 

En laten we nu de eigenschappen van onze POJO bekijken:

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

Als we zouden afdrukken propertyNames op de console zouden we alleen zien:

[begin] 

Hier zien we dat we alleen krijgen begin als een eigenschap van de klas. PropertyUtils kon de andere twee niet vinden.

We zouden hetzelfde soort resultaat zien als we andere bibliotheken zoals Jackson zouden gebruiken om te verwerken Medewerker Pojo.

Idealiter zouden we al onze eigendommen zien: Voornaam, achternaam, en startdatum. En het goede nieuws is dat veel Java-bibliotheken standaard de zogenaamde JavaBean-naamgevingsconventie ondersteunen.

3. JavaBeans

3.1. Wat is een JavaBean?

Een JavaBean is nog steeds een POJO, maar introduceert een strikte set regels voor hoe we het implementeren:

  • Toegangsniveaus - onze eigendommen zijn privé en we stellen getters en setters bloot
  • Methodenamen - onze getters en setters volgen de getX en setX conventie (in het geval van een boolean, isX kan worden gebruikt voor een getter)
  • Default Constructor - een constructor zonder argument moet aanwezig zijn zodat een instantie kan worden gemaakt zonder argumenten op te geven, bijvoorbeeld tijdens deserialisatie
  • Serialiseerbaar - implementatie van het Serialiseerbaar interface stelt ons in staat om de staat op te slaan

3.2. Medewerker Pojo als een JavaBean

Laten we dus proberen om te converteren Medewerker Pojo in een JavaBean:

public class EmployeeBean implementeert Serializable {private static final long serialVersionUID = -3760445487636086034L; private String voornaam; private String achternaam; privé LocalDate startDate; openbare EmployeeBean () {} openbare EmployeeBean (String firstName, String lastName, LocalDate startDate) {this.firstName = firstName; this.lastName = achternaam; this.startDate = startDate; } public String getFirstName () {return firstName; } public void setFirstName (String firstName) {this.firstName = firstName; } // extra getters / setters}

3.3. Reflectie met een JavaBean

Als we onze boon met reflectie inspecteren, krijgen we nu de volledige lijst met eigenschappen:

[voornaam, achternaam, startdatum]

4. Afwegingen bij het gebruik van JavaBeans

We hebben dus een manier laten zien waarop JavaBeans nuttig zijn. Houd er rekening mee dat elke ontwerpkeuze gepaard gaat met afwegingen.

Wanneer we JavaBeans gebruiken, moeten we ook rekening houden met enkele mogelijke nadelen:

  • Veranderlijkheid - onze JavaBeans zijn veranderlijk vanwege hun setter-methoden - dit kan leiden tot problemen met gelijktijdigheid of consistentie
  • Boilerplate - we moeten getters introduceren voor alle eigendommen en setters voor de meeste, veel hiervan is misschien niet nodig
  • Constructor zonder argumenten - we hebben vaak argumenten nodig in onze constructors om ervoor te zorgen dat het object in een geldige staat wordt geïnstantieerd, maar de JavaBean-standaard vereist dat we een constructor met nulargumenten opgeven

Gezien deze afwegingen hebben kaders zich in de loop der jaren ook aangepast aan andere bonenconventies.

5. Conclusie

In deze tutorial hebben we POJO's vergeleken met JavaBeans.

Ten eerste hebben we geleerd dat een POJO een Java-object is dat aan geen specifiek raamwerk is gebonden, en dat een JavaBean een speciaal type POJO is met een strikte set conventies.

Vervolgens zagen we hoe sommige frameworks en bibliotheken gebruikmaken van de JavaBean-naamgevingsconventie om de eigenschappen van een klasse te ontdekken.

Zoals gewoonlijk zijn de voorbeelden beschikbaar op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found