Plain old Java object: Difference between revisions

Revision as of 18:20, 11 May 2020

Latest revision as of 18:50, 19 December 2024

(17 intermediate revisions by 15 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 (programming 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">{{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 |last=Almaer |first=Dion |work=Ajaxian |date=2006-07-17 |accessdate=2014-08-19 }}</ref>

The term "POJO" phenomenoninitially hasdenoted mosta likelyJava object which does not follow any of the major Java object models, conventions, or frameworks. It has since gained widespreadadoption as a language-agnostic acceptanceterm, because of the need for a common and easily understood term that contrasts with complicated object frameworks.{{Citation needed|date=April 2013}}

The term continues the pattern of older terms for technologies that do not use fancy new features, such as [[plain old Ruby object]] (PORO) in [[Ruby (programming language)|Ruby]], [[plain old telephone service]] (POTS) in [[telephony]] and [[Plain Old Documentation]] (pod) in [[Perl]]. The equivalent to POJO on the [[.NET framework]] is [[Plain old CLR object|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 |url-status=dead |archiveurl=https://web.archive.org/web/20120326195616/http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |archivedate=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 |accessdate=2012-05-27 |url-status=dead |archiveurl=https://web.archive.org/web/20120326195611/http://jym.sg/controller-with-bare-bone-plain-old-php-objec |archivedate=2012-03-26 }}

</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 |access-date=2012-05-27 }}

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

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

</ref> in [[PHP]]

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

==Definition==

Line 23 ⟶ 28:

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

Line 35 ⟶ 39:

The definition of the POJO can be as follows:

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

public class MyBean {

private String someProperty;

Line 47 ⟶ 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

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

Line 89 ⟶ 98:

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

<syntaxhighlight lang="java">

Line 110 ⟶ 119:

* [[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:Java (programming language)]]

[[Category:BrandComputer managementjargon]]