채용 과제 진행중 'POJO 형태로 구현'이라는 요구사항을 받았다.
POJO? 종종 들어보긴 했는데 무슨 의미지??
정의를 찾아보니
'Plain Old Java Object' - 오래된 방식의 간단한 자바 오브젝트
오래된?
간단한?
너무 추상적이었다...
처음엔 프레임워크나 라이브러리를 사용하지 않은
옛날에 만들던 야구게임 같은 순수 Java Code를 말하는건가? 싶었다.
그러던 중...
'Spring은 POJO 방식을 활용하는 대표적인 프레임워크이다.'
-다수의 블로그 글 참조-
엥?
간단한 형태라면서 프레임워크라고??
다시 읽어보니
POJO '방식'을 활용!
'아하 어떤 정해진 오브젝트가 아니라 Code 방식을 의미하는 것이구나' 라고
어렴풋하게는 이해가 됬지만 그래도 뭔지 정확히 와닿지가 않았다.
더 찾아보니 3가지에서 비교적(?) 자유로운 Code 방식이라는 의견이 많았다.
- 상속
- 인터페이스
- 어노테이션
이와 대비되는 가장 대표적인 예는 Servlet이라 한다.
UserServlet extends HttpServlet서블릿의 경우 사용하려면 HttpServlet을 반강제적으로 상속 받아야하고
그렇게 되면 단일 상속인 자바의 경우 다른 클래스는 상속 받지 못하게 된다.
확장성 있는 유연한 활용이 어려워지는 것이다.
마지막으로 POJO의 유래을 정리하자면
우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다.
그래서 적당한 이름(POJO)을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.
-마틴 파울러- (위키백과 발췌)
마틴 파울러 역시 멋있다.
찾아봐도 이 말을 사용한 2000년 이후 발표 이후로 딱히 정확한 정의가 없는 것으로보아
POJO란 좀 더 유연한 Java Code의 지향점에 가까운 용어인 것 같다. 정확히 모르겠다...
그래도 이러한 용어가 생긴 이후로 사람들이 기존에 무거운 EJB의 문제점을 인식하고
좀 더 유연한 방식을 고민하고 지향하게 된 것이 아닐까라는 생각을 가지며 글을 마친다.
(마틴 파울러👍)
