POJO(Plain Old Java Object)

쓰는 시점에서 이해하려고 노력하고 있지만 완벽하게 익히기엔 한계가 있기에 일단 막 써내려가며 익혀보기로 하자.

 

POJO(Plain Old Java Object)

특정 기술이나 프레임워크에 종속되지 않는 순수한 자바 객체

Martin Fowler가 EJB의 복잡성을 비판하며 제안한 개념

POJO는 IoC/DI, AOP, PSA 3개로 구성되어있다. 이 3개를 이해하고 활용하면 되지만 매우매우 어렵다.

 

POJO는

- 자바 표준 외의 특별한 인터페이스나 상속이 필요 없다.

- 애너테이션이나 설정파일 없이도 동작한다.

- getter/setter, 기본 생성자 정도만 가진다

 

Spring이 POJO 기반을 선택한 이유

Spring은 POJO를 바탕으로 복잡한 컨테이너 구조를 벗어나 자바의 단순함을 유지하면서 유연한 아키텍쳐를 구현할 수 있는 방법을 제시함.

기존 Java EE 환경에서는 EJB 컴포넌트를 사용하기 위해 반드시 특정 인터페이스를 구현하거나, 컨테이너에 배포되어야만 했음.

이는 개발자에게 기술적 제약을 강제하며 테스트와 재사용성을 크게 제한함.

POJO를 지향함으로 얻게 된 것

 - 컨테이너 종속성 제거 : 객체가 Spring 컨테이너 밖에서도 실행 가능하도록 설계

 - 기능과 구현의 분리 : 기술 스택에 상관없이 비즈니스 로직 자체의 순수성 유지

 - 단위 테스트 용이성 : 외부 의존성을 제거하여 독립적 테스트 환경 구성 가능

 

POJO의 장점

1. 기술 독립성 확보

POJO는 어떤 라이브러리, 프레임워크에도 의존하지 않기 때문에 비즈니스 로직이 특정 기술에 묶이지 않음

기술 스택 교체나 이식성이 용이해진다.

public class MessageForm extends ActionForm { // 1

	String message;
    
    public String getMessage() {
    	return message;
    }
    
    public void setMessage(String message) {
    	this.message = message;
    }
}

public class MessageAction extends Action { // 2
	
    public ActionForward execute(ActionMapping mapping, ActionForm form, 
    HttpServietRequest request, HttpServietResponse response) throws Exception {
    
    	MessageForm messageForm = (MessageForm) form;
        messageForm.setMessage("Hello,world!");
        
        return mapping.findForward("success");
    
    }
    
}

 

2. 코드 순수성 유지

POJO기반 설계는 비즈니스 로직과 프레임워크 기능의 결합을 최소화하여 코드의 명확성과 유지보수성을 향상시킴

서비스 계층에서 트랜잭션 처리가 필요하더라도 @Transactional 애너테이션만 붙이면 되며, 핵심 로직 자체는 POJO로 유지될 수 있음

 

@Service
class MemberService {
	
    private final MemberRepository;
    
    public MemberService(MemberRepository memberRepository) {
    	this.memberRepository = memberRepository;
    }
    
    @Transactional
    public Member findMember(String memberId) {
    	// 어쩌고 저쩌고...
    }

}

 

3. 테스트 용이성

POJO는 객체 자체를 독립적으로 생성하고 실행할 수 있기 때문에 JVM만 있으면 별도의 컨테이너 없이 테스트가 가능함.

이러한 구조는 단위 테스트, 모킹(mocking), 테스트 자동화 도구와의 결합에서 매우 유리함

@Mock private MemberRepository memberRepository;
@InjectMocks private MemberService memberService; // Mocks 주입?

 

스프링의 핵심 철학 중 하나 : 기능은 많되, 개입은 적게

이를 구현하는게 POJO기반 개발이며 개발자로 하여금 기술로부터 자유로워지고 비즈니스 로직에 집중할 수 있게 만든다.

* 비침투성(non-invasiveness) : 비즈니스 로직이나 도메인 모델에 프레임워크에 종속된 클래스나 인터페이스를 억지로 도입하지 않아도 되어야 한다는 것을 의미함