[토비의 스프링3] 8-3. POJO 프로그래밍

'토비의 스프링3' 개발 서적을 읽으며 내용을 정리한 글입니다.

 

8.3 POJO 프로그래밍

스프링의 가장 강력한 특징과 목표를 기술적으로 정의하자면 아래와 같다.

 

분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다.

해석

(1) : 핵심 로직은 아니지만 반드시 필요한 뒷단의 기술을

(2) : POJO 방식으로 개발된 애플리케이션 핵심 로직에 포함시킨다.

핵심 로직과 뒷단의 기술을 분리하였는데 (2)에 포함시켜 제공하고자 하는게 스프링이 기술적으로 지향하는 목적이라고 한다.

 

그렇다면 POJO가 대체 뭘까? POJO에 대해서 알아보자.

 

 

POJO란 무엇일까?

• POJO 정의
  • 간단한 자바 오브젝트.
  • 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트.

 

POJO의 조건

• 특정 규약에 종속되지 않는다. (필수)
  • (예시) 스트럿츠1 의 경우 ActionForm을 상속해야하는 폼 객체는 거의 비슷한 구조를 가진 DTO를 만들어 복사해줘야한다.
    -> 이미 상속을 받아야하는 규약이 있으므로 자바의 단일 상속 제한 대문에 더 이상 객체지향 설계 기법을 적용하기 어려워진다.
    -> 규약이 적용된 환경에 종속적이 되기 때문에 다른 환경으로 이전이 어렵다.
• 특정 환경에 종속되지 않는다. (필수)
  • 특정 기업의 프레임워크 안에서만 동작하거나, 특정 서버, 특정 OS 에서만 사용 가능한 코드를 갖고 있는 등 특정 환경에서만 동작할 수 있는 경우라면 POJO라고 할 수 없다.
• 애노테이션 같은 XML의 설정 정보를 자바코드에 담았다면?
  -> 특정 기술과 환경에 종속적인 정보가 있다면 POJO 성립 X
  -> 단지 코드로 표현하기 적절치 않은 부가정보만 담고 있다면 POJO 성립 O 
  
  
• 객체지향의 원리가 담겨있는 Java 클래스여야 POJO이다.
  
  • 덩치만 크고 객체지향 설계가 안되어있다면? (상속과 다형성으로 처리할 수 있는 것을 if/else로 가득채우거나 메서드 덩어리가 클 경우 등)
    -> POJO 성립 X
• 👉🏻 단순히 JavaSE API만 만 사용하거나 자바 문법만 지켰다고 해서 POJO는 아니다.

 

POJO의 장점

• 코드가 깔끔해진다.
• 자동화된 테스트에 유리하다.
• 객체지향적인 설계를 자유롭게 적용할 수 있다.

 

POJO 프레임워크

• POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크
• 대표적 : 스프링 프레임워크, 하이버네이트