1. POJO (Plain Old Java Object)
Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조시 맥킨지 등이 사용하기 시작한 용어로써 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다.
여기서 오래된 방식의 간단한 자바 오브젝트가 무엇인가?
쉽게 말하면, 특정 기술과 환경에 종속되어 동작하는 것이 아닌 순수한 자바 객체를 말한다.
음.. 조금 깊이 있게 설명을 하자면, ORM 기술을 사용하고 싶다면 ORM 프레임워크를 사용해야 한다. 만약 자바 객체가 ORM 기술을 사용하기 위해 ORM 프레임워크를 의존하는 순간 POJO라고 할 수 없다.
앞서 언급했다시피 특정 기술에 종속되어 있기 때문이다.
2. POJO를 지향해야 하는 이유
POJO의 목적은 자바의 객체지향적인 특징을 살려 비즈니스 로직에 충실한 개발이 가능하도록 하는 것이다.
복잡한 개발의 필요조건을 충족시킬 수 있도록 POJO 기반의 프레임워크를 적절히 이용하는 것이 요구된다. 단순히 POJO 프레임워크를 사용하는 것이 아니라 그에 대한 여러 기준을 지켜야 한다.
가. 객체지향적인 설계 원칙에 충실하도록 개발
- POJO는 자바 오브젝트는 객체지향 언어로서 자바 오브젝트의 특징을 잘 가져야 한다.
- 테스트하기 힘든 구조, 확장이나 재활용이 어려움이 있으면 안 된다.
나. 테스트가 용이
- POJO 철학을 이용해 만들어진 애플리케이션은 자동화된 테스트 코드 작성이 편리해야 한다.
3. POJO의 조건
가. 특정 규약에 종속되지 않는다.
POJO는 자바와 꼭 필요한 API 외에는 종속되지 않아야 한다. 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구한다.
자바의 단일 상속 제한 때문에 더 이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생긴다. 또한 규약이 적용된 환경에 종속적이 되기 때문에 다른 환경으로 이전이 힘들다는 문제점이 있다.
나. 특정 환경에 종속되지 않는다.
순수한 애플리케이션 로직을 담고 있는 오브젝트 코드가 특정 환경에 종속되게 만드는 경우라면 그것 역시 POJO라고 할 수 없다. POJO는 환경에 독립적이어야 한다.
비즈니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경정보나 웹 기술을 담고 있는 Class나 implements를 사용해서는 안된다.
비즈니스 로직을 담은 코드에 HttpServletRequest나 HttpSession, 캐시와 관련된 API가 등장하거나 웹 프레임워크의 클래스를 직접 이용하는 부분이 있다면 그것은 진정한 POJO라고 볼 수 없다.
단지 자바의 문법을 지키고, 순수하게 JavaSE API만을 사용했다고 해서 그 코드를 POJO라고 할 수는 없다. POJO는 객체지향적인 자바 언어의 기본에 충실하게 만들어져야 하기 때문이다.
4. 기본적인 형태의 POJO는?
public class User {
private int name;
private int value;
public int getName() {
return name;
}
public int getValue() {
return value;
}
public void setName(int name) {
this.name = name;
}
public void setValue(int value) {
this.value = value;
}
}
순수한 자바 오브젝트
Getter와 Setter로 구성된 가장 순수한 형태의 기본 클래스를 POJO라 하며, 이는 Spring에서 고안된 철학의 핵심적인 부분을 구성하는 요소로 사용된다
5. POJO 개념을 사용하는 것과 사용하지 않는 것은?
눈에 크게 띄는 예시를 위해 스프링 프레임워크에서 JMS(자바 메시지 서비스)의 MessageListener로부터 메시지를 받는 예시를 살펴보겠다.
가. 개념을 사용하지 않는
public class ExampleListener implements MessageListener {
public void onMessage(Message message) {
if (message instanceof TextMessage) {
try {
System.out.println(((TextMessage) message).getText());
}
catch (JMSException ex) {
throw new RuntimeException(ex);
}
}
else {
throw new IllegalArgumentException("Message must be of type TextMessage");
}
}
}
JMS를 사용하기 위해 MessageListener 인터페이스를 상속받아야 한다.
하지만, JMS라는 특정 환경에 종속되게 되고 다른 메시징 설루션을 적용하기 어려워지고, 단순한 예제와 달리 Listener가 많은 경우, 다른 설루션으로 교체할 경우 더더욱 어려울 것이다.
나. 개념을 사용하고 있는
@Component
public class ExampleListener {
@JmsListener(destination = "myDestination")
public void processOrder(String message) {
System.out.println(message);
}
}
반면, POJO 개념을 사용하고 있는 코드를 보면 어떠한 인터페이스에 종속되지 않는다.
@JmsListenr라는 어노테이션을 이용하여 JMS 서비스를 이용할 수 있고, 다른 설루션을 사용하고 싶은 경우, @RabbitListener로 바꿔주기만 하면 된다.
스프링 프레임워크는 위의 예제처럼 우리의 라이브러리와의 결합성을 줄이도록 도와준다.
댓글