POJO(Plain Old Java Object)

💡 이 포스팅은 스프링 스터디에 맞게 구성된 것이며, 추후 글의 구조와 다루는 범위가 변경될 수 있으니 참고 바란다.

 

POJO(Plain Old Java Object)란?

JLS(Java Language Specification)에 의해 강제된 것 이외의 제한에 의존하지 않는 자바 오브젝트를 부르는 용어이다.

여기서 말하는 '제한에 의존하지 않는' 것이 무엇인지 코드와 함께 알아보자.

 

💡 JLS(Java Language Specification)

자바 프로그래밍 언어를 위한 문법과 정상적인/비정상적인 규칙, 정상적인 프로그램을 실행하기 위한 프로그램 방법들을 보여주는 자바 표준 문서를 말한다. 자바 표준에 대해 더 궁금하시다면 자바 표준 - JLS(Java Language Specification), JSR(Java Specification Request), JEP(Java Enhancement Proposal) 포스팅을 참고 바란다.

 

---

특정 규약에 종속되지 않음

// MessageListener 인터페이스를 직접 구현하므로 POJO가 아님
public class BestStarListener implements MessageListener {

    @Override
    public void onMessage(Message message) {
        if (message instanceof TextMessage) {
            try {
                System.out.println(((TextMessage) message).getText());
            }
            catch (JMSException ex) {
                throw new RuntimeException(ex);
            }
        }
    }

}

// 어노테이션으로 MessageListener 인터페이스와의 결합도를 낮춘 POJO
@Component
public class MyListener {

  @JmsListener(destination = "myDestination")
  public void processOrder(String data) {
    System.out.println(data);
  }
}

위 예제처럼 JMS를 사용하기 위해 MessageListener를 상속받아서는 안된다. 다른 환경에서의 사용 시 호환을 고려해야 하므로 그만큼 까다로워지기 때문이다.

 

특정 환경에 종속되지 않음

public class Foo extends javax.servlet.http.HttpServlet { ... }

예를 들어 웹 환경에 종속되는 HttpServletRequest나 HttpSession와 관련된 API를 직접 이용해서는 안된다.

이 역시 다른 환경에서의 사용 시 호환을 고려해야 하므로 그만큼 까다로워지고, 웹 환경에 종속돼 비즈니스 로직과 기술적인 내용을 담은 코드가 섞여 결합도가 높아지고, 독립적으로 단위 테스트를 하기 어려워진다.

 

단일 책임 원칙(SRP)을 지키는 클래스

책임과 역할이 다른 코드를 하나의 클래스에 넣는 경우 객체지향 원칙에서 그만큼 멀어지기 때문에 진정한 POJO라 할 수 없다.

 

정리하자면 특정 환경과 규약에 종속되지 않아 재사용될 수 있는 방식으로 설계된 오브젝트이며

객체지향적 원칙을 지향하는 것이 POJO라고 말할 수 있다.

---

여러 포스팅에서 POJO를 'Getter와 Setter를 가진 단순한(Plain) 자바 오브젝트' 정도로만 정의하던데,

이는 POJO의 특징 관점에서 봤을 때 의존성이 없고 코드 수정과 테스트에도 용이하므로 조건이 맞아서 POJO가 될 수 있었을 뿐 반드시 Getter와 Setter를 가져야만 한다는 말은 아니다.

 

💡 Getter/Setter 

어떤 오브젝트나 변수를 가져오는 역할의 메서드를 Getter, 설정하는 역할의 메서드를 Setter라고 한다.

 

💡 자바빈(JavaBean)

특정한 관례를 지키려는 자바빈(JavaBean) API 스펙 표준이 지켜진 클래스를 말하는 것이다.

자바빈 스펙 문서의 기본개념 파트와 위키백과를 참고한 결과 아래 4가지 규칙을 지키는 클래스이다.

1. 모든 필드는 private이며, Getter/Setter 메서드를 통해서만 접근이 가능하다.
2. 기본 생성자가 있어야 한다. 즉, 파라미터가 없는 생성자가 존재해야 한다.
3. 직렬화돼있어야 한다. 즉, java.io.Serializable 인터페이스를 구현해야 한다.
4. (필요한 경우) 어떤 한 컴포넌트가 무언가를 한다는 것을 다른 컴포넌트에게 알리는 '이벤트(Event) 처리 메서드'를 갖고 있어야 한다.

아마 위 자바빈 규칙 중 Getter/Setter 메서드 부분만 보고 POJO와의 관계를 잘못 정리해낸 게 아닌가 싶다.

 

이러한 POJO를 중심으로 스프링 프레임워크를 비롯한 여러 객체지향 기반의 프레임워크가 탄생할 수 있었다.

---

POJO를 지향해야 하는 이유 - 객체지향 설계의 장점을 얻기 위해

스프링 프레임워크 이전에는 엔터프라이즈 기술을 직접 의존하는 객체를 설계했다. 그래서 결합도가 높아지고 응집성이 낮아져 유지보수가 어려워졌다. 즉, 객체지향을 추구하는 자바가 객체지향 설계의 장점들을 잃어버리게 된 것이다.

그래서 POJO라는 개념이 등장했다.

 

💡 그럼에도 특정 기술을 사용해야 하는데 이럴땐 어떻게 하는가? - PSA(Portable Service Abstraction)

특정 기술에 종속적이면 POJO가 아니기 때문에 스프링에서는 마련해둔 표준 인터페이스가 있다. 예를 들어 자바 객체와 데이터베이스를 연결짓기 위해 'JPA'라는 표준 인터페이스를 정해두었고, 이와 관련된 여러 프레임워크들은 이 JPA라는 표준 인터페이스 아래 구현되어 실행되는 것이다. 

이렇게 사용하고자 하는 기술과 환경의 변화와 관계없이 일관된 방식의 기술 접근 환경을 제공하는 추상화 구조를 스프링에서는 PSA라고 한다. PSA에 대해서는 별도로 포스팅 후 링크를 걸어둘테니 참고 바란다.

---

출처

POJO(Plain Old Java Object)

en.wikipedia.org/wiki/Plain_old_Java_object

 

JMS(Java Message Service) 예문

docs.spring.io/spring-framework/docs/4.3.25.RELEASE/spring-framework-reference/html/jms.html

 

자바빈(JavaBean) 표준

ko.wikipedia.org/wiki/자바빈즈

download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/