Hvad er en POJO-klasse?

1. Oversigt

I denne korte vejledning vi undersøger definitionen af ​​“Almindeligt gammelt Java-objekt” eller POJO for kort.

Vi ser på, hvordan en POJO sammenligner med en JavaBean, og hvordan det kan være nyttigt at omdanne vores POJO'er til JavaBeans.

2. Almindelige gamle Java-objekter

2.1. Hvad er en POJO?

Når vi taler om en POJO, er det, vi beskriver, en ligetil type uden henvisninger til bestemte rammer. En POJO har ingen navngivningskonvention for vores egenskaber og metoder.

Lad os oprette en grundlæggende medarbejder POJO. Det har tre egenskaber; fornavn, efternavn og startdato:

offentlig klasse EmployeePojo {public String firstName; offentlig streng efternavn; privat LocalDate startDate; public EmployeePojo (String firstName, String lastName, LocalDate startDate) {this.firstName = firstName; this.lastName = efternavn; this.startDate = startDate; } offentligt strengnavn () {returner this.firstName + "" + this.lastName; } offentlig LocalDate getStart () {returner this.startDate; }}

Denne klasse kan bruges af ethvert Java-program, da det ikke er bundet til nogen ramme.

Men vi følger ikke nogen reel konvention til at konstruere, få adgang til eller ændre klassens tilstand.

Denne manglende konvention skaber to problemer:

For det første øger det indlæringskurven for kodere, der prøver at forstå, hvordan man bruger den.

Sekund, det kan begrænse en rammes evne til at favorisere konvention frem for konfiguration, forstå hvordan klassen bruges og udvide dens funktionalitet.

For at udforske dette andet punkt, lad os arbejde med MedarbejderPojo ved hjælp af refleksion. Således begynder vi at finde nogle af dens begrænsninger.

2.2. Refleksion med en POJO

Lad os tilføje commons-beanutils afhængighed til vores projekt:

 commons-beanutils commons-beanutils 1.9.4 

Og nu, lad os inspicere egenskaberne af vores POJO:

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

Hvis vi skulle udskrive propertyNames til konsollen, ville vi kun se:

[Start] 

Her ser vi, at vi kun får Start som en egenskab for klassen. PropertyUtils kunne ikke finde de to andre.

Vi ville se det samme resultat, hvis vi brugte andre biblioteker som Jackson til at behandle MedarbejderPojo.

Ideelt set ville vi se alle vores ejendomme: fornavn, efternavn, og start dato. Og den gode nyhed er, at mange Java-biblioteker som standard understøtter noget, der kaldes JavaBean-navngivningskonventionen.

3. JavaBeans

3.1. Hvad er en JavaBean?

En JavaBean er stadig en POJO, men introducerer et strengt sæt regler omkring, hvordan vi implementerer det:

  • Adgangsniveauer - vores ejendomme er private, og vi udsætter getters og settere
  • Metodenavne - vores getters og settere følger getX og sætX konvention (i tilfælde af en boolsk, isX kan bruges til en getter)
  • Standardkonstruktør - en konstruktør uden argument skal være til stede, så en instans kan oprettes uden at give argumenter, for eksempel under deserialisering
  • Serialiserbar - implementering af Serialiserbar interface giver os mulighed for at gemme staten

3.2. MedarbejderPojo som en JavaBean

Så lad os prøve at konvertere MedarbejderPojo ind i en JavaBean:

offentlig klasse EmployeeBean implementerer Serialiserbar {privat statisk endelig lang serialVersionUID = -3760445487636086034L; privat streng fornavn; privat streng efternavn; privat LocalDate startDate; public EmployeeBean () {} public EmployeeBean (String firstName, String lastName, LocalDate startDate) {this.firstName = firstName; this.lastName = efternavn; this.startDate = startDate; } offentlig streng getFirstName () {return firstName; } public void setFirstName (String firstName) {this.firstName = firstName; } // yderligere getters / setters}

3.3. Refleksion med en JavaBean

Når vi inspicerer vores bønne med refleksion, får vi nu den fulde liste over egenskaberne:

[fornavn, efternavn, startdato]

4. Afvejninger ved brug af JavaBeans

Så vi har vist en måde, hvorpå JavaBeans er nyttige. Husk, at ethvert designvalg kommer med kompromiser.

Når vi bruger JavaBeans, skal vi også være opmærksomme på nogle potentielle ulemper:

  • Ændring - vores JavaBeans er mutable på grund af deres settermetoder - dette kan føre til problemer med samtidighed eller konsistens
  • Kedelplade - vi skal introducere getters til alle ejendomme og settere for de fleste, meget af dette kan være unødvendigt
  • Nul argumentkonstruktør - vi har ofte brug for argumenter i vores konstruktører for at sikre, at objektet bliver instantieret i en gyldig tilstand, men JavaBean-standarden kræver, at vi leverer en nul-argument-konstruktør

I betragtning af disse kompromiser har rammerne også tilpasset andre bønnekonventioner gennem årene.

5. Konklusion

I denne vejledning sammenlignede vi POJO'er med JavaBeans.

For det første lærte vi, at en POJO er et Java-objekt, der ikke er bundet til nogen specifik ramme, og at en JavaBean er en særlig type POJO med et strengt sæt konventioner.

Derefter så vi, hvordan nogle rammer og biblioteker udnytter JavaBean-navngivningskonventionen for at opdage en klasses egenskaber.

Som sædvanligt er eksemplerne tilgængelige på GitHub.


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