Plain Old Java Object

En Programara inĝenierarto, POJO estas akronimo por Plain Old Java Object. La nomo estas uzata por emfazi ke donita objekto estas objekto ordinara en Java, ne objekto speciala. La termino estis elpensita de Martin Fowler, Rebecca Parsons kaj Josh MacKenzie en septembro 2000:

We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

("Ni nin demandis kial homoj malakceptis tiom uzi objektojn regulajn en iliaj sistemoj kaj ni estas konkludinta ke ĝi estis ĉar objektoj simpla mankis nomoj fantazian. Do ni estas doninta iun al ili, kaj ĝi estas fariĝinta populara kun multe da precizeco.")

La termino "POJO" komence indikis Java-objekton kiu ne sekvas iuj ajn el la ĉefaj modeloj, konvencioj, aŭ frameworks de Java-objekto; hodiaŭ oni povas uzi "POJO" ankaŭ kiel akronimo por "Plain Old Javascript Object". Ĉikaze la termino indikas Javascript-objekto de simila genealogio.

La termino daŭrigas la skemon de terminoj pli malnovaj por teknologioj kiuj ne uzas novajn trajtoj fantaziajn, kiel POTS (Plain Old Telephone Service) en telefonio, PODS (Plain Old Data Structures) difinitaj en C++ sed uzantaj nur trajtojn de la lingvo C, kaj POD (Plain Old Documentation) en Perl. La ekvivalento al POJO sur la Microsoft .NET estas Plain Old CLR Object (POCO). Por PHP, ĝi estas Plain Old PHP Object (POPO).

Difino

Parolante ideale, POJO estas Java-objekto ne ligita de iu ajn restrikto krom tiuj devigitaj de la Java Language Specification. En aliaj parolas, POJO devas:

1. Ne plilongigi klasojn prespecifita, kiel en

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

2. Ne implementi interfacojn prespecifita, kiel en

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

3. Ne enhavi prinotaĵojn prespecifita, kiel en

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

Tamen, pro malfacilaĝoj teknikaj kaj aliaj kialoj, multaj programaro-produktoj aŭ frameworks priskribataj kiel akordiĝintaj kun POJO ankoraŭ postulas fakte la uzon de prinotaĵoj prespecifitaj por trajtoj kiel persisto por funkcii ĝuste. La ideo estas ke se la objekto (fakte klaso) estis POJO antaŭ ol iu ajn prinotaĵoj estis aldonata, kaj revenus al stauso de POJO se la prinotaĵoj estas rorigitaj, do ĝi povas ankoraŭ esti konsiderata POJO. Do la objekto baza restas POJO en la senso ke ĝi ne havas trajtojn specialajn (kiel interfacon implementata) kiuj faras ĝin "Specialized Java Object" (SJO aŭ (sic) SoJO).

Varioj kuntekstaj

JavaBeans

JavaBean estas POJO kiu estas serialigebla, havas konstruanton sen argumentoj, kaj permesas aliro al propraĵos uzantaj metodojn getter kaj setter kiuj sekvas simplan konvencion de nomi. Pro ĉi tiu konvencio, oni povas fari simplajn referencojn deklarajn al la propraĵos de JavaBeans arbitra. Kodo uzanta tia referenco deklara ne scias ion sur la tipo de la bean (objekto unuobla), kaj oni povas uzi la bean kun multaj frameworks sen ĉi tiu frameworks devantaj scii la tipon ekzaktan de la bean.

La specification de JavaBeans, se plene implementata, iomete malobservas la modelo POJO kiel la klaso devas implementi la interfaco serialigebla al esti vera JavaBean. Multaj klasoj de POJO ankoraŭ nomitaj JavaBeans ne plenumas ĉi tiu postulon. Ĉar serialigebla estas interfaco marko (sen metodo), ĉi tiu estas ne multo de ŝarĝo.

La kodo sekvanta montras ekzemplon de komponanto de JSF havantan dudirekton ligantan al propraĵo de POJO:

<h:inputText value="#{miaBean.iuProprajho}"/>

La difino de la POJO povas esti kiel sekvas:

public class MiaBean
{
 private String iuProprajho;

 public String getIuProprajho()
 {
  return iuProprajho;
 }

 public void setIuProprajho(String iuProprajho)
 {
  this.iuProprajho = iuProprajho;
     }
}

Pro la konvencioj de nomi en JavaBean la unuobla referenco "iuProprajho" povas esti aŭtomate tradukata al la metodo getIuProprajho() (aŭ isIuProprajho() se la propraĵo estas de tipo booleana) por ricevi valoron, kaj al la metodo setIuProprajho(String) por fiksi valoron.

Travideble aldoni servoj

Kiel desegnoj uzantaj POJOjn estas fariĝintaj pli komune uzata, sistemoj estas aperintaj kiuj donas al POJOj la plenan funkcioneson uzatan en frameworks kaj pli da elekton sur la kiuj lokoj de funkcioneso estas fakte postulata. En ĉi tiu modelo, la programisto kreas nenion pli ol POJO. Ĉi tiu POJO pure koncentriĝas sur komerco-logiko (business logic) kaj ne havas dependencojn sur (enterprise) frameworks. Frameworks de programado orientiĝata al aspektoj tiam travideble aldonas aferojn transtranĉajn kiel persisto, transakcioj, sekureso, etc.

Spring estis implemento frua de ĉi tiu ideo kaj unu el la kondukanta fortoj malantaŭ popularigi ĉi tiun modelon.

Ekzemplo de bean de Enterprise JavaBeans (EJB) estanta POJO:

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

La kodo sekvanta montras bean plene praktikan de EJB, montrante kiel EJB3 ekspluatas la POJO modelo:

public class ServoSalutonMondo
{
 public String diruSaluton()
 {
  return "Saluton, mondo!";
 }
}

Kiel donita, la bean ne postulas plilongigi iun ajn klason de EJB aŭ implementi iun ajn interfacon de EJB kaj ankaŭ ne postulas enhavi iun ajn prinotaĵojn de EJB. Anstataŭ tio, la programisto deklaras, en ekstera dosiero de xml, kiuj servoj de EJB devas esti aldonata al la bean:

<enterprise-beans>
    <session>
        <ejb-name>salutonMondo</ejb-name>
        <ejb-class>com.example.ServoSalutonMondo</ejb-class>
       <session-type>stateless</session-type>
    </session>
</enterprise-beans>

Praktike, iuj homoj trovas prinotaĵoj elegantaj, sed ili vidas XML kiel malkonciza, malbona kaj malfacila por daŭrigi, sed aliaj trovas ke prinotaĵoj poluas la POJO-modelo.

Sekve, kiel alternativo al XML, multaj frameworks (ekz. Spring, EJB kaj JPA) permesas uzi prinotaĵojn anstataŭ aŭ en aldonaĵo al XML. La kodo sekvanta montras la saman bean de Enterprise JavaBeans (EJB) kiel montrata alte sed kun prinotaĵo aldonata. Ĉikaze la dosiero de XML ne estas jam postulata:

@Stateless
public class ServoSalutonMondo
{
 public String diruSaluton()
 {
  return "Saluton, mondo!";
 }
}

Kun la prinotaĵo kiel donita alte la bean ne estas POJO vere pura jam, sed ĉar prinotaĵoj estas nur pasivaj metadatenoj ĉi tiu havas malpli da malutilajn malavantaĝojn kompare kun la invadeco de devo plilongigi klasojn kaj/aŭ implementi interfacoj. En sekvaĵo, la programado-modelo estas ankoraŭ tre multe kiel la pura modelo POJO.