Plain Old Java Object

A számítástechnikában, a POJO, a Plain Old Java Object vagy magyar nyelven 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 rendszerinti 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 framework -ben 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

Sablon:Noref 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 konstuktőr (Constructor)-rel rendelkezik, és hozzáférést biztosít a tulajdonságok számára, melyek getter and setter method-okat alkalmaznak, és az egyszerű nevesíté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ő mutat egy példát a JSF komponensről, amelynek bidirekciós kötése 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-ket 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ége a befektetési keretrendszerekkel szemben. 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, amelyek ezen modellnek a népszerűsítése mögött működtek a háttérben.

Több példa:

• Enterprise JavaBeans,
• JPA (including Hibernate)
• CDI

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

public class HelloWorldService {

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

Az alábbiaknak megfelelően a bab nem szükségszerűen terjed ki bármilyen EJB osztályra vagy implementál bármilyen EJB kezelőfelületet és nem szükségelteti bármilyen EJB megjegyzés tartalmát. Ehelyett a programozó kinyilatkoztatja egy külső xml fájlban 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 sok ember a megjegyzéseket elegánsnak találja, míg az XML-t általában bőbeszédűnek, csúnyának és nehezen karban tarthatónak találják, míg 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