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:

Plain Old Java Object
subclasse de: Objecto

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:

1. Non extender classes prespecificate, como in

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

2. Non implementar interfacies prespecificate, como in

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

3. Non continer annotationes prespecificate, como in

   @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:

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

Le definition del POJO pote esser como seque:

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:

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:

<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:

@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

Nota

Iste pagina contine material traducite ab Wikipedia in anglese. Le articulo original se trova a en:Plain Old Java Object, e es usate secundo le mandatos del licentia de Wikipedia.