Sima régi Java objektum - Plain old Java object

A szoftverfejlesztésben a sima régi Java objektum ( POJO ) egy közönséges Java objektum , amelyre semmilyen különleges korlátozás nem vonatkozik. A kifejezést Martin Fowler , Rebecca Parsons és Josh MacKenzie alkotta 2000 szeptemberében:

"Azon tűnődtünk, hogy miért ellenzik az emberek a rendszeres tárgyak használatát a rendszerükben, és arra a következtetésre jutottunk, hogy ez azért van, mert az egyszerű tárgyaknak nem volt fantázianévük. Így adtunk nekik egyet, és ez nagyon szépen megfogott."

A "POJO" kifejezés kezdetben egy Java objektumot jelölt, amely nem követi a fő Java objektummodelleket, konvenciókat vagy keretrendszereket; manapság a "POJO" használható a sima régi JavaScript objektumok rövidítéseként is, ebben az esetben a kifejezés egy hasonló törzsű JavaScript objektumot jelöl .

A kifejezés folytatja az érme -utónevek rövidítését olyan technológiákhoz, amelyek nem használnak divatos új funkciókat: sima régi Ruby -objektum (PORO) a Ruby -ban , sima régi telefonszolgáltatás (POTS) a telefonálásban és a Plain Old Documentation (pod) a Perl -ben . Az egyenértékű POJO a .NET Framework az öreg CLR objektum (POCO). Mert PHP , ez öreg PHP objektum (POPO).

A POJO jelenség nagy valószínűséggel széles körben elfogadottá vált, mivel szükség van egy közös és könnyen érthető kifejezésre, amely ellentétes a bonyolult objektumkeretekkel.

Meghatározás

Ideális esetben a POJO egy Java objektum, amelyre semmilyen korlátozás nem vonatkozik, kivéve azokat, amelyeket a Java nyelvi specifikáció kényszerít; azaz a POJO -nak nem kell

  1. Bővítse az előre meghatározott osztályokat, mint pl
    public class Foo extends javax.servlet.http.HttpServlet { ...
  2. Előre meghatározott interfészek megvalósítása, például
    public class Bar implements javax.ejb.EntityBean { ...
  3. Előre meghatározott megjegyzéseket tartalmaz , mint például
    @javax.persistence.Entity public class Baz { ...

Technikai nehézségek és egyéb okok miatt azonban számos szoftvertermék vagy keretrendszer, amelyet POJO-kompatibilisnek minősítenek, valójában továbbra is megköveteli az előre meghatározott megjegyzések használatát az olyan funkciókhoz, mint például a kitartás a megfelelő működéshez. Az elképzelés az, hogy ha az objektum (valójában osztály) POJO lenne a megjegyzések hozzáadása előtt, és visszatérne a POJO állapotba, ha a megjegyzéseket eltávolítják, akkor is POJO -nak tekinthető. Ekkor az alapobjektum POJO marad abban az értelemben, hogy nincsenek olyan különleges jellemzői (például egy megvalósított interfész), amely "Specialized Java Object" -vé (SJO vagy (sic) SoJO) teszi.

Kontextuális variációk

JavaBeans

A JavaBean egy POJO, amely sorosítható , argumentum nélküli konstruktorral rendelkezik , és lehetővé teszi a tulajdonságokhoz való hozzáférést az egyszerű elnevezési konvenciót követő getter és setter metódusok használatával . Ennek az egyezménynek köszönhetően egyszerű kijelentő hivatkozások tehetők tetszőleges JavaBeans tulajdonságaira. Az ilyen kijelentő hivatkozást használó kódnak nem kell semmit tudnia a bab típusáról, és a bab használható sok keretrendszerrel anélkül, hogy ezeknek a keretrendszereknek ismernie kellene a bab pontos típusát. A JavaBeans specifikáció, ha teljes mértékben megvalósul, kissé megtöri a POJO modellt, mivel az osztálynak végre kell hajtania a Serializable interfészt, hogy valódi JavaBean legyen. Sok, továbbra is JavaBeans nevű POJO osztály nem felel meg ennek a követelménynek. Mivel a Serializable egy marker (módszer nélküli) felület, ez nem jelent nagy terhet.

Az alábbiakban egy példa látható egy JavaServer Faces (JSF) összetevőre, amely kétirányú kötéssel rendelkezik a POJO tulajdonságához: 

<h:inputText value="#{MyBean.someProperty}"/>

A POJO meghatározása a következő lehet: 

public class MyBean {

    private String someProperty;

    public String getSomeProperty() {
         return someProperty;
    }

    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
}

A JavaBean elnevezési konvenciók miatt az egyetlen "someProperty" hivatkozás automatikusan lefordítható a "getSomeProperty ()" (vagy "isSomeProperty ()", ha a tulajdonság logikai típusú ) módszerre az érték lekérésére, és a "setSomeProperty ( String) "módszer érték beállítására.

Szolgáltatások átlátható hozzáadása

Ahogy a POJO -kat használó tervek egyre gyakoribbak lettek, olyan rendszerek jöttek létre, amelyek a POJO -k számára a keretrendszerekben használt teljes funkcionalitást biztosítják, és nagyobb választási lehetőséget biztosítanak arra vonatkozóan, hogy a funkcionalitás mely területeire van szükség. Ebben a modellben a programozó csak POJO -t hoz létre. Ez a POJO pusztán az üzleti logikára összpontosít, és nem függ a (vállalati) keretektől. Az aspektusorientált programozási (AOP) keretek ezután átláthatóan olyan átfogó aggályokat adnak hozzá, mint a kitartás, a tranzakciók, a biztonság stb.

A tavasz ennek az ötletnek a korai megvalósítása és a modell népszerűsítésének egyik hajtóereje.

Példa arra, hogy az EJB bab POJO:

Az alábbiakban egy teljesen működőképes EJB bab látható, bemutatva, hogy az EJB3 hogyan használja ki a POJO modellt: 

public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

A babnak nem kell semmilyen EJB osztályt kiterjesztenie vagy EJB interfészt megvalósítania, és nem kell tartalmaznia sem EJB megjegyzéseket. Ehelyett a programozó egy külső XML fájlban deklarálja, hogy mely EJB szolgáltatásokat kell hozzáadni a babhoz: 

<enterprise-beans>
    <session>
        <ejb-name>helloWorld</ejb-name>
        <ejb-class>com.example.HelloWorldService</ejb-class>
        <session-type>stateless</session-type>
    </session>
</enterprise-beans>

A gyakorlatban egyesek elegánsnak találják a megjegyzéseket, míg az XML -t sokoldalúnak, csúnyának és nehezen karbantarthatónak tartják, mások szerint a megjegyzések szennyezik a POJO modellt.

Így az XML alternatívájaként számos keretrendszer (pl. Spring, EJB és JPA) lehetővé teszi a megjegyzések használatát az XML helyett vagy mellett. Az alábbiakban ugyanaz az EJB bab látható, mint fent, de megjegyzéssel. Ebben az esetben az XML fájlra már nincs szükség: 

@Stateless
public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

A fenti megjegyzéssel a bab már nem igazán tiszta POJO, de mivel a feliratok pusztán passzív metaadatok, ennek sokkal kevesebb káros hátránya van, mint az osztályok kiterjesztésének és/vagy interfészek megvalósításának invazivitása. Ennek megfelelően a programozási modell még mindig nagyon hasonlít a tiszta POJO modellre.

Kapcsolódó rövidítések

Sima régi Java felület

A sima régi Java interfész (POJI) a Java interfész alapvető formája, és elfogadható olyan helyeken, ahol a bonyolultabb Java interfészek nem engedélyezettek.

Lásd még

Hivatkozások