POJO

in Reference

게시판 만들기 프로젝트를 진행하며 자세히 알지 못하는 부분에 대한 공부 중 POJO 대한 공부 내용

  1. 프로젝트 관리
  2. POJO
    1. POJO의 조건
      1. 1. 특정 규약에 종속되지 않는다.
      2. 2. 특정 환경에 종속되지 않는다.
      3. 3. 객체 지향적 원리에 충실해야한다.
    2. POJO 기본 구조
    3. 올바른 POJO 프로그래밍
  3. References

프로젝트 관리

프로젝트 관리 문서

POJO

POJO란 Plain Old Java Object의 약자로서, 오래된 방식의 간단한 자바 오브젝트라는 말로 해석할 수 있습니다. 이를 다른 말로 표현하자면, Java EE 등의 무거운 프레임워크 들을 사용하게 되면서 해당 프레임워크에 종속된 “무거운” 객체를 사용함에 대해 이를 반발해서 사용되게 된 용어입니다.

“POJO”라는 용어는 주요 Java 오브젝트 모델, 컨벤션 또는 프레임워크를 따르지 않는 Java 오브젝트를 의미합니다.

POJO의 조건

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

자바언어와 꼭 필요한 API외에는 종속되지 말아야한다. EJB2와 같이 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구한다. 그럴 경우 자바의 단일 상속 제한 때문에 더이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생긴다.

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

  • 다른 환경에서 사용하기 어려움
  • 비즈니스 로직과 기술적인 내용을 담은 웹정보 코드가 섞여 이해하기 어려워짐
  • 웹서버에 올리지 않고 독립적으로 테스트하기 어려워짐

    3. 객체 지향적 원리에 충실해야한다.

    즉, POJO란 객체지향적인 원리에 충실하면서, 특정 환경과 규약에 종속되지 않아 필요에 따라 재사용될 수 있는 방식으로 설계된 오브젝트라 할 수 있다.

    POJO 기본 구조

    public class foo {
 private String bar;
   
 public String getBar() {
  return bar;
 }
   
 public void setBar(String bar) {
  this.bar = bar;
 }
}

EJB 등에서 사용되는 Java Bean이 아닌 Getter와 Setter로 구성된 가장 순수한 형태의 기본 클래스를 POJO라 하며, EJB의 사용과 프로그램의 규모 증가로 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생기게 되고 또한,

특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지며 점점 객체지향성을 잃어갔습니다. 그래서 개발자들은 옛날 순수한 객체지향성이 컸던 시절로 돌아가자는 취지로 POJO를 개발하게 되었습니다.

  • 미리 지정된 클래스를 상속하면 안됩니다.
  • 미리 지정된 인터페이스를 구현하면 안됩니다.
  • 미리 정의된 Annotation을 포함 하면 안됩니다.

올바른 POJO 프로그래밍

앞서 이야기했듯이 POJO를 잘 사용하면 최소한의 코드와 좋은 코드를 만들 수 있습니다. 특히 가장 중요한 내용은 반드시 자동화된 테스트 코드를 개발하는 것입니다. 이를 통해 만들어진 테스트 코드는 지속적인 변화에 유현하게 대응할 수 있습니다.

References