POJO
POJO
Plain Old Java Object 의 줄인 말으로, 특별한 제한에 종속되지 않고, 클래스 패스를 필요로 하지 않는 일반적인 Java Object 를 의미한다.
간단히 말하면, 주요 Java 오브젝트 모델, 컨벤션 또는 프레임워크를 따르지 않는 Java 오브젝트 이다.
특정 환경과 라이브러리와의 결합도가 낮다!
POJO 의 특징
하나의 오브젝트 안에 상태(State)와 행위(Behavior)를 모두 가지고 있다.
즉 인스턴스 변수
와 로직을 가진 메소드
를 가지고 있는 것이다.
그렇게 만들기 위한 가장 간단한 방법은 오브젝트가 가지고 있어야할 행위를 오브젝트로 옮겨주는 것이다.
풍성한 도메인 모델(Rich Domain Model) : 객체지향 원리에 충실하게 도메인 모델을 만드는 것
POJO 의 조건
특정 규약에 종속되지 않아야 한다.
그렇지 않으면
단일 상속 제한 때문에 객체 지향적인 설계 기법을 적용하기 어렵고, 다른 환경으로의 이전이 어려워진다.특정 환경에 종속되지 않아야 한다.
그렇지 않으면
- 다른 환경에서 사용하기 어렵다.
- 비즈니스 로직과 기술적인 내용을 담은 웹 정보 코드가 섞여 이해하기 어려워진다.
ex) 웹 환경에 종속되는 HttpServletRequest나 HttpSession과 관련된 API 직접 이용하면 웹 서버에 올리지 않고 독립적으로 테스트하기 어려워진다.
- 단일 책임 원칙을 지키는 클래스여야 한다.
책임과 역할이 각기 다른 코드는 서로 다른 클래스로 나눠야한다.
즉, POJO란 객체 지향적인 원리에 충실하면서, 특정 환경과 규약에 종속되지 않아 필요에 따라 재사용될 수 있는 방식으로 설계된 오브젝트이다.
POJO 의 장점
위의 조건들이 곧 장점이 된다.
특정 규약에 종속되지 않아 객체지향 설계를 할 수 있다.
특정 환경에 종속되지 않아 테스트하기 좋다.
특정 규약에 종속되지 않아 로우레벨 코드와 비즈니스 코드가 분리되어 깔끔한 코드 작성이 가능하다.
POJO의 진정한 가치는 자바의 객체지향적인 특징을 살려 비즈니스 로직에 충실한 개발이 가능하도록 하는 것
POJO를 잘 사용하면 군더더기 없는 최소한의 코드로 이전과 동일한 결과를 낼 수 있고, 그 이상으로 더 좋은 코드를 만들 수 있다.
그러한 코드를 만들기 위해서는 자동화된 테스트 코드를 개발해야 한다. 그리고 잘 만들어진 테스트 코드는 지속적인 변화에 유연하게 대응할 수 있도록 도와준다.
POJO 기반의 코드인지 아닌지 확인하는 중요한 기준
객체지향적인 설계원칙에 충실하도록 개발되어 있는가?
POJO의 자바 오브젝트라는 것은 단순히 자바 언어 문법을 지켜 만든 것이 아니라, 객체지향언어로서의 자바 오브젝트의 특징을 가지고 있는지가 중요
반복적으로 등장하는 템플릿 코드, 테스트하기 힘든 구조, 확장이나 재활용의 어려움이 있다면 POJO 기반 코드가 아니다.
테스트 코드 개발의 용이성
잘 만들어진 POJO 애플리케이션은 자동화된 테스트 코드 작성이 편리하다.
코드 작성이 편리할수록 더 자주 더 꼼꼼하게 테스트할 수 있어 코드 검증과 품질 향상에 유리해진다.
잘만들어진 테스트 코드베이스가 있다면, 리팩토링할 여유가 생겨 POJO 코드를 좀 더 나은 설계 구조로 변경할 가능성도 높아진다.
토비님께서 직접 하신 말에 따르면, "POJO 프로그래밍의 꽃은 테스트 코드 작성"
스프링과 POJO
스프링 애플리케이션 = POJO를 이용해서 만든 애플리케이션 로직
+ POJO가 어떻게 관계를 맺고 동작하는지 정의해놓은 설계 정보
스프링의 주요 기술인 IoC & DI, AOP, PSA 는 애플리케이션을 POJO 로 개발할 수 있게 해주는 기술들이다.