Plain old Java object: Difference between revisions

Revision as of 15:22, 17 April 2017

Latest revision as of 18:50, 19 December 2024

(45 intermediate revisions by 35 users not shown)

Line 1:

{{Short description|Type of object in Java programming language}}

In [[software engineering]], a '''plain old Java object''' ('''POJO''') is an ordinary [[Java_Java (programming_languageprogramming language)|Java]] [[Objectobject (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">{{cite web |url=http://www.martinfowler.com/bliki/POJO.html |title=MF Bliki: POJO |work=MartinFowler.com }}</ref>

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

</blockquote>

"{{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>

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 |date=2006-07-17 |accessdate=2014-08-19}}

</ref>

The term "POJO" initially denoted a Java object which does not follow any of the major Java object models, conventions, or frameworks;. nowadaysIt "POJO"has maysince begained usedadoption as ana acronymlanguage-agnostic forterm, "Plainbecause Oldof ''JavaScript''the Object"need asfor well,a incommon whichand caseeasily theunderstood term denotesthat acontrasts with [[JavaScript]]complicated object offrameworks.{{Citation similarneeded|date=April pedigree.<ref>2013}}

The term continues the pattern of older terms for technologies that do not use fancy new features, such as 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 |author=Jan Kneschke |date=2007-02-19 |work=kneschke.de |accessdate=2012-05-27}}</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 |author=Jym Cheong |date=2011-06-26 |work=jym.sg |accessdate=2012-05-27}}

</ref>

The term continues an [[acronym]] pattern to coin [[retronym | retronyms]] for constructs that do not use fancy new features:

The POJO phenomenon has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks.{{Citation needed|date=April 2013}}

* "Plain old JavaScript object" in [[JavaScript]]<ref>{{cite web |url=http://ajaxian.com/archives/return-of-the-pojo-plain-ole-javascript |url-status=dead |archive-url=https://web.archive.org/web/20140913151352/http://ajaxian.com/archives/return-of-the-pojo-plain-ole-javascript |archive-date=2014-09-13 |title=Return of the POJO: Plain 'Ole JavaScript |last=Almaer |first=Dion |work=Ajaxian |date=2006-07-17 |access-date=2014-08-19 }}</ref>

* "Plain old Ruby object" (PORO) in [[Ruby (programming language)|Ruby]]

* "Plain old Documentation" (pod) in [[Perl]]

* [[Plain old CLR object]] (POCO)<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/cc681329.aspx |title=POCO Support |work=microsoft.com |accessdateaccess-date=2012-05-27 }}

</ref> in the [[.NET Framework]]

* "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 |access-date=2012-05-27 |url-status=dead |archive-url=https://web.archive.org/web/20120326195616/http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |archive-date=2012-03-26 }}</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 |access-date=2012-05-27 |url-status=dead |archive-url=https://web.archive.org/web/20120326195611/http://jym.sg/controller-with-bare-bone-plain-old-php-objec |archive-date=2012-03-26 }}

</ref> in [[PHP]]

* [[Plain old telephone service]] (POTS) in [[telephony]]

==Definition==

Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification; i.e. a POJO '''should not''' have to

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

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

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

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) waswere 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).

==Contextual variations==

===JavaBeans===

A [[JavaBean]] is a POJO that is [[Serialization#Java|serializable]], has a no-argument [[Constructor (computer science)|constructor]], and allows access to properties using [[Mutator method|getter and setter methods]] that follow a simple naming convention. Because of this convention, simple declarative references can be made to the properties of arbitrary JavaBeans. Code using such a declarative reference does not have to know anything about the type of the bean, and the bean can be used with many frameworks without these frameworks having to know the exact type of the bean.

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]] (JSF) component having a [[Duplex_Duplex (telecommunications)|bidirectional]] binding to a POJO's property:

<syntaxhighlight lang="xml">

<h:inputText value="#{myBeanMyBean.someProperty}"/>

</syntaxhighlight>

The definition of the POJO can be as follows:

<syntaxhighlight lang="java">public class MyBean {

public class MyBean {

private String someProperty;

Line 52 ⟶ 50:

this.someProperty = someProperty;

}

}</syntaxhighlight>

}

</syntaxhighlight>

Because of the JavaBean naming conventions the single "someProperty" reference can be automatically translated to the "getSomeProperty()" (or "isSomeProperty()" if the property is of [[Boolean type]]) method for getting a value, and to the "setSomeProperty(String)" method for setting a value.

The [https://projectlombok.org/ lombok] library allows to change the code dynamically to integrate those conventions without the hassle to write them. The following code would generate the same bean, with the addition of an empty constructor :<syntaxhighlight lang="java">@NoArgsConstructor

===Transparently adding services===

public class MyBean {

@Getter @Setter

As designs using POJOs have become more commonly used, systems have arisen that give POJOs the full functionality used in frameworks and more choice about which areas of functionality are actually needed. In this model, the programmer creates nothing more than a POJO. This POJO purely focuses on [[business logic]] and has no dependencies on (enterprise) frameworks. [[Aspect-oriented programming|AOP]] frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.<ref>Martin, Robert C. (2008). Clean Code. Chapter 11, Pure Java AOP Frameworks</ref>

private String someProperty;

}</syntaxhighlight>Other libraries or framework generate code (or bytecode) with those conventions directly. The addition of those tools help alleviate the [[Boilerplate code|boilerplate]], which in turn reduces the bugs frequency and maintenance cost .

===Transparently adding services===

As designs using POJOs have become more commonly used, systems have arisen that give POJOs the full functionality used in frameworks and more choice about which areas of functionality are actually needed. In this model, the programmer creates nothing more than a POJO. This POJO purely focuses on [[business logic]] and has no dependencies on (enterprise) frameworks. [[Aspect-oriented programming|AOP]] (AOP) frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.<ref name="Martin2008">Martin, Robert C.; (2008).; ''Clean Code.'', Chapter 11, ''Pure Java AOP Frameworks''</ref>

[[Spring Framework|Spring]] was an early implementation of this idea and one of the driving forces behind popularizing this model.

Line 66 ⟶ 70:

* [[Enterprise JavaBeans]] (EJB),

* [[Java Persistence API|JPA]] (JPA) (including [[Hibernate (Java)|Hibernate]])

* [http://jcp.org/en/jsr/summary?id=299 CDI (Contexts and Dependency Injection for the Java EE platform)]

The following shows a fully functional EJB bean, demonstrating how EJB3 leverages the POJO model:

Line 92 ⟶ 96:

</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). EJB3''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 showedshown above but with an annotation added. In this case the XML file is no longer needed:

<syntaxhighlight lang="java">

Line 106 ⟶ 110:

</syntaxhighlight>

With the annotation as given above the bean isn't a truly pure POJO anymore, but since annotations are merely passive metadata this has far fewer harmful drawbacks compared to the invasiveness of having to extend classes and/or implement interfaces.<ref>Martin, Robertname="Martin2008" C. (2008). Clean Code. Chapter 11, Pure Java AOP Frameworks</ref> Accordingly, the programming model is still very much like the pure POJO model.

==Related Acronyms==

==={{Anchor|POJI}}Plain old Java Interface===

A Plain old Java Interface (POJI) is a basic form of [[Interface (Java)|Java interface]] and acceptable at points where more complex Java interfaces are not permitted.<ref name="RAD"/>{{rp|57,572,576,579,1340}}

==See also==

* [[Data transfer object]] (DTO)

* [[Anemic ___domain model]]

* [[KISS principle]]

==References==

{{Reflist}}|refs=

<ref name="RAD">{{cite book|title=Rational Application Developer V7.5 Programming Guide|first1=Ueli|last1=Wahli|first2=Miguel|last2=Vieira|first3=Ferreira Lopes|last3=Gomes|first4=Brian|last4=Hainey|first5=Ahmed|last5=Moharram|first6=JuanPablo|last6=Napoli|first7=Marco|last7=Rohr|first8=Henry|last8=Cui|first9=Patrick|last9=Gan|first10=Celso|last10=Gonzalez|first11=Pinar|last11=Ugurlu|first12=Lara|last12=Ziosi|date=29 June 2009|publisher=IBM Redbooks|isbn=978-0738432892 }}</ref>

}}

[[Category:Computing acronyms]]

[[Category:Java (programming language)]]

[[Category:BrandComputer managementjargon]]