streamalism.org

1. Oversikt

I denne korte opplæringen, vi vil undersøke definisjonen av “Plain Old Java Object” eller POJO for kort.

Vi vil se på hvordan en POJO kan sammenlignes med en JavaBean, og hvordan det kan være nyttig å gjøre våre POJOer til JavaBeans.

2. Vanlige gamle Java-objekter

2.1. Hva er en POJO?

Når vi snakker om en POJO, er det vi beskriver en enkel type uten referanser til noen spesielle rammer. En POJO har ingen navnekonvensjon for våre egenskaper og metoder.

La oss lage en grunnleggende ansatt POJO. Den har tre egenskaper; fornavn, etternavn og startdato:

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

Denne klassen kan brukes av ethvert Java-program, da det ikke er bundet til noe rammeverk.

Men vi følger ikke noen reell konvensjon for å konstruere, få tilgang til eller endre klassens tilstand.

Denne mangelen på konvensjon gir to problemer:

For det første øker det læringskurven for kodere som prøver å forstå hvordan de skal brukes.

Sekund, det kan begrense et rammeverks evne til å favorisere konvensjon fremfor konfigurasjon, forstå hvordan du bruker klassen og øke funksjonaliteten.

For å utforske dette andre punktet, la oss jobbe med MedarbeiderPojo ved hjelp av refleksjon. Dermed begynner vi å finne noen av begrensningene.

2.2. Refleksjon med en POJO

La oss legge til commons-beanutils avhengighet til prosjektet vårt:

 commons-beanutils commons-beanutils 1.9.4 

Og nå, la oss inspisere egenskapene til vår POJO:

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

Hvis vi skulle skrive ut propertyNames til konsollen, ville vi bare se:

[start] 

Her ser vi at vi bare får start som en egenskap til klassen. PropertyUtils klarte ikke å finne de to andre.

Vi ville se det samme resultatet hvis vi brukte andre biblioteker som Jackson til å behandle MedarbeiderPojo.

Ideelt sett ville vi se alle eiendommene våre: fornavn, etternavn, og startdato. Og den gode nyheten er at mange Java-biblioteker som standard støtter noe som kalles JavaBean navngivningskonvensjon.

3. JavaBeans

3.1. Hva er en JavaBean?

En JavaBean er fortsatt en POJO, men introduserer et strengt sett med regler for hvordan vi implementerer det:

• Tilgangsnivåer - eiendommene våre er private, og vi utsetter getters og setters
• Metodenavn - våre getters og setters følger getX og setX konvensjon (i tilfelle boolsk, isX kan brukes til en getter)
• Standardkonstruktør - en konstruktør uten argument må være til stede slik at en forekomst kan opprettes uten å gi argumenter, for eksempel under deserialisering
• Serialiserbar - implementering av Serialiserbar grensesnitt lar oss lagre staten

3.2. MedarbeiderPojo som en JavaBean

Så, la oss prøve å konvertere MedarbeiderPojo inn i en JavaBean:

offentlig klasse EmployeeBean implementerer Serializable {private static final long serialVersionUID = -3760445487636086034L; privat streng fornavn; privat streng etternavn; privat LocalDate startdato; public EmployeeBean () {} public EmployeeBean (String fornavn, String etternavn, LocalDate startdato) {this.firstName = fornavn; this.lastName = etternavn; this.startDate = startdato; } offentlig streng getFirstName () {return firstName; } public void setFirstName (String firstName) {this.firstName = firstName; } // ekstra getters / setters}

3.3. Refleksjon med en JavaBean

Når vi inspiserer bønnen vår med refleksjon, får vi nå full liste over egenskapene:

[fornavn, etternavn, startdato]

4. Avveininger ved bruk av JavaBeans

Så vi har vist en måte som JavaBeans er nyttige. Husk at hvert designvalg kommer med kompromisser.

Når vi bruker JavaBeans, bør vi også være oppmerksom på noen potensielle ulemper:

• Mutabilitet - JavaBeans er mutable på grunn av deres settermetoder - dette kan føre til problemer med samtidighet eller konsistens
• Kjeleplate - vi må introdusere getters for alle eiendommer og settere for de fleste, mye av dette kan være unødvendig
• Nullargumentkonstruktør - vi trenger ofte argumenter i konstruktørene våre for å sikre at objektet blir instantiert i en gyldig tilstand, men JavaBean-standarden krever at vi gir en nullargumentkonstruktør

Gitt disse kompromissene, har rammeverk også tilpasset seg andre bønnekonvensjoner gjennom årene.

5. Konklusjon

I denne opplæringen sammenlignet vi POJO-er med JavaBeans.

Først lærte vi at en POJO er et Java-objekt som ikke er bundet av noe spesifikt rammeverk, og at en JavaBean er en spesiell type POJO med et strengt sett med konvensjoner.

Så så vi hvordan noen rammer og biblioteker utnytter navngivningskonvensjonen JavaBean for å oppdage egenskapene til en klasse.

Som vanlig er eksemplene tilgjengelige på GitHub.