Plain Old Java Object

Nota

Iste articulo es in disveloppamento

Un o plus wikipedistas labora al momento pro meliorar iste articulo. Per iste ration, le information del articulo poterea esser incomplete. Per favor, propone nove cambios in le pagina de discussion.

In ingenieria de programmatura, POJO es un acronymo pro Plain Old Java Object. Le nomine es usate pro accentuar que un date 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 que 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 que non usa nove characteristicas phantastic, tal como POTS (Plain Old Telephone Service) in telephonia, PODS (Plain Old Data Structures) definite in C++ ma usante solmente characteristicas del linguage C, e POD (Plain Old Documentation) in Perl. Le equivalente a POJO super le Microsoft .NET es Plain Old CLR Object (POCO). For 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 aquelles 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 a 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 como un interfacie implementate) le quales face lo un "Specialized Java Object" (SJO o (sic) SoJO).

Variationes contextual

JavaBeans

Un JavaBean es un POJO que es serialisabile, ha un constructor sin argumentos, e permitte accesso a proprietates usante methodos getter e setter que seque un simple convention de nominar. A causa de iste convention, on pote facer simple referentias declarative al proprietates de JavaBeans arbitrari. Codice usante un tal referentia declarative non sape alque 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 a esser un ver JavaBean. Multe classes de POJO ancora appellate JavaBeans non incontra iste requirimento. A causa que 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}"/>