Plain old Java object: Difference between revisions

Revision as of 23:38, 24 April 2019

Revision as of 23:59, 27 April 2019

Line 1:

In [[software engineering]], a '''Plain Old Java Object''' ('''POJO''') is an ordinary [[Java_Java (programming_languageprogramming language)|Java]] [[Object (computer science)|object]], not bound by any special restriction and not requiring any class path. The term was coined by [[Martin Fowler (software engineer)|Martin Fowler]], Rebecca Parsons and Josh MacKenzie in September 2000: <ref name="bliki" />

<blockquote>

"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."<ref name="bliki">{{cite web |url=http://www.martinfowler.com/bliki/POJO.html |title=MF Bliki: POJO |work=MartinFowler.com }}</ref>

Line 6:

The term "POJO" initially denoted a Java object which does not follow any of the major Java object models, conventions, or frameworks; nowadays "POJO" may be used as an acronym for "Plain Old ''JavaScript'' Object" as well, in which case the term denotes a [[JavaScript]] object of similar pedigree.<ref>{{cite web |url=http://ajaxian.com/archives/return-of-the-pojo-plain-ole-javascript |title=Return of the POJO: Plain ‘Ole JavaScript |last=Almaer |first=Dion |work=Ajaxian |date=2006-07-17 |accessdate=2014-08-19 }}</ref>

The term continues the pattern of older terms for technologies that do not use fancy new features, such as PORO ([[Plain Old Ruby Object]]) in [[Ruby (programming language)|Ruby]], POTS ([[Plain Old Telephone Service]]) in [[telephony]] and Pod ([[Plain Old Documentation]]) in [[Perl]]. The equivalent to POJO on the [[.NET framework]] is [[Plain Old CLR Object]] (POCO).<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/cc681329.aspx |title=POCO Support |work=microsoft.com |accessdate=2012-05-27 }}

</ref> For [[PHP]], it is Plain Old PHP Object (POPO).<ref>{{cite web |url=http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |title=typesafe objects in PHP |first=Jan |last=Kneschke |date=2007-02-19 |work=kneschke.de |accessdate=2012-05-27 |deadurl=yes |archiveurl=https://web.archive.org/web/20120326195616/http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |archivedate=2012-03-26 |df= }}</ref><ref>{{cite web |url=http://jym.sg/controller-with-bare-bone-plain-old-php-objec |title=Controller with bare-bone Plain Old PHP Object aka POPO |first=Jym |last=Cheong |date=2011-06-26 |work=jym.sg |accessdate=2012-05-27 |deadurl=yes |archiveurl=https://web.archive.org/web/20120326195611/http://jym.sg/controller-with-bare-bone-plain-old-php-objec |archivedate=2012-03-26 |df= }}

</ref>

Line 16:

#Extend prespecified classes, as in<source lang="java">public class Foo extends javax.servlet.http.HttpServlet { ...</source>

#Implement prespecified interfaces, as in<source lang="java">public class Bar implements javax.ejb.EntityBean { ...</source>

#Contain prespecified [[Java_annotationJava annotation|annotations]], as in<source lang="java">@javax.persistence.Entity public class Baz { ...</source>

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.

The idea is that if the object (actually class) was a POJO before any annotations were added, and would return to POJO status if the annotations are removed then it can still be considered a POJO. Then the basic object remains a POJO in that it has no special characteristics (such as an implemented interface) that makes it a "Specialized Java Object" (SJO or (sic) SoJO).

Line 27:

The JavaBeans specification, if fully implemented, slightly breaks the POJO model as the class must implement the [[Serialization#Java|Serializable]] interface to be a true JavaBean. Many POJO classes still called JavaBeans do not meet this requirement. Since [[Serialization|Serializable]] is a marker (method-less) interface, this is not much of a burden.

The following shows an example of a [[JavaServer Faces]] (JSF) component having a [[Duplex_Duplex (telecommunications)|bidirectional]] binding to a POJO's property:

<syntaxhighlight lang="xml">

Line 87:

</syntaxhighlight>

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. <ref>Panda, Debu; Rahman, Reza; Lane, Derek; (2007). ''EJB 3 in action'', Manning Publications Co., Shelter Island (NY), {{ISBN|978-1-93-398834-4}} (www.manning.com/books/ejb-3-in-action). Chapter 11, ''Deployment descriptors vs. annotations''</ref>

Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead of or in addition to XML. The following shows the same EJB bean as showed above but with an annotation added. In this case the XML file is no longer needed: