Plain Old Java Object

In ingenieria de programmatura, ***POJO*** es un acronymo pro **Plain Old Java Object**. Le nomine es usate pro accentuar que un donate objecto es un objecto ordinari in Java, non un objecto special. Le termino esseva cuneate per Martin Fowler, Rebecca Parsons e Josh MacKenzie in septembre 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.*

("Nos nos demandava proque gente se opponeva tanto a usar objectos regular in lor systemas e nos ha concludite que illo esseva a causa que objectos simple careva un nomine phantastic. Dunque nos ha date alcun a illos, e illo ha devenite popular con multe precision.")


Le termino "POJO" initialmente denotava un objecto de Java qui seque nulle del major modellos, conventiones, o *frameworks* de objecto de Java; hodie on pote usar "POJO" anque como un acronymo pro "Plain Old *Javascript* Object". In iste caso le termino denota un objecto de Javascript de similar genealogia.

Le termino continua le patrono de terminos plus ancian pro technologias qui non usa nove characteristicas phantastic, tal como POTS (Plain Old Telephone Service) in telephonia, PODS (Plain Old Data Structures) definite in C++ sed usante solmente characteristicas del linguage C, e POD (Plain Old Documentation) in Perl. Le equivalente al POJO super le Microsoft .NET es Plain Old CLR Object (POCO). Pro PHP, illo es Plain Old PHP Object (POPO).

## Definition
Pro parlar idealmente, un POJO es un objecto de Java non ligate per qualcunque restriction altere que illos fortiate per le Java Language Specification. In altere parolas, un POJO debe:
#Non extender classes prespecificate, como in
```java
public class Foo extends javax.servlet.http.HttpServlet { ...
```

#Non implementar interfacies prespecificate, como in
```java
public class Bar implements javax.ejb.EntityBean { ...
```

#Non continer annotationes prespecificate, como in
```java
@javax.persistence.Entity public class Baz { ...
```

Totevia, a causa de difficultates technic e altere rationes, multe productos de programmatura o *frameworks* describite como accordante con POJO ancora require de facto le uso de annotationes prespecificate pro tal characteristicas como persistentia pro functionar correctemente. Le idea es que si le objecto (de facto classe) esseva un POJO ante que qualcunque annotationes esseva addite, e retornarea al stato de POJO si le annotationes es removite, dunque illo pote ancora esser considerate un POJO. Dunque le objecto basic remane un POJO in le senso que illo non ha characteristicas special (tal que un interfacie implementate) le quales lo face un "Specialized Java Object" (SJO o (sic) SoJO).

## Variationes contextual
### JavaBeans
Un JavaBean es un POJO qui es serialisabile, ha un constructor sin argumentos, e permitte accesso al proprietates usante methodos mutator e accessor le quales seque un simple convention de nominar. A causa de iste convention, on pote facer simple referentias declarative al proprietates de JavaBeans arbitrari. Le codice usante un tal referentia declarative non sape nihil super le typo del *bean* (objecto singule), e on pote usar le *bean* con multe *frameworks* sin iste *frameworks* debente cognoscer le typo exacte del *bean*.

Le specification de JavaBeans, si plenmente implementate, legiermente viola le modello POJO como le classe debe implementar le interfacie serialisabile pro esser un ver JavaBean.  Multe classes de POJO ancora appellate JavaBeans non incontra iste requirimento.  A causa que le interfacie serialisabile es un interfacie marca (sin methodo), isto es minimo de un onere.

Le codice sequente monstra un exemplo de un componente de JSF habente un bidirectional ligante a un proprietate de POJO:


```xml
<h:inputText value="#{miBean.alcunProprietate}"/>
```


Le definition del POJO pote esser como seque:


```java
public class MiBean 
{
	private String alcunProprietate;

	public String getAlcunProprietate() 
	{
		return alcunProprietate;
	}

	public void setAlcunProprietate(String alcunProprietate) 
	{
		this.alcunProprietate = alcunProprietate;
    	}
}
```


A causa del conventiones de nominar in JavaBean le singule referentia "alcunProprietate" pote esser automaticamente traducite al methodo *getAlcunProprietate()* (o *isAlcunProprietate()* si le proprietate es de typo boolean) pro obtener un valor, e al methodo *setAlcunProprietate(String)* pro poner un valor.

### Transparentemente adder servicios
Como designos usante POJOs ha devenite plus communmente usate, systemas ha provenite le quales da a POJOs le plen functionalitate usate in *frameworks* e plus de selection super le qual areas de functionalitate es de facto requirite. In iste modello, le programmator crea nulle de plus que un POJO. Iste POJO purmente se concentra super le logica de negotio (*business logic*) e non ha dependentias super (enterprise) *frameworks*. *Frameworks* de programmation orientate a aspectos alora transparentemente adde affaires transversal como persistentia, transactiones, securitate, etc.

Spring esseva un implementation anterior de iste idea e un del fortias guidante pro popularisar iste modello.

Un exemplo de un *bean* de Enterprise JavaBeans (EJB) essente un POJO:
* Enterprise JavaBeans, 
* JPA (includente Hibernate) pro le persistentia
* CDI

Le codice sequente monstra un *bean* plenmente functional de EJB, demonstrante como EJB3 influentia le modello de POJO:


```java
public class ServicioHalloMundo 
{
	public String diceHallo() 
	{
		return "Hallo, mundo!";
	}
}
```


Como donate, le *bean* non require extender qualcunque classe de EJB o implementar qualcunque interfacie de EJB e anque non require continer qualcunque annotationes de EJB. In su loco, le programmator declara, in un externe archivo de xml, qual servicios de EJB debe esser addite al *bean*:


```xml
<enterprise-beans>
    <session>
        <ejb-name>halloMundo</ejb-name>
        <ejb-class>com.example.ServicioHalloMundo</ejb-class>
       <session-type>stateless</session-type>
    </session>
</enterprise-beans>
```


In practica, alcun gente trova annotationes elegante, sed illes vide XML como verbose, fede e difficile pro mantener, sed alteres trova que annotationes pollue le modello POJO. 

Assi, como un alternative a XML, multe *frameworks* (e.g. Spring, EJB e JPA) permitte de usar annotationes in loco de o in addition a XML. Le codice sequente monstra le mesme *bean* de EJB como monstrate in alto sed con un annotation addite. In iste caso le archivo de XML non es jam requirite:


```java
@Stateless
public class ServicioHalloMundo 
{
	public String diceHallo() 
	{
		return "Hallo, mundo!";
	}
}
```


Con le annotation como donate in alto le *bean* non es un POJO vermente pur plus longe, sed a causa que annotationes es solmente metadatos passive isto ha plus pauc disavantages damnose in comparation de deber extender classes e/o implementar interfacies tediosemente. In consequentia, le modello de programmation es ancora permulto como le modello POJO pur.

## Referentias