Plain Old Java Object
From Wikipedia, the free encyclopedia
POJO is an acronym for Plain Old Java Object, and is favoured by advocates of the idea that the simpler the design, the better. The name is used to emphasize that the object in question is not somehow special but an ordinary Java Object, in particular not an EJB (especially before EJB 3, that is). The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000. "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 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 PODS (Plain Old Data Structures) that are defined in C++ but use only C language features.
The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated, special object frameworks. It is more attractive than the Java "bean" terms because of the naming conflict between JavaBeans and Enterprise JavaBeans. The former is to large extent a POJO that follows rigorous naming conventions and is serializable, whereas the latter is not a single class but an entire component model (again, EJB 3 reduces the degree of difference).
The POJO concept obviously far predates the POJO term, because the natural condition of an object class is that it is not special. A large part of the usefulness of the term is it encourages developers to consider whether the benefits of using some framework are sufficient to justify its complexity. Without an explicit term as a reminder that simpler designs can be better, it is easier for a complicated framework to become included in the architecture of a system without sufficient reason. As POJO designs have become more commonly used, systems have arisen that can give POJOs some of the functionality of larger frameworks, with more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.
[edit] Possible ambiguity
As of November 2005, the term "POJO" is mainly used to denote a Java object which does not follow any of the (major) Java object models, conventions, or frameworks such as EJB. However, this definition is inherently unstable and ambiguous, considering the possible changes in the models and frameworks, and the fact that such a categorization itself is context-dependent.
In the strictest sense, all Java objects can be referred to as POJOs. Under this interpretation, statements that involve POJOs should apply to all Java objects without exception. However, many people disagree with this view.
The EJB 3 specification proclaims a POJO programming model and describes EJB3 Session beans as POJOs, though they usually require annotations....
