자바와 스프링 공부를 하면서 여러 자료를 찾아보는데 항상 POJO라는 단어가 많이 등장했다.
도대체 POJO가 뭐야..
보통 구글링을 하면 바로 "정의" 및 "사용법"이 나오는데 이건 정확한 정의가 없다.
심지어 사람들이 POJO와 자바빈의 정의를 가지고 토론을 하고 있다. (더 헷갈리기 시작한다..)
사실 여러 자료를 찾고 지금 이 포스팅을 쓰는 지금도 정확한 정의는 모르겠다.
여러 자료를 참고하여 대충 내가 느낀점을 우선 적어보려 한다.
https://itewbm.tistory.com/entry/POJOPlain-Old-Java-Object
위 링크의 내용을 살펴보면 POJO의 탄생 배경을 알 수 있다.
개발자가 비지니스 로직 외의 로우레벨 (트랜잭션, 멀티스레드 세이프한 보안 기능 등) 까지 직접 jdk를 사용하여 구현하기는 쉽지 않다.
가능하다 하더라도 확장 가능한, 재사용 가능한 코드를 짜기는 거의 불가능에 가깝다.
이러한 것을 보안하기 위해 sun사에서 EJB (엔터프라이즈 자바 빈즈)를 만들었다.
EJB를 사용함으로서 개발자는 비지니스 로직에 집중할 수 있게 되었다.
하지만, 한가지 기능을 위해 배보다 큰 배꼽을 사용해야하는 상황에 부딪혔다.
이러한 상황을 놓고 마틴 파울러라는 사람이 아래와 같은 말을 했다.
위 용어는 2000년 9월 한 컨퍼런스에서 Rebecca Parsons, Josh MacKenzie, 그리고 나 세 명이서 강연을 준비하는 와중에 생겨났다. 강연에서 우리는 Entity Bean을 사용하는 것보다 비즈니스 로직을 일반 자바 객체에 넣는 것이 훨씬 더 많은 이득을 가져다준다고 지적했다. 그런데 왜 사람들이 시스템 구축 시 일반 객체를 사용하는 것을 꺼리는지 그 이유가 궁금했다. 그리고, 단순한 객체에 아주 팬시한 이름이 없기 때문에 그렇다는 결론을 내렸다. 그래서 우리가 이름 하나를 지어줬고, 엄청나게 인기를 끌게 되었다.
즉, POJO 자체는 Plain Old Java Object 가 뜻하는 것처럼 그냥 단순한 자바 객체를 말하고 있다.
하지만, 위 링크에서 말하듯이 단순한 자바 객체를 사용한다고 하면 EJB가 나오기 전의 상황으로 돌아갈 수 밖에 없다.
그럼 도대체 POJO는 뭐란 말인가..
위 링크의 중반부에 이러한 말을 했다.
아래 링크를 참고해보자.
By using plain old Java objects, your code is much more simplified, which lends to better testing, flexibility, and ability to change technical decisions at future stages based on knowledge and shifting requirements.
"POJO를 사용함으로써, 당신의 코드는 더욱 심플해졌고, 그로인해 테스트 하기에 더 좋으며, 유연하고, 요구사항에 따라 기술적 선택을 바꿀수 있도록 바뀌었다. "
EJB에 대해서는 잘 모르지만,
몇몇 자료를 보니 클래스들이 extends, implements 를 사용하는 코드들이 많았다.
이렇게 할 경우, 각 클래스 간의 의존도가 생기기 때문에 추후에 다른 api로 바꾸던가 코드를 수정해야할 때 수정해야하는 부분이 많아지는 등 여러가지 불편한 점이 발생한다.
위 링크의 코드를 보면 extends, implements를 없애고 대신 어노테이션을 사용함으로써 의존도를 낮췄다.
첫번째 링크 중반부에서 한 내용을 충실히 따르고 있다.
구글링을 하면 많은 자료들이 POJO를 getter / setter를 가진 단순한 자바 오브젝트로 정의하고 있다.
위의 내용들에 근거하면 POJO는 "getter / setter를 가진 단순한 자바 오브젝트"이다 가 아니라
"getter / setter를 가진 단순한 자바 오브젝트"는 POJO이다. 라고 하는게 맞을것 같다.
"getter / setter를 가진 단순한 자바 오브젝트"는 분명 의존성도 없고, 테스트도 용이하며 추후 수정이 편리하니 POJO로 볼 수 있을것 같다.
이와 같은 개념을 가지고 EJB를 대체할 POJO 기반 프레임워크가 나왔고 그것이 하이버네이트와 스프링이라고 한다.
스프링은 EJB의 의존성 문제와 배보다 배꼽이 더 큰 문제를 해결하기 위해 POJO를 기반으로 만들어졌다.
스프링을 제대로 사용한다면 EJB를 대체하는 POJO의 개념을 충실히 갖춘 프로그래밍을 할 수 있겠지만
이것은 프로그래밍을 하는 개발자의 몫인듯하다.