Plain Old Java Object

A Wikipédiából, a szabad enciklopédiából

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.”[1]

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[szerkesztés | forrásszöveg szerkesztése]

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[szerkesztés | forrásszöveg szerkesztése]

JavaBeans[szerkesztés | forrásszöveg szerkesztése]

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[szerkesztés | forrásszöveg szerkesztése]

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.[2]

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:

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 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.[3]

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 a megjegyzések 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.[2] Ennek megfelelően a programozási modell továbbra is nagyon hasonlít a tiszta a POJO modellre.

Kapcsolódó szócikkek[szerkesztés | forrásszöveg szerkesztése]

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. MF Bliki: POJO from MartinFowler.com
  2. ^ a b Martin, Robert C. (2008). Clean Code. Chapter 11, Pure Java AOP Frameworks
  3. Panda, Rahman, Lane. (2007). EJB3 in action. Manning. Chapter 11, Deployment descriptors vs. annotations