POJO (22.10.10 TIL)

POJO 란 무엇일까? 아래는 위키백과에 정의되어 있는 내용이다.

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. 

“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.”
 — 마틴 파울러 —

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다.

 정의에 따르면 POJO (Plain Old Java Object) 란 오래된 방식의 간단한 자바 오브젝트이다. 쉽게 풀이하면 특정 기술에 종속되지 않은 순수한 자바 객체를 의미하는 것이다. 예를 들어 특정 기술을 사용하기 위해 특정 프레임워크에 의존하게 되면 그것은 POJO 라고 할 수 없다.

왜 POJO 를 지향하는가?

 나는 여기서, 왜 POJO 를 지향해야 하는거지? 라는 의문이 생겼다. 기술은 사용하라고 있는 것인데 말이다. 이유를 찾아보니 스프링 이전 역사까지 거슬러 올라간다.

 스프링 프레임워크 이전에는 원하는 엔터프라이즈 기술이 있다면 그 기술을 직접적으로 사용하는 객체를 설계했다. 그 결과 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생겼다. 또한, 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지는 단점이 있었다. 이 말은 객체지향의 대표 주자인 자바가 객체지향 설계의 장점들을 잃어버리게 된 것이다.

 그래서 원래의 자바의 장점을 살리는 '오래된' 방식의 '순수한' 자바객체인 POJO라는 개념이 등장하게 되었다.

POJO 의 특징

 POJO 는 하나의 오브젝트 안에 상태와 행위를 모두 가지고 있는 특징이 있다. 즉 인스턴스 변수와 로직을 가진 메서드를 가지고 있는 것이다. 그렇게 만들기 위한 가장 간단한 방법은 오브젝트가 가지고 있어야 할 행위를 오브젝트로 옮겨주는 것이다.

 POJO 의 조건은 아래와 같다.

• 특정 규약에 종속되지 않아야 한다. 그렇지 않으면 단일 상속 제한 때문에 객체 지향적인 설계 기법을 적용하기 어렵고, 다른 환경으로의 이전이 어려워진다.
• 특정 환경에 종속되지 않아야 한다. 그렇지 않으면 다른 환경에서 사용하기 어렵고, 비즈니스 로직과 기술적인 내용을 담은 웹 정보 코드가 섞여 있어 이해하기 어려워진다. (ex. 웹 환경에 종속되는 HttpServletRequest나 HttpSession과 관련된 API 를 직접 이용하면 웹 서버에 올리지 않고 독립적으로 테스트하기 어려워진다.)
• 단일 책임 원칙을 지키는 클래스여야 한다. 책임과 역할이 다른 코드는 분리해야 한다.

 POJO 의 진정한 가치는 자바의 객체지향적인 특징을 살려 비즈니스 로직에 충실한 개발이 가능하도록 하는 것이다.

 토비의 스프링에서는 진정한 POJO 를 아래와 같이 정의한다.

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가? 많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. ...(중략)... 진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

 POJO 에 대해 알아보다보니 테스트 코드의 필요성을 한층 더 느끼게 되었다. '환경과 기술에 종속되지 않고 필요에 따라 재활용 할 수 있는 코드' 를 작성하기 위해서는 먼저 올바르게 동작하는 코드가 필요하고, 그런 코드는 테스트 코드를 작성함으로써 올바른 동작을 하는 코드인지의 여부를 확신할 수 있다. 코드 작성이 편리할수록 더 자주 더 꼼꼼하게 테스트할 수 있어 코드 검증과 품질 향상에 유리해진다. 잘만들어진 테스트 코드베이스가 있다면, 리팩토링할 여유가 생겨 POJO 코드를 좀 더 나은 설계 구조로 변경할 가능성도 높아진다.

---

++그럼 특정 기술을 사용하고 싶다면? (스프링이 POJO를 유지하면서 Hibernate를 사용할 수 있는 이유)

 Hibernate 는 스프링 개발에서 많이 사용하고 있는 기술이다.

 특정 기술에 종속적이면 POJO가 아니라면서 스프링에서는 어떻게 가능한 걸까? 바로 스프링에서 정한 표준 인터페이스가 있기 때문이다. 스프링 개발자들은 ORM이라는 기술을 사용하기 위해서 'JPA'라는 표준 인터페이스를 정해두었다. 그리고 이제 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래, 구현되어 실행된다. 이것이 스프링이 새로운 엔터프라이즈 기술을 도입 하면서도 POJO를 유지하는 방법이다.

 

참고: 

Plain Old Java Object - 위키백과, 우리 모두의 백과사전

만렙 개발자 키우기