fbpx
Wikipedia

Plain old Java object

April 17, 2023

In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:[1]

"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."[1]

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.[2]

The term continues an acronym pattern to coin retronyms for technologies that do not use fancy new features: plain old Ruby object (PORO) in 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 (POCO).[3] For PHP, it is plain old PHP object (POPO).[4][5]

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]

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

  1. Extend prespecified classes, as in
    public class Foo extends javax.servlet.http.HttpServlet { ...
  2. Implement prespecified interfaces, as in
    public class Bar implements javax.ejb.EntityBean { ...
  3. Contain prespecified annotations, as in
    @javax.persistence.Entity public class Baz { ...

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

Contextual variations

JavaBeans

A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using 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 Serializable interface to be a true JavaBean. Many POJO classes still called JavaBeans do not meet this requirement. Since 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 bidirectional binding to a POJO's property: 

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

The definition of the POJO can be as follows: 

public class MyBean { private String someProperty; public String getSomeProperty() { return someProperty; } public void setSomeProperty(String someProperty) { this.someProperty = someProperty; } }

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.

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.[6]

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

An example of an EJB bean being a POJO:

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

public class HelloWorldService { public String sayHello() { return "Hello, world!"; } }

As given, the bean does not need to extend any EJB class or implement any EJB interface and also does not need to contain any EJB annotations. Instead, the programmer declares in an external XML file which EJB services should be added to the bean: 

<enterprise-beans> <session> <ejb-name>helloWorld</ejb-name> <ejb-class>com.example.HelloWorldService</ejb-class> <session-type>stateless</session-type> </session> </enterprise-beans>

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.[7]

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

@Stateless public class HelloWorldService { public String sayHello() { return "Hello, world!"; } }

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.[6] Accordingly, the programming model is still very much like the pure POJO model.

Related Acronyms

Plain old Java Interface

A Plain old Java Interface (POJI) is a basic form of Java interface and acceptable at points where more complex Java interfaces are not permitted.[8]: 57, 572, 576, 579, 1340 

See also

References

  1. ^ a b "MF Bliki: POJO". MartinFowler.com.
  2. ^ Almaer, Dion (2006-07-17). . Ajaxian. Archived from the original on 2014-09-13. Retrieved 2014-08-19.
  3. ^ "POCO Support". microsoft.com. Retrieved 2012-05-27.
  4. ^ Kneschke, Jan (2007-02-19). . kneschke.de. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
  5. ^ Cheong, Jym (2011-06-26). . jym.sg. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
  6. ^ a b Martin, Robert C; (2008); Clean Code, Chapter 11, Pure Java AOP Frameworks
  7. ^ 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
  8. ^ Wahli, Ueli; Vieira, Miguel; Gomes, Ferreira Lopes; Hainey, Brian; Moharram, Ahmed; Napoli, JuanPablo; Rohr, Marco; Cui, Henry; Gan, Patrick; Gonzalez, Celso; Ugurlu, Pinar; Ziosi, Lara (29 June 2009). Rational Application Developer V7.5 Programming Guide. IBM Redbooks. ISBN 978-0738432892.

April 17, 2023
plain, java, object, software, engineering, plain, java, object, pojo, ordinary, java, object, bound, special, restriction, term, coined, martin, fowler, rebecca, parsons, josh, mackenzie, september, 2000, wondered, people, were, against, using, regular, objec. In software engineering a plain old Java object POJO is an ordinary Java object not bound by any special restriction The term was coined by Martin Fowler Rebecca Parsons and Josh MacKenzie in September 2000 1 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 1 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 2 The term continues an acronym pattern to coin retronyms for technologies that do not use fancy new features plain old Ruby object PORO in 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 POCO 3 For PHP it is plain old PHP object POPO 4 5 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 Contents 1 Definition 2 Contextual variations 2 1 JavaBeans 2 2 Transparently adding services 3 Related Acronyms 3 1 Plain old Java Interface 4 See also 5 ReferencesDefinition EditIdeally 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 inpublic class Foo extends javax servlet http HttpServlet Implement prespecified interfaces as inpublic class Bar implements javax ejb EntityBean Contain prespecified annotations as in javax persistence Entity public class Baz 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 Contextual variations EditJavaBeans Edit A JavaBean is a POJO that is serializable has a no argument constructor and allows access to properties using 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 Serializable interface to be a true JavaBean Many POJO classes still called JavaBeans do not meet this requirement Since 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 bidirectional binding to a POJO s property lt h inputText value MyBean someProperty gt The definition of the POJO can be as follows public class MyBean private String someProperty public String getSomeProperty return someProperty public void setSomeProperty String someProperty this someProperty someProperty 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 Transparently adding services Edit 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 6 Spring was an early implementation of this idea and one of the driving forces behind popularizing this model An example of an EJB bean being a POJO Enterprise JavaBeans EJB Java Persistence API JPA including Hibernate 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 public class HelloWorldService public String sayHello return Hello world As given the bean does not need to extend any EJB class or implement any EJB interface and also does not need to contain any EJB annotations Instead the programmer declares in an external XML file which EJB services should be added to the bean lt enterprise beans gt lt session gt lt ejb name gt helloWorld lt ejb name gt lt ejb class gt com example HelloWorldService lt ejb class gt lt session type gt stateless lt session type gt lt session gt lt enterprise beans gt 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 7 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 shown above but with an annotation added In this case the XML file is no longer needed Stateless public class HelloWorldService public String sayHello return Hello world 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 6 Accordingly the programming model is still very much like the pure POJO model Related Acronyms EditPlain old Java Interface Edit A Plain old Java Interface POJI is a basic form of Java interface and acceptable at points where more complex Java interfaces are not permitted 8 57 572 576 579 1340 See also EditData transfer object DTO Anemic domain model KISS principleReferences Edit a b MF Bliki POJO MartinFowler com Almaer Dion 2006 07 17 Return of the POJO Plain Ole JavaScript Ajaxian Archived from the original on 2014 09 13 Retrieved 2014 08 19 POCO Support microsoft com Retrieved 2012 05 27 Kneschke Jan 2007 02 19 typesafe objects in PHP kneschke de Archived from the original on 2012 03 26 Retrieved 2012 05 27 Cheong Jym 2011 06 26 Controller with bare bone Plain Old PHP Object aka POPO jym sg Archived from the original on 2012 03 26 Retrieved 2012 05 27 a b Martin Robert C 2008 Clean Code Chapter 11 Pure Java AOP Frameworks 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 Wahli Ueli Vieira Miguel Gomes Ferreira Lopes Hainey Brian Moharram Ahmed Napoli JuanPablo Rohr Marco Cui Henry Gan Patrick Gonzalez Celso Ugurlu Pinar Ziosi Lara 29 June 2009 Rational Application Developer V7 5 Programming Guide IBM Redbooks ISBN 978 0738432892 Retrieved from https en wikipedia org w index php title Plain old Java object amp oldid 1143317019, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.