Content deleted Content added
Michaelnakis (talk | contribs) Removed the part that says "and not requiring any class path" because it does not make any sense. There is nothing about POJOs that has anything to do with class paths. |
mNo edit summary |
||
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 [[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
</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>
Line 23:
===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 53 ⟶ 52:
===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>
| |||