POJO의 개념

In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction and not requiring any class path. 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 the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and Pod (Plain Old Documentation) 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]

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

출처 : 위키피디아(EN)

'JAVA > Spring Framework' 카테고리의 다른 글

03. Spring DI의 개념  (0) 2016.10.27
01. Spring Framework을 사용해야 하는 이유  (0) 2016.09.05
글을 시작하기에 앞서...  (0) 2016.09.05

+ Recent posts