[Spring] POJO 알아보기

POJO(Plain Old Java Object)

POJO는 200년대 초반, 마틴 파울러 등이 만든 용어로, 당시 복잡한 기술 표준에 종속되어 코드가 지저분해지는 것에 반발하여 특정 기술에 얽매이지 않는 단순한 자바 객체로 돌아가자는 취지에서 만들어졌습니다.

특징

POJO라고 불리기 위해서는 크게 두 가지 조건을 충족해야 합니다.

• 특정 라이브러리나 프레임워크를 상속 받지 않음: 예를 들어, 웹 서버 기능을 쓰기 위해 HttpServlet을 상속받아야 하는 클래스는 POJO가 아님
• 특정 인터페이스를 구현하지 않음: 프레임워크가 강제하는 특정 인터페이스를 구현해도 안됨

따라서, 자바 언어 사양 외 다른 기술에 종속되지 않는 순수한 자바 클래스 그 자체를 의미합니다.

// Non-POJO (프레임워크 종속적)
public class UserOrder extends EntityBean { // 특정 기술을 상속받음
    public void ejbCreate() { ... } // 기술 규격에 맞춘 메서드 강제
    public void ejbRemove() { ... }
}

// POJO (순수 자바 객체)
public class UserOrder {
    private String orderId;
    private int price;

    public void calculateTax() { // 순수한 자바 로직
        this.price = (int)(price * 1.1);
    }
}

 

언제 POJO라는 단어를 쓸까?

• 설계 원칙을 말할 때
  • 예시: "우리 비즈니스 로직은 POJO로 유지해야 해"
  • 의미: 특정 기술(spring, JPA 등)에 오염되지 않게, 순수 자바 코드로만 로직을 짜야 나중에 기술 바뀌어도 고치기 쉽다는 의미
• 데이터 객체를 말할 때
  • 예시: "그거 그냥 POJO 객체야"
  • 의미: 별다른 기능 없이 데이터만 담고 있는 클래스(DTO, Entity)
• Spring 장점 설명할 때
  • 예시: "Spring 덕분에 POJO 프로그래밍이 가능해"
  • 의미: 과거에는 기술적인 기능을 쓰기 위해 코드가 지저분했는데, 이제는 클래스에 @Annotation만 붙이면 되어 편해졌다는 뜻

Spring이 개발자가 POJO만 작성할 수 있도록 돕는 무기

• IoC/DI (제어의 역전/의존성 주입): 객체 생성과 조립을 Spring이 대신 해준다. 개발자는 클래스 내부에 특정 프레임워크 코드를 넣지 않고 순수 자바 객체(POJO)만 작성하여 주입만 하면 됨
• AOP (관점 지향 프로그래밍): 로그 남기기, 트랜잭션 처리 등 부가 작업을 Spring이 따로 처리해주어 개발자가 만든 클래스에는 핵심 비즈니스 로직(POJO)만 남음
• PSA (일관된 서비스 추상화): 기술이 바뀌어도 개발자의 코드는 영향 받지 않도록 추상화

어노테이션(@) 붙이는게 왜 POJO일까?

Spring이 개발자가 POJO만 작성할 수 있도록, AOP 등을 통해 지원을 하고 있다. 엄밀히 말하면 POJO는 spring 프레임워크를 완전히 걷어내어도 수정 없이 바로 쓸 수 있어야 할텐데, @Transactional 등의 어노테이션은 spring을 걷어내면 사용할 수 없다.

 

Spring의 POJO란 이론적으로는 순수성이 깨진 것은 맞지만, 실용적 관점에서는 POJO라고 보는 것이다.

• 침투적 vs 비침투적 코드
  • 과거의 기술(EJB 등)과 현대의 Spring 방식의 결정적 차이는 내 로직이 기술에 오염되었는가이다.
  • 침투적 코드: 프레임워크 클래스를 extends하거나 implements한다. 이러면 프레임워크 없이는 클래스가 인스턴스화도 안되고, 메소드 시그니처 자체가 프레임워크에 묶임
  • 비침투적 코드(어노테이션): @Service나 @Autowired는 클래스 위에 붙어있는 주석(Annotation)일 뿐이라 프레임워크 없어도 이 클래스는 독립적인 자바 객체임

어노테이션이 붙어도 POJO인 이유

• 컴파일과 테스트의 독립성
  • 프레임워크 라이브러리가 없으면 @Service 부분에서 컴파일 에러는 날 수 있다. 하지만, 클래스 내부의 핵심 로직(덧셈, 뺄셈 등)은 자바 표준 문법으로 작성되어 있기 떄문에 어노테이션을 지우면 일반 자바 객체로 돌아옴
• 어노테이션은 메타데이터일 뿐임
  • 어노테이션은 그 자체로 로직을 수행하지 않음
  • @Transactional을 붙였다고 해서 그 클래스 안에 데이터베이스 트랜잭션 코드가 삽입되는게 아니라, 클래스는 가만히 있는데 spring이라는 외부 엔진이 "어? 이 클래스 @Transactional 붙었네? 트랜잭션 처리해줘야겠다"라고 판단하는 근거로만 쓰임

더 순수한 POJO로 작성하려면, 어노테이션 대신 XML 설정이나 Java Config 방식을 활용할 수도 있지만, 매번 설정 파일을 만드는게 번거롭기 때문에 약간의 어노테이션은 눈 감아주는 것이 현대의 POJO 관례이다.