Plain Old Java Object

A számítástechnikában, a POJO, a Plain Old Java Object azaz magyarul a Régi Egyszerű Java Objektum rövidítése. Ezt a nevet akkor használják, mikor kihangsúlyozzák, hogy egy adott objektum egy rendszerint Java Objektum, nem pedig egy különleges objektum. A kifejezést Martin Fowler, Rebecca Parsons és Josh MacKenzie vezette be, 2000 szeptemberében:

""Csodálkoztunk, hogy az emberek miért ellenezték annyira a négyszögletes objektumokat a rendszereikben és arra jutottunk, hogy azért mert az egyszerű objektumoknak nem volt különleges nevük. Így hát adtunk nekik egyet, és igen szépre sikeredett."

A "POJO" kifejezést főleg olyan Java objektumok megnevezésére használják, amelyek nem követnek semmilyen főbb Java objektum modellt, megegyezés vagy keretrendszert. A kifejezés régebbi technológiák kifejezés mintáit követik, amelyek nem használnak különleges új tartozékok, mint például a POTS (Plain Old Telephone Service magyarul Régi Egyszerű Telefon Szolgáltatás) a telefonszolgáltatások terén, és a PODS and PODS (Plain Old Data Structures magyarul Régi Egyszerű Adat Struktúrák) amelyek C++ nyelven belül kerülnek meghatározásra, de kizárólag C nyelvi alkalmazásokat használnak és POD -t (Plain Old Documentation magyarul Régi Egyszerű Dokumentáció) Perl-ben. A POJO-nak megfelelő a .NET keretrendszerben a Plain Old CLR Object, magyarul Régi Egyszerű CLR Objektum. A POJO, valószínűleg akkor nyerte el leginkább elfogadottságát, mikor szükségessé vált egy egyszerű és könnyen megérthető kifejezés, ami kontrasztot nyújtott a bonyolult objektumok keretrendszerekkel szemben.

Meghatározás

Ideálisan elmondható, hogy a POJO egy olyan Java objektum, amelyet nem köt semmiféle korlátozás, azokon kivül amelyek a Java Nyelvi Specifikációból adódnak, azaz, a POJO-nak nem kell,

1. Kibővitenie az előrespecifikált osztályokat,

   public class Foo extends javax.servlet.http.HttpServlet { ...
   

2. Implementálnia az előrespecifikált osztályokat,

   public class Bar implements javax.ejb.EntityBean { ...
   

3. Tartalmaznia előrspecifikált osztályokat.

   @javax.persistence.Entity public class Baz { ...
   

Ennek ellenére, a műszaki nehézségeknek és más okoknak köszönhetően, sok szoftver termék és keretrendszer, amely POJO-kompatibilisként kerül leirásra, igazából még mindig szükségessé teszi az előre meghatározott magyarázatok használatát bizonyos tartozékokat illetően, mint például a megfelelő munkára vonatkozó kitartás.

Környezetfüggő variációk

JavaBeans

A JavaBean egy POJO, ami egy szerializálható elem, egy argumentum nélküli konstuktorral rendelkezik, és hozzáférést biztosít a tulajdonságok számára, melyek getter és setter metódusokat alkalmaznak, és az egyszerű nevezési megegyezést követik. Emiatt a megegyezés miatt, az egyszerű kinyilatkoztató hivatkozások, a tetszőleges JavaBeans tulajdonságaihoz köthetőek. Egy ilyen kinyilatkoztató hivatkozást alkalmazó kódnak nem kell tudnia semmit sem a bab típusáról és a bab sokféle keretrendszerrel alkalmazható, anélkül, hogy ezek a keretrendszerek tudnák a bab pontos típusát.

A következő egy JSF komponens példát mutat be, amely kétirányú kötésben van a POJO tulajdonsággal:

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

A POJO meghatározások a következők lehetnek:

public class MyBean {

    private String someProperty;

    public String getSomeProperty() {
         return someProperty;
    }

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

A JavaBean elnevezési megegyezéseinek megfelelően az egyszerű "someProperty" hivatkozás automatikusan lefordítható a "getSomeProperty()" metódusává, az értékszerzés céljából, és a "setSomeProperty(String)" metódusává az érték beállításához.

Átláthatóan hozzáadott szolgáltatások

A POJO-kat használó design-ok egyre elterjedtebben alkalmazottabbak, olyan rendszerek kerülnek piacra, amelyek a POJOk számára teljes funkcionalitást biztosítanak, a keretrendszerekben alkalmazva és szélesebb választékot arra való tekintettel, hogy milyen funkcionalitási területekre van igazából szükség. Ezen modellen belül, a programozó semmi többet nem hoz létre, mint egy POJO-t. Ez a POJO tisztán az üzleti logikára fókuszál, és nincs függőségben semmilyen keretrendszerrel sem. Az AOP keretrendszerek ezután átláthatóan adják hozzá a keresztvágási vonatkozásokat, úgy mint a hűséget, a tranzakciókat, biztonságot és így tovább.

Spring ennek az ötletnek egy korai implementációja volt, és egyike azon hajtóerőknek, melyek ezen modellnek a népszerűsítése mögött működtek a háttérben.

Egyéb példák:

• Enterprise JavaBeans,
• JPA (beleértve a hibernate is)
• CDI

A következő bemutatja az EJB bean teljes működését, demonstrálja, hogy hogyan használja ki az EJB3 a POJO modellt:

public class HelloWorldService {

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

Az alábbiaknak megfelelően a bab nem szükségszerűen terjeszt ki bármilyen EJB osztályt, vagy implementál bármilyen EJB kezelőfelületet, továbbá nem szükséges tartalmaznia semmilyen EJB megjegyzést sem. Ehelyett a programozó deklarálja egy külső xml fájlban, hogy milyen 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>

Gyakorlatban sokan a megjegyzéseket elegánsnak találják, míg az XML-t általában bőbeszédűnek, csúnyának és nehezen karban tarthatónak találják. Megint mások úgy találják, hogy a megjegyzések beszennyezik a POJO modellt.

Az XML alternatívájaként, sok keretrendszer (pl. a Spring, EJB és JPA) engedélyezi a megjegyzéseket, az XML helyett vagy mellett hozzáadva:

@Stateless
public class HelloWorldService {

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

A megjegyzéssel a babnak megfelelően a fentiekben megadva, a bab igazából többé nem egy tiszta POJO, de mivel a megjegyzések tisztán passzív metaadatokat tartalmaznak, ez sokkal kevesebb káros hátrányt okoz az osztályok bővítésének és/vagy kezelőfelületek implementálásának invazív jellegével szemben. Ennek megfelelően a programozási modell továbbra is nagyon hasonlít a tiszta a POJO modellre.

Lásd még

• Data Transfer Object
• Anemic Domain Model