Content deleted Content added
fixed POCO link. |
m oops, fix duplicate ref |
||
| (18 intermediate revisions by 16 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
"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"
</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 }}▼
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> 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<
#Implement prespecified interfaces, as in<
#Contain prespecified [[Java annotation|annotations]], as in<
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) were 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 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
<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:
| |||