POJO 정리

토비의 스프링을 탐독하면서 나온 단어중 POJO라는 개념이 있어서 간단히 정리한다.

 

 

POJO를 알기전에 EJB부터 알아보자.

EJB

EJB에 대해서 간단하게 이야기 하자면

Enterprise Java Bean의 약자로 처음에는 분산처리를 위해 탄생했다.

EJB스펙을 구현한 여러가지 제품이 출시 되었다.

그렇게 시간이 지나면서 EJB를 사용하면 DB연결, 트랜잭션, 보안 등에 신경을 쓰지 않아도 되었다.

어느새 분산처리를 위해 탄생한 EJB가 어느새 웹 어플리케이션 권장 설계가 되었다.

 

EJB를 사용하면 어플리케이션 핵심 로직과 비즈니스 로직을 일부분 분리하는 데 성공하긴 했다.

그러나

EJB환경에서 동작하기 위해서는

1. 특정 인터페이스를 구현 해야 했고

2. 특정 클래스를 상속 해야 했고

3. 서버의 종속적인 서비스를 통해서만 접근하고 사용해야 했다.

 

그래서

 

오히려 EJB라는 환경과 스펙에 종속되는 코드로 만들어져야(기술적 침투) 하는 더 큰 부담을 안게 됐다.

 

EJB는

- 객체 지향적이지 않음

- 복잡한 프로그래밍 모델

- 특정 환경, 기술에 종속적인 코드

- 자동화된 테스트가 매우 어려움

등의 문제점이 있었다.

 

그래서 이런것을 개선한것이 바로 Spring이다.

개발자들에게 봄이 왔다고 해서 spring

 

스프링 개발의 핵심 POJO

스프링의 목적은 어플리케이션 개발의 복잡함을 줄여 주는 것 또는 효과적으로 대응해주는것이다.

 

[Professional Spring Framework]라는 책이 있다.

이 책은 "스프링의 정수는 엔터프라이즈 서비스 기능을 POJO에 제공하는 것" 이라고 했다.

엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 어플리케이션 핵심 로직을 담은 코드에 제공한다.

 

* 엔터프라이즈 서비스 : 트랜잭션, 보안, DB 연결같은 시스템에서 요구되는 기술

 

여기서는 스프링의 개발의 핵심은 POJO이다 정도만 알면 될듯하다.

 

 

POJO

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. [1]
“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.” — 마틴 파울러
POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다. - 위키백과 -

 

마틴 파울러가 2000년에 컨퍼런스 발표를 준비하다가 만들어낸 용어라고 한다.

그런데 POJO라는 용어를 만들어낸 이유가 재미 있는데

당시 인기를 끌고있던 EJB처럼 복잡하고 제한이 많은 기술을 사용하는 것보다

자바의 간단한 오브젝트를 이용하여 비즈니스 로직을 구현하는것이 낫다고 생각했다.

 

그러나

 

왜? 개발자들은  자바의 간단한 오브젝트를 이용하길 꺼릴까? 생각했다.

이유를 찾아보니 자바의 간단한 오브젝트에는 EJB처럼 그럴싸한 이름이 없었기 때문이었고

그래서 뭔가 있어 보이도록 만든 이름이 바로 POJO이다

 

---

EJB는 특정 인터페이스, 클래스를 상속해야 했기 때문에

내가 원하는 인터페이스, 클래스를 상속 받을 수 없었다.

자바는 다중 상속이 안되니깐!

자바의 객체지향적인 장점을 하나도 못살리고 있다.!

 

그러니깐 자바의 간단한 오브젝트를 사용해서 자바 장점을 그대로 살리자!

 

 

POJO의 조건

 

1. 특정 규약에 종속되지 않는다.

 

POJO는 자바 언어와 꼭 필요한 API외에는 종속되지 않는다.

EJB처럼 특정 규약을 따라야 한다면 그건 POJO가 아니다.

스트럿츠1도 특정 클래스를 상속해야 만들어야만 하기 때문에 이것도 POJO가 아니다.

 

특정 규약을 따라 만들게 하는 경우에는 특정 클래스를 상속하도록 요구한다.

그럴 경우 자바는 단일 상속 제한 때문에 내가 원하는 객체지향적인 설계를 적용하기 어렵다.

 

또한 특정 규약에 종속된다면 다른 환경으로 이전하기도 어렵다.

 

별다른 가치를 주지도 못하는 규약 따위에 종속되지 말고

객체지향 설계의 자유로운 적용이 가능한 오브젝트이여먄 POJO라고 불릴 수 있다.

 

 

2. 특정 환경에 종속되지 않는다.

 

EJB3은 이전 버전의 단점인 특정 규약에 종속되는 문제를 해결했지만 

여전히 JNDI를 사용해야만 했고 JNDI가 없는 환경에서는 그대로 사용하기 힘들었다.

 

어떤 경우는 특정 회사가 출시한 제품의 API, 기능을 직접 쓴 경우가 있다.

Weblogic 서버에서만 사용가능한 API를 비즈니스 로직에 직접 코딩해서 WebLogic이 없는 서버에서 실행시키면 오류가 난다던가.

특정 OS가 제공하는 코드를 비즈니스 로직에 직접 코딩해서 OS가 바뀐경우 실행할수 없다던가

또한 웹 기술이 HttpSesion, Request등을 담은 비즈니스 로직이라면 웹 서버에 올리지 않고는 테스트가 어려울 수도 있고 웹 이외에는 대응하지 못할 수 있다.

 

특정 환경에 종속되어 있는 이런 경우 모두 POJO라고 할 수 없다.

POJO는 환경에 독립적이어야 한다.

대한독립만세

 

=> 그렇다면 기술규약과 환경에 종속되지 않으면 모두 POJO인가?

토비 선생님께서는 말씀하셨다.

자바 문법 철저히 지키면서 JavaSE API만을 사용했다고 해서 그 코드가 POJO라고 할 수 없다고

 

POJO는 객체지향적인 언어인 자바 언어의 기본에 충실하게 만들어 져야 한다!

자바 문법을 사용했다고 해서 객체지향적으로 프로그래밍 하지 않으면 객체지향적인 설계라고 볼 수 없다.

 

1 - 책임과 역할이 각기 다른 코드를 한 클래스에 몰아넣어 덩치 큰 만능 클래스를 만드는 경우

2 - 재사용이 불가능할 정도로 다른 레이어와 영역의 코드와 강한 결합을 가지고 만드는 경우

3 - 상속과 다형성을 사용하면 깔끔할것을 if/switch문으로 더럽게 분기처리해서 길고 긴 메소드를 작성한 경우

 

이런거는 객체지향적인 자바 오브젝트라고 볼수 없다. POJO가 아니다.

 

진정한 POJO는

객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용 할수있는 설계, 오브젝트를 말한다!