POJO(Plain Old Java Object)

Spring Framework

POJO(Plain Old Java Object)

mozzi329 2022. 8. 10. 13:51

728x90

📌 POJO(Plain Old Java Object)

POJO(Plain Old Java Object)란 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로써, 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트를 말한다.

POJO는 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다.

마틴 파울러는 POJO에 대해 다음과 같이 그 기원을 밝히고 있다.

"우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고."

-마틴 파울러

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. ~~(순수 혈통 자바 객체)~~ 스프링 프레임워크는 POJO 방식의 프레임워크이다.

📌 POJO 프로그래밍

앞서 POJO는 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않는 간단한 자바 오브젝트라고 정의하였다. POJO 프로그래밍은 이러한 POJO를 지향하는 관점의 프로그래밍이다.

✔️ POJO 프로그래밍에서 준수해야할 규칙 1

Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.

아래의 코드는 특정 기술에 종속적인 예를 보여주기 위한 코드이다.

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,
		HttpServletRequest request, HttpServletResponse response)
        throws Exception {
		
		MessageForm messageForm = (MessageForm) form;
		messageForm .setMessage("Hello World");
		
		return mapping.findForward("success");
	}
	
}

ActionForm 클래스는 과거에 Struts라는 웹 프레임워크에서 지원하는 클래스이다.

(1)에서는 Struts라는 기술을 사용하기 위해서 ActionForm을 상속하고 있다.

(2)에서는 역시 Struts 기술의 Action 클래스를 상속 받고 있다.

이렇게 특정 기술을 상속해서 코드를 작성하게 되면 나중에 애플리케이션의 요구사항이 변경되서 다른 기술로 변경하려할 때 Struts 기술의 클래스를 명시적으로 사용했던 부분을 전부 다 일일이 제거하거나 수정해야하는 문제가 발생한다.

그리고, Java는 다중 상속을 지원하지 않기 때문에 'extends' 키워드를 사용해서 한 번 상속을 하게 된다면 상위 클래스를 상속받아서 하위 클래스를 확장하는 객체지향 설계 기법을 적용하기가 어려워진다. 추후에 언급하겠지만 이러한 상속은 별도의 인터페이스를 만들어 해당 인터페이스를 상속함으로써 문제를 개선할 수 있다.

✔️ POJO 프로그래밍에서 준수해야할 규칙 2

특정 환경에 종속적이지 않아야 한다.

어떤 경우는 특정 벤더의 서버나 특정 기업의 프레임워크 안에서만 동작 가능한 코드로 작성되기도 한다. 또 환경에 종속적인 클래스나 API를 직접 쓴 경우도 있다. 순수한 애플리케이션 로직을 담고 있는 오브젝트 코드가 특정 환경에 종속되게 만드는 경우라면 그것 역시 POJO라고 할 수 없다. POJO는 환경에 독립적이어야한다.

특히 비즈니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경정보나 웹 기술을 담고 있는 클래스나 인터페이스를 사용해서는 안된다. 비즈니스 로직을 담은 코드에 HttpServletRequest나 HttpSession, 캐시와 관련된 API가 등장하거나 웹 프레임워크의 클래스를 직접 이용하는 부분이 있다면 그것은 진정한 POJO라고 볼 수 없다.

📌 POJO 프로그래밍이 필요한 이유

특정 환경이나 기술에 종속적이지 않으면 재사용이 가능하고, 확장 가능한 유연한 코드를 작성할 수 있다.
저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거함으로써 코드가 깔끔해진다.
코드가 깔끔해지기 때문에 디버깅하기도 상대적으로 쉽다.
특정 기술이나 환경에 종속적이지 않기 때문에 테스트 역시 단순해진다.
객체지향적인 설계를 제한없이 적용할 수 있다. (가장 중요)

📌 POJO와 Spring의 관계

스프링에서는 POJO 프로그래밍을 지향하기 위해 IoC/DI, AOP, PSA 기술을 지원한다.

📌 참고사항(객체 지향 설계 원칙)

SOLID(객체 지향 설계 원칙): https://ko.wikipedia.org/wiki/SOLID (객체지향_설계)
SOLID 요약: https://itvillage.tistory.com/entry/객체지향-설계-원칙-SOLID-원칙