streamalism.org

1. Áttekintés

Ebben a rövid bemutatóban megvizsgáljuk a „Plain Old Java Object” definícióját vagy röviden POJO.

Megvizsgáljuk, hogy a POJO hogyan viszonyul a JavaBean-hoz, és hogyan lehet hasznos a POJO-k JavaBean-vá alakítása.

2. Egyszerű régi Java objektumok

2.1. Mi az a POJO?

Amikor POJO-ról beszélünk, az általunk leírtak egyenes típusúak, semmilyen konkrét keretrendszerre nem hivatkozva. A POJO-nak nincs elnevezési szokása tulajdonságainkra és módszereinkre.

Hozzunk létre egy alap alkalmazott POJO-t. Három tulajdonsággal rendelkezik; keresztnév, vezetéknév és kezdő dátum:

public class EmployeePojo {public String keresztnév; public String vezetéknév; privát LocalDate startDate; public EmployeePojo (String keresztnév, String vezetéknév, LocalDate startDate) {this.firstName = keresztnév; this.lastName = vezetékNév; this.startDate = startDate; } public String name () {return this.firstName + "" + this.lastName; } public LocalDate getStart () {return this.startDate; }}

Ezt az osztályt bármely Java program használhatja, mivel nincs kötve egyetlen keretrendszerhez sem.

De nem követünk semmilyen valós megállapodást az osztály állapotának összeállításáról, eléréséről vagy módosításáról.

A konvenció hiánya két problémát okoz:

Először is, növeli a kódolók tanulási görbéjét, akik megpróbálják megérteni annak használatát.

Második, korlátozhatja a keretrendszer azon képességét, hogy előnyben részesítse a konvenciót a konfigurációval szemben, megértse, hogyan kell használni az osztályt, és bővíti annak funkcionalitását.

A második pont felfedezéséhez dolgozzunk együtt EmployeePojo reflexió segítségével. Így kezdjük megtalálni néhány korlátját.

2.2. Reflektálás POJO-val

Tegyük hozzá a közönséges-beanutil függőség projektünkhöz:

 commons-beanutils commons-beanutils 1.9.4 

Most pedig vizsgáljuk meg a POJO tulajdonságait:

List tulajdonságNév = PropertyUtils.getPropertyDescriptors (EmployeePojo.class) .stream () .map (PropertyDescriptor :: getDisplayName) .collect (Collectors.toList ());

Ha kinyomtatnánk propertyNames a konzolhoz csak a következőket láttuk:

[Rajt] 

Itt látjuk, hogy csak kapunk Rajt mint az osztály tulajdonsága. PropertyUtils nem találta a másik kettőt.

Ugyanilyen eredményt látnánk, ha más könyvtárakat is használnánk, mint például Jackson a feldolgozáshoz EmployeePojo.

Ideális esetben megnéznénk az összes tulajdonságunkat: keresztnév, vezetéknév, és kezdő dátum. És jó hír, hogy sok Java könyvtár alapértelmezés szerint támogat valamit, az úgynevezett JavaBean elnevezési megállapodást.

3. JavaBeans

3.1. Mi az a JavaBean?

A JavaBean még mindig POJO, de szigorú szabályrendszert vezet be annak végrehajtására vonatkozóan:

• Hozzáférési szintek - ingatlanjaink magántulajdonban vannak, és kitesszük a gettereket és a beállítókat
• Metódusnevek - a gettereink és beállítóink követik a getX és setX egyezmény (logikai érték esetén isX lehet használni a getter)
• Alapértelmezett konstruktor - egy argumentum nélküli konstruktornak jelen kell lennie, így egy példány argumentumok megadása nélkül is létrehozható, például deserializáció során
• Serializálható - a Sorosítható felület lehetővé teszi számunkra az állapot tárolását

3.2. EmployeePojo mint JavaBean

Tehát próbáljuk meg az átalakítást EmployeePojo JavaBean-ba:

public class EmployeeBean megvalósítja a Serializable {private static final long serialVersionUID = -3760445487636086034L; privát karakterlánc keresztnév; privát karakterlánc vezetéknév; privát LocalDate startDate; public EmployeeBean () {} public EmployeeBean (String keresztnév, String vezetéknév, LocalDate startDate) {this.firstName = keresztnév; this.lastName = vezetékNév; this.startDate = startDate; } public karakterlánc getFirstName () {return firstName; } public void setFirstName (String keresztnév) {this.firstName = keresztnév; } // további getterek / beállítók}

3.3. Tükrözés JavaBean-nal

Amikor reflexióval megvizsgáljuk a babunkat, most megkapjuk a tulajdonságok teljes listáját:

[keresztnév, vezetéknév, kezdési dátum]

4. Kompromisszumok a JavaBeans használatakor

Tehát bemutattuk a JavaBeans hasznos módját. Ne feledje, hogy minden tervezési választás kompromisszumokkal jár.

A JavaBeans használatakor figyelembe kell venni néhány lehetséges hátrányt is:

• Változtathatóság - JavaBeanjaink szetteres módszereik miatt módosíthatók - ez párhuzamossági vagy konzisztencia-problémákhoz vezethet
• Kazán - be kell vezetnünk az összes tulajdonságra vonatkozó gettert, a legtöbbre pedig a beállítókat, ezek nagy része felesleges lehet
• Nulla argumentumú konstruktor - gyakran szükségünk van argumentumokra a konstruktőreinkben annak biztosítására, hogy az objektum érvényes állapotban legyen példányos, de a JavaBean szabvány megköveteli, hogy adjunk nulla argumentumú konstruktort

Ezen kompromisszumok alapján a keretrendszerek az évek során más babkonvenciókhoz is alkalmazkodtak.

5. Következtetés

Ebben az oktatóanyagban a POJO-kat hasonlítottuk össze a JavaBeans-szal.

Először megtudtuk, hogy a POJO egy Java objektum, amely nincs kötve konkrét kerethez, és hogy a JavaBean a POJO speciális típusa, szigorú konvenciókkal.

Aztán láttuk, hogy egyes keretek és könyvtárak hogyan használják fel a JavaBean elnevezési megállapodást az osztály tulajdonságainak felfedezésére.

Szokás szerint a példák elérhetők a GitHub oldalon.