서론
POJO는 실무에서나 이번 게으른 개발자 컨퍼런스를 갔을 때도 객체지향에 대한 얘기를 할 때 간간히 나오는 개념이였다.
스프링에 입문한지 별로 안된 나는 그냥 프레임워크에 종속되지 않은 object라는 것만 생각하고 있었다.
그래도 스프링의 철학에 가장 밑바탕이 되는 개념인데 정리해봐야되지 않을까해서 적어본다.
(헥사고날 아키텍쳐 비슷하게 구성하려고 할 때 필요한 개념이기도 하다ㅎㅎ)
POJO
Plain Old Java Object
특정 모델이나 기능 프레임워크를 따르지 않는 자바 오브젝트를 지칭한다.
간단하게 말하면 자바로 생성하는 순수한 객체이다.
어디에도 종속되지 않기 떄문에 어디든 제약없이 사용할 수 있게 되는 것이다.
다른 클래스나 인터페이스를 상속받지 않는 클래스이다.
그런데 EJB 이전(빈 생성)으로 돌아가는 꼴이 되버리니 POJO 형태에 걸맞는 프레임워크가 등장했는데
그게 하이버네이트, 스프링 이다.
가장 많이 사용하는 예제를 가져와서 보면
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");
}
}
}데코레이터를 이용해 바꿔서 사용할 수 있도록 결합도를 낮춘것을 볼 수 있다.
@Component
public class ExampleListener {
@JmsListener(destination = "myDestination")
public void processOrder(String message) {
System.out.println(message);
}
}결론
- 의존 관게 주입 (Ioc/DI)
- 관점 중심 프로그래밍 (AOP)
- 이식 가능한 서비스 추상화 (PSA)
3가지를 충족한 객체가 POJO라고 볼 수 있다.
필요한 이유
- 특정 환경에 종속되지 않아 테스트하기 쉽다. (fake로 만들기가 쉬워진다)
- 재사용이 가능하고 확장 가능한 코드를 작성할 수 있다. (환경 상관 없이)
필자가 생각한 이유
- 기술의 복잡함은 프레임워크에 맡기고 작업자는 로직에 대한 내용만 신경쓰도록 하기 위함이 POJO 구성을 가져가야되는 큰 이유로 보인다.
참고
backend-developer