Plain Old Java Object
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
Plain Old Java Object(POJO)는 자바 언어 명세 외에 특별한 제약 없이 자바 객체를 정의하는 용어이다. POJO는 특정 클래스 확장, 인터페이스 구현, 또는 애너테이션 사용에 얽매이지 않아야 한다. POJO 개념은 스프링 프레임워크와 같은 POJO 기반 프레임워크의 발전에 기여했으며, 지속성, 트랜잭션, 보안과 같은 기능을 제공한다. POJO는 POPO, POCO, PODS 등 다른 프로그래밍 언어 및 기술에서도 유사한 개념으로 사용된다. POJO의 유연성에도 불구하고, 일부에서는 애너테이션 사용이 POJO의 순수성을 훼손한다고 비판하기도 한다.
더 읽어볼만한 페이지
- 자바 (프로그래밍 언어) - 자바 애플릿
자바 애플릿은 웹 페이지에서 실행되는 자바 기반 프로그램으로, 웹 상호작용성을 높였으나 기술적 문제와 웹 표준 기술 발전에 따라 쇠퇴하여 사용이 중단되었다. - 자바 (프로그래밍 언어) - 자바FX
JavaFX는 자바 기반의 UI 구축 플랫폼으로, 다양한 플랫폼을 지원하며 풍부한 UI 기능들을 제공하고, Java 8부터 JDK에 포함되었다가 JDK 11부터 분리되어 관리된다. - 브랜드 경영 - 저작권
저작권은 창작자의 권익 보호와 문화 발전에 기여하기 위해 문학, 예술, 음악 등 인간의 창작물에 대해 창작자에게 부여되는 법적 권리로서, 저작인격권과 저작재산권으로 구성되며, 국제 조약 및 각국 국내법을 통해 보호되지만 디지털 기술 발전으로 보호와 이용 간 균형에 대한 논쟁이 지속되고 있다. - 브랜드 경영 - 사치품
사치품은 필수재가 아닌 소득탄력성이 1보다 큰 재화 또는 서비스로, 미술사적으로는 화려한 장식과 고가 재료를 사용한 물건을 의미하며, 최근에는 "접근 가능한 고급"이라는 새로운 범주가 등장하여 시장이 성장하고 있다.
| Plain Old Java Object | |
|---|---|
| 일반 정보 | |
| 이름 | Plain old Java object |
| 유형 | 객체 |
| 프로그래밍 언어 | 자바 |
| 약칭 | POJO |
| 설명 | |
| 정의 | 특별한 제약이나 프레임워크 의존성이 없는 일반적인 자바 객체 |
| 특징 | 특정 인터페이스 구현 불필요 특정 클래스 상속 불필요 특정 어노테이션 사용 불필요 |
| 목적 | 코드의 가독성 및 유지보수성 향상 |
| 같이 보기 | |
| 관련 개념 | 엔터프라이즈 자바 빈즈 POX 스프링 프레임워크 POCO POPO |
2. 정의
이상적으로, POJO는 자바 언어 사양 외에 어떠한 제한에도 묶이지 않은 자바 객체라고 할 수 있다. 즉, POJO는 다음과 같은 제약을 받지 않아야 한다.
POJO를 사용하는 설계가 더 일반적으로 사용됨에 따라, POJO에 프레임워크에서 사용되는 기능을 제공하면서도 필요한 기능 영역에 대한 선택권을 넓히는 시스템들이 등장했다. 이러한 모델에서 프로그래머는 순수하게 비즈니스 로직에 초점을 맞춘 POJO만을 작성하며, 특정 (엔터프라이즈) 프레임워크에 대한 의존성을 갖지 않는다. 이후 관점 지향 프로그래밍 (AOP) 프레임워크가 지속성, 트랜잭션, 보안 등과 같은 횡단 관심사(cross-cutting concerns)를 투명하게 추가하는 방식으로 동작한다.[6] 이러한 접근 방식은 개발자가 핵심 비즈니스 로직 구현에 더 집중할 수 있도록 돕는다.
# 미리 정의된 클래스(예: `javax.servlet.http.HttpServlet`)를 확장하지 않아야 한다.
# 미리 정의된 인터페이스(예: `javax.ejb.EntityBean`)를 구현하지 않아야 한다.
# 미리 정의된 애너테이션(예: `@javax.persistence.Entity`)을 포함하지 않아야 한다.
그러나 기술적 어려움이나 다른 이유로 인해, 실제로는 퍼시스턴스(persistence)와 같은 기능을 위해 미리 정의된 애너테이션 사용을 요구하는 프레임워크나 소프트웨어 제품도 많다. 핵심은 특정 프레임워크의 애너테이션 등을 추가하기 전에는 POJO였고, 이를 제거했을 때 다시 POJO 상태로 돌아갈 수 있다면 여전히 POJO로 간주할 수 있다는 점이다.
이 용어는 2000년 9월 마틴 파울러, 레베카 파슨스, 조쉬 매켄지가 복잡한 엔터프라이즈 프레임워크에 대비하여 단순한 객체를 지칭하기 위해 처음 사용했다.[1] 이는 고급 신기능을 사용하지 않는 기술(예: 통신의 POTS, C++에서의 PODS)에 대한 기존 용어 명명 패턴을 따른 것이다. 이 용어가 널리 받아들여진 배경에는 복잡하고 특수한 객체 프레임워크와 대조되는, 일반적이고 이해하기 쉬운 용어에 대한 요구가 있었기 때문이다.
JavaBean은 특정 명명 규칙(인자 없는 생성자, getter/setter 메서드)을 따르고 직렬화가 가능한 POJO의 한 형태이다. 다만, `Serializable` 인터페이스 구현 요구사항은 엄밀히 말해 POJO의 기본 정의에서 벗어나는 측면이 있다. 많은 POJO 클래스가 이 요구사항을 충족하지 않음에도 JavaBeans로 불리기도 한다.
시간이 지남에 따라 EJB 3와 같이 애너테이션을 사용함에도 스스로 POJO 프로그래밍 모델을 표방하는 경우도 나타나는 등, 용어의 의미는 문맥에 따라 다소 유연하게 해석되기도 한다.
3. POJO 기반 프레임워크
스프링은 이러한 아이디어를 초기에 구현한 대표적인 예시이며, POJO 기반 개발 모델을 대중화하는 데 중요한 역할을 했다.
POJO를 활용하는 다른 기술들의 예시는 다음과 같다.
다음은 EJB 3.0 버전이 어떻게 POJO 모델을 활용하는지 보여주는 예시이다. 아래 코드는 특별한 EJB 클래스를 상속하거나 인터페이스를 구현하지 않은 간단한 자바 클래스이다.
public class HelloWorldService {
public String sayHello() {
return "Hello, world!";
}
}
이 클래스를 EJB로 사용하기 위해, 과거에는 외부 XML 설정 파일을 통해 필요한 EJB 서비스를 선언했다.
하지만 XML 설정 방식은 코드가 길어지고 관리가 어렵다는 비판이 있었다. 이에 대한 대안으로 많은 프레임워크(스프링, EJB, JPA 등)는 어노테이션을 사용하여 설정을 코드 내에 직접 명시하는 방식을 지원한다. 아래는 어노테이션을 사용하여 동일한 EJB 빈을 정의한 예시이다. 이 경우 별도의 XML 파일이 필요 없다.
@Stateless
public class HelloWorldService {
public String sayHello() {
return "Hello, world!";
}
}
일부 개발자들은 어노테이션 방식이 간결하고 우아하다고 평가하는 반면, 다른 개발자들은 어노테이션이 POJO의 순수성을 해친다고 보기도 한다.[7] 어노테이션을 사용하면 엄밀히 말해 순수한 POJO는 아니게 되지만, 어노테이션은 단순히 메타데이터를 추가하는 방식이므로, 특정 클래스를 상속하거나 인터페이스를 구현해야 하는 과거 방식에 비해 코드 침투성이 훨씬 낮다.[6] 결과적으로 프로그래밍 모델은 여전히 순수 POJO 모델과 매우 유사하게 유지된다.
4. POJO 관련 용어
POJO라는 용어는 기존의 복잡한 프레임워크 대신 일반적이고 쉬운 용어가 필요한 다른 분야에도 널리 사용되기 시작했다. 이와 유사한 개념을 나타내는 용어들은 다음과 같다.
- POPO: Plain Old PHP Object의 약자로, PHP 언어에서 사용된다.
- POCO: Plain Old CLR Object의 약자로, 닷넷 프레임워크에서 사용된다.
- PODS: Plain Old Data Structures의 약자로, C++ 언어에서 C 언어의 특징만을 사용하는 구조체를 가리킨다. Plain old data structure|플레인 올드 데이터 스트럭처eng라고도 한다.
- POD: Plain Old Documentation의 약자로, 펄(Perl) 언어에서 사용되는 간단한 문서 형식을 의미한다.
- POTS: Plain Old Telephone Service의 약자로, 기본적인 전기 통신 서비스를 뜻하며, POJO와 같은 용어 명명 방식의 예시 중 하나이다.
POJO라는 용어는 2000년 9월에 마틴 파울러, 레베카 파슨스, 조쉬 매켄지에 의해 처음 사용되었다. 마틴 파울러는 "시스템에 평범한 객체를 사용하는 것에 강한 거부감을 가진 사람이 많은 이유가 무엇인지 생각했을 때, 그것은 단순한 객체에 좋은 이름이 없기 때문이라는 결론에 도달했다. 그래서 우리가 이름을 붙였더니, 그것이 매우 유행하게 되었다."라고 설명했다.마틴 파울러의 설명 이 명명법은 POTS나 PODS처럼, 특정 기술의 고급 신기능을 사용하지 않는 기본적인 형태를 지칭하는 기존 용어들의 패턴을 따른다.
이 용어가 널리 받아들여진 배경에는 복잡하고 특수한 객체 프레임워크와 대조되는, 일반적이고 이해하기 쉬운 용어에 대한 필요성이 있었다. 또한, JavaBeans와 Enterprise JavaBeans(EJB)의 이름이 혼동을 일으킬 수 있는 상황에서 POJO는 더 명확하고 매력적인 대안으로 여겨졌다. JavaBeans는 엄격한 명명 규칙을 가진 직렬화 가능한 POJO에 가깝지만, EJB는 단일 클래스가 아닌 완전한 컴포넌트 모델이다(EJB 3 이후로는 그 차이가 줄어들고 있다).
사실 POJO의 개념 자체는 이 용어가 만들어지기 전부터 존재했다. 객체 클래스의 가장 기본적인 형태는 특별할 것이 없기 때문이다. POJO라는 용어의 의의는 개발자들에게 특정 프레임워크를 사용하는 것의 장점이 그 복잡성을 감수할 만큼 충분한지를 고민하게 만든다는 점에 있다. 단순한 설계가 더 나은 선택일 수 있음을 상기시키는 명확한 용어가 없었다면, 불필요하게 복잡한 프레임워크가 시스템 아키텍처에 도입되기 쉬웠을 것이다. POJO를 활용한 설계가 보편화되면서, Hibernate나 Spring과 같은 프레임워크들의 일부 기능이 POJO만으로도 구현 가능하다는 점이 명확해졌고, 필요한 기능 영역에 대한 선택의 폭이 넓어졌다.
5. 비판적 관점
POJO 개념은 단순성을 지향하지만, 실제 프레임워크 적용 과정에서는 논란이 존재한다. 특히 애너테이션의 사용이 POJO 모델의 순수성을 해친다는 비판이 제기된다.[7]
과거에는 외부 XML 파일을 통해 설정을 관리하는 방식이 사용되었으나, 이는 파일 내용이 길고 복잡해지며 유지보수가 어렵다는 단점이 있었다. 이러한 문제를 해결하기 위해 스프링, EJB, JPA 등 많은 프레임워크에서는 애너테이션 사용을 대안으로 지원하게 되었다.
애너테이션은 코드를 더 간결하게 만들 수 있다는 장점이 있지만, 일각에서는 애너테이션이 POJO의 본질적인 단순성을 저해하고 특정 프레임워크에 대한 의존성을 높인다고 비판한다.[7] 예를 들어, EJB 3는 스스로 POJO 프로그래밍 모델을 따른다고 선언하지만, 실제로는 `@Stateless`와 같은 애너테이션을 코드에 직접 추가해야 필요한 기능을 사용할 수 있는 경우가 많다.
애너테이션이 추가된 코드는 엄밀히 말해 순수한 POJO라고 보기는 어렵다. 하지만 애너테이션은 단순히 메타데이터를 추가하는 방식이므로, 특정 클래스를 상속받거나 인터페이스를 구현해야 하는 방식에 비해 코드에 직접적인 영향을 미치는 정도가 낮다는 점에서 현실적인 절충안으로 여겨지기도 한다.[6]
결론적으로 "POJO"라는 용어 자체의 정의가 다소 모호하며[6], 기술이나 프레임워크의 발전에 따라 그 의미가 유동적으로 변화할 수 있다는 점을 고려해야 한다.
참조
[1]
웹사이트
MF Bliki: POJO
http://www.martinfow[...]
[2]
웹사이트
Return of the POJO: Plain 'Ole JavaScript
https://web.archive.[...]
2014-08-19
[3]
웹사이트
POCO Support
http://msdn.microsof[...]
2012-05-27
[4]
웹사이트
typesafe objects in PHP
https://web.archive.[...]
2012-05-27
[5]
웹사이트
Controller with bare-bone Plain Old PHP Object aka POPO
https://web.archive.[...]
2012-05-27
[6]
서적
Clean Code
2008
[7]
서적
EJB 3 in action
www.manning.com/book[...]
Manning Publications Co.
2007
[8]
웹인용
POJO
http://www.martinfow[...]
2012-06-07
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com