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.

Definition

Sablon:Noref Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification. I.e., a POJO should not have to

1. Extend prespecified classes, as in

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

2. Implement prespecified interfaces, as in

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

3. Contain prespecified annotations, as in

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

However, due to technical difficulties and other reasons, many software products or frameworks described as POJO-compliant actually still require the use of prespecified annotations for features such as persistence to work properly.

Contextual variations

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

As designs using POJOs have become more commonly used, systems have arisen that give POJOs the full functionality used in frameworks and more choice about which areas of functionality are actually needed. In this model, the programmer creates nothing more than a POJO. This POJO purely focusses on business logic and has no dependencies on (enterprise) frameworks. AOP frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.

Spring was an early implementation of this idea and one of the driving forces behind popularizing this model.

Other examples are:

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

The following shows a fully functional EJB bean, demonstrating how EJB3 leverages the POJO model:

public class HelloWorldService {

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

As given, the bean does not need to extend any EJB class or implement any EJB interface and also does not need to contain any EJB annotations. Instead, the programmer declares in an external xml file which EJB services should be added to the bean:

<enterprise-beans>
    <session>
        <ejb-name>helloWorld</ejb-name>
        <ejb-class>com.example.HelloWorldService</ejb-class>
       <session-type>stateless</session-type>
    </session>
</enterprise-beans>

In practice, some people find annotations elegant, while they see XML as verbose, ugly and hard to maintain, yet others find annotations pollute the POJO model.

Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead or in addition to XML:

@Stateless
public class HelloWorldService {

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

With the annotation as given above the bean isn't a truly pure POJO anymore, but since annotations are merely passive metadata this has far fewer harmful drawbacks compared to the invasiveness of having to extend classes and/or implement interfaces. Accordingly, the programming model is still very much like the pure POJO model.

See also

• Data Transfer Object
• Anemic Domain Model

References

hu:Plain Old Java Object