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.”[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
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
- Kibővítse az előrespecifikált osztályokat,
public class Foo extends javax.servlet.http.HttpServlet { ...
- Implementálja az előrespecifikált osztályokat,
public class Bar implements javax.ejb.EntityBean { ...
- 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.[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:
- 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.[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 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.[2] 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
Jegyzetek
Informatikai portál • összefoglaló, színes tartalomajánló lap