POJO - (Plain Old Java Object)란 뭘까?

POJO

자바나 스프링 프레임워크를 조금이라도 공부 해본 개발자 (혹은 학생)이라면 POJO 라는 단어를 한번쯤 듣게됩니다. POJO의 정의는 사실 그렇게 어렵지 않습니다. 아래 내용은 위키 백과에 나와있는 POJO에 대한 설명입니다.

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

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

 

근데 오래된 방식의 간단한 오브젝트가 뭘까요? 오래된 방식이 있다면 새로운 방식도 있는걸까요? 좀 더 풀어서 쉽게 말해보자면, 특정 '기술'에 종속되어 동작하는 것이 아닌 순수한 자바 객체를 말하는 겁니다.

 

예를들어, ORM(Object Relationship Mapping)이 새롭게 등장 했을 때를 생각해보겠습니다. ORM 기술을 사용하고 싶었다면 ORM을 지원하는 ORM 프레임워크를 사용해야 합니다. (대표적으로 Hibernate라는 프레임워크가 있습니다.) 만약 자바 객체가 ORM 기술을 사용하기 위해서 Hibernate프레임워크를 직접 의존하는 순간! POJO라고 할 수 없습니다. 특정 '기술'에 종속되었기 때문입니다.

왜 POJO를 지향해야 하는가?

스프링 프레임워크 이전에는 원하는 엔터프라이즈 기술이 있다면 그 기술을 직접적으로 사용하는 객체를 설계했습니다. 그리고 이러한 개발 방식이 만연하고 있었습니다. 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생겼습니다. 또한 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지는 단점이 있었습니다. 

이 말은 자바가 객체지향 설계의 장점들을 잃어버리게 된 것입니다.

 

그래서 POJO라는 개념이 등장했습니다. 본래 자바의 장점을 살리는 '오래된' 방식의 '순수한' 자바객체 말입니다.

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

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

진정한 POJO?

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

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가? 많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. ...(중략)...

진정한 POJO란 객체지향적인 원리에 충실하면서,

환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

토비 아저씨는 왜 이런 머리 아픈 이슈를 마지막에 던진걸까요? 제 생각엔 POJO의 등장이유를 생각해보라는 것 같습니다. (자바가 객체지향적 설계의 장점을 포기하고 특정 기술과 환경을 사용하기에 급급했던 예전 시절의 고통을 잊지말자는 교훈을...)