Plain Old Java Object

Az informatikában, illetve a szoftverfejlesztésben a Plain Old Java Object („jó öreg Java-objektum”), röviden POJO kifejezés az olyan Java-objektumokra használatos, amik teljesen hétköznapiak, nem rendelkeznek speciális tulajdonságokkal.

A kifejezést Martin Fowler, Rebecca Parsons és Josh MacKenzie vezette be, 2000 szeptemberében:

„Azon tűnődtünk, miért ellenzik az emberek annyira a sima objektumok használatát a rendszereikben, és arra jutottunk, hogy azért, mert az egyszerű objektumoknak nem volt fantázianevük. Így hát adtunk nekik egyet, és az szépen elterjedt.”

A „POJO” kifejezést főleg olyan Java-objektumok megnevezésére használják, amelyek nem követnek semmilyen főbb Java-objektummodellt, megegyezést vagy keretrendszert. A kifejezés más, régi, egyszerű és megbízható technológiára utaló kifejezések mintájára készült, mint amilyen a POTS (Plain Old Telephone Service) a telefonszolgáltatások terén, a PODS (Plain Old Data Structures), melyek olyan C++ adatstruktúrák, melyek csak a C nyelv eszközeit használják, vagy a POD (Plain Old Documentation) Perlben. A POJO megfelelője a .NET keretrendszerben a Plain Old CLR Object.

A POJO kifejezés valószínűleg azért terjedt el gyorsan, mert szükség volt egy egyszerű és közérthető kifejezésre, ami a bonyolult objektum-keretrendszerek ellentétét próbálja kifejezni.

Meghatározás

Ideális esetben a POJO egy olyan Java-objektum, amelyet nem köt semmiféle korlátozás, azokon kívül amelyek a Java nyelvi specifikációjából adódnak. Így tehát egy POJO-tól nem várja el, hogy

1. Kibővítse az előrespecifikált osztályokat,

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

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

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

3. Tartalmazzon előrespecifikált osztályokat.

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

Mindazonáltal, technikai nehézségek és más okok miatt sok POJO-kompatibilisnek reklámozott szoftvertermékben valójában még mindig szükséges az előre meghatározott annotációk használata az olyan funkciók megfelelő működéséhez, mint a perzisztencia.

Környezetfüggő variációk

JavaBeans

A JavaBean olyan POJO, ami szerializálható, argumentum nélküli konstruktorral rendelkezik, és egyszerű elnevezési konvenciókat alkalmazó getter és setter metódusokkal hozzá lehet férni a tulajdonságaihoz. Emiatt a megegyezés miatt egyszerű deklaratív referenciákkal hivatkozni lehet tetszőleges JavaBean objektum tulajdonságaira. Egy ilyen hivatkozást alkalmazó kódnak nem kell tudnia semmit a bab típusáról, és a bab sokféle keretrendszerrel alkalmazható, anélkül, hogy ezek a keretrendszerek ismernék a bab pontos típusát.

A következő példában egy JSF-komponens kétirányú kötésben van egy 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

Ahogy a POJO-kat használó designok egyre elterjedtebben alkalmazzák, olyan rendszerek kerülnek piacra, amelyek a POJO-k számára a keretrendszerek teljes funkcionalitását biztosítják, és rugalmasabban választható ki, 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 több területet érintő vonatkozásokat, mint pl. a perzisztenciát, a tranzakciókat, biztonságot és így tovább.

A Spring ennek az ötletnek egy korai megvalósítása volt, és az egyik hajtóerő a modell elterjedése mögött.

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 annotációt 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>

A gyakorlatban sokan az annotációkat 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 az annotációk beszennyezik a POJO modellt.

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

@Stateless
public class HelloWorldService {

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

A fenti annotációval a bab igazából nem tekinthető valódi POJO-nak, de mivel az annotációk csupán passzív metaadatokat tartalmaznak, ez sokkal kevesebb káros visszalépést jelent az osztályok bővítésének és/vagy interfészek 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.

Kapcsolódó szócikkek

• Data Transfer Object
• Anemic Domain Model