POJO
POJO는 Plain Old Java Object 즉, 평범한 오래된 자바 객체를 의미한다. 그런데 조금 이상하다. 왜 굳이 평범한 자바 객체에 이름이 붙게 되었을까? 이를 이해하기 위해서는 POJO라는 용어가 어떻게 등장하였는지 배경을 알아볼 필요가 있다.
POJO 용어의 등장 배경
우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. -마틴 파울러-
POJO라는 용어는 마틴파울러가 2000년 컨퍼런스에서 처음으로 사용한 용어이다. 스프링 프레임워크가 등장하기 이전까지 시간을 거슬러 올라가보자. IT 기술이 막 발전하던 초기에 Java 진영에서 다양한 프레임워크가 등장하고, 이에 따라 생산성이 많이 증가했다. 하지만 시간이 갈수록 이 문제는 객체지향적인 설계를 포기하고 특정 기술과 환경을 사용하기 급급하게 되었고, 객체를 프레임워크에 종속되도록 설계하는 방식이 늘어났다.
이때, 프레임워크의 기능을 사용하기 위해 위해 객체가 프레임워크에서 제공하는 특정 클래스를 상속하도록 요구하는 경우가 많았고, 자바의 단일 상속 제한으로 인해 더이상 객체지향적으로 코드를 작성할 수 없어졌다. 이런 문제는 결과적으로 유연성과 확장성을 낮추고, 유지보수가 어려운 코드를 낳는 문제를 발생하게 하였다.
이런 문제속에서 POJO라는 개념이 등장하였다. POJO의 핵심은 '자바 언어 스펙을 제외한, 특정 기술 (e.g. 프레임워크) 에 대한 종속성이 없는 객체' 이다. 즉, 어떤 자바 프로젝트에서도 사용 가능한 객체를 의미한다. 이상적으로 이야기하자면, Java 언어 자체 규약에 의한 제한외의 규약에 구속받지 않는 Java 객체가 POJO라고 할 수 있다.
POJO의 제약사항
어떠한 객체가 POJO라고 불리기 위해서는 아래의 제약사항을 지켜야한다.
- 미리 지정된 클래스를 extend 해서는 안된다. 즉, 어떤 클래스의 자식 클래스가 될 수 없다.
- 미리 지정된 인터페이스를 implement 해서는 안된다.
- 미리 정의된 어노테이션을 포함해서는 안된다.
즉, POJO는 그것을 사용하기 위해 외부의 프레임워크, 라이브러리, 별개의 클래스 등이 필요 없고, 객체 단독으로 사용할 수 있는 객체를 의미한다. 따라서 POJO는 특정 규약과 환경에 종속적이지 않은 객체라고 할 수 있다.
그렇다면 위 규약을 모두 지킨 객체는 '진정한 의미의' POJO 라고 할 수 있을까? 토비의 스프링에서는 진정한 POJO에 대하여 아래와 같이 이야기 한다.
진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.
POJO를 사용하면 어떤 점이 좋을까?
- 비즈니스 로직과 특정 환경 종속적인 코드를 분리하기 때문에 코드가 단순해진다.
- 특정 환경에 종속적인 로직이 포함된 객체는 테스트가 어렵지만, POJO는 그렇지 않다. 즉, POJO는 테스트 자동화에 유리하다.
- 객체지향적인 설계를 자유롭게 적용할 수 있다.
POJO vs Java Bean
많은 사람들이 POJO와 Java Bean의 개념을 혼용하여 사용하거나, 혼란을 겪고 있다고 한다. POJO는 그 자체로 사용할 수 있는 객체를 의미하지만, Java Bean 은 여기에 조금 더 많은 제약사항이 추가된다.
- 기본 생성자(no-args constructor)가 존재해야한다.
- 필드의 접근 제어자가 private 이어야하며, 필드는 public getter, setter 로만 접근해야한다.
- 직렬화 가능(Serializable)해야한다. 즉, Serializable 인터페이스를 구현해야한다.