[Spring] POJO (Plain Old Java Object) 란?

POJO, 자바나 스프링 프레임워크를 다뤄보았다면 어디선가 본거같기도 하고 들어본거같기도 한 그런 단어입니다. 오늘은 이 POJO에 대해 알아보겠습니다!

 

POJO는 Plain Old Java Object를 줄여쓴 말로, 제 특기인 직역을 하면 평이하고(아무것도 꾸며지지 않은) 오래된 자바 객체입니다. 일상 생활에서 자주 보이는 플레인(Plain) 요거트에서도 쓰이는 Plain 이죠.

 

POJO 라는 단어의 탄생

POJO는 2000년 9월에 마틴 파울러(Martin Fowler), 레베카 파슨스(Rebecca Parsons), 조쉬 맥킨지(Josh MacKenzie) 가 사용하기 시작한 용어로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 무거운 객체를 만들게 된 것에 반발해서 사용되게 된 용어입니다.

 

프레임워크를 안쓰면 안쓰는거지 왜 굳이 아무것도 안쓴걸 가지고 이름까지 지었을까요? 마틴 파울러는 이렇게 말했습니다.

 We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely. - Martin Fowler

우리는 왜 사람들이 자기네들 시스템에 기본 객체(아마 프레임워크에 종속된 라이브러리를 사용하지 않은?)를 사용하는걸 싫어했는지 궁금했는데, 기본 객체에 대한 폼나는 이름이 없기때문이라는 결론을 내렸어요. 그래서 우리는 그 폼나는 이름을 하나 던져줬고, 아주 성공적이었죠. 

네.. 그렇다고 합니다.

 

당시 상황을 더 잘 이해하려면 EJB 에 대해서 알아야하는데, 이는 새로운 글에서 다루겠습니다. 요약하자면 더 간편하게 쓸 수 있는 프레임워크의 등장에 특정 기술, 프레임워크, 환경에 종속되어 의존하게 된 자바 코드가 사람들 사이에서 많이 쓰이게 되었습니다. 이는 무겁고 가독성이 떨어져 유지보수가 어렵고 확장성이 매우 떨어지는 단점이 있었습니다. 또한 객체지향 언어인 자바가 객체지향의 장점들을 잃어버리게 되는 것이죠.

 

결과적으로 POJO전략 (이름을 폼나게 짓는) 은 굉장히 효과적이었으며, 현재에 이르러서는 POJO 프로그래밍을 압도적으로 하고있고, POJO로 배제하고자 했던 EJB는 레거시 기술이 되었습니다.

 

그럼 어떤 코드가 바로 POJO일까요?

---

POJO의 정의

현대에서 POJO는 주요 Java 오브젝트 모델, 컨벤션 또는 프레임워크를 따르지 않는 Java 오브젝트를 나타냅니다.

 

따라서 POJO는 다음의 사항을 포함하면 안됩니다.

 

1. 미리 지정된 클래스를 extends 하는 것

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

2. 미리 정의된 인터페이스를 implement 하는 것

public class Bar implements javax.ejb.EntityBean { ... }

3. 미리 정의된 Annotation을 포함하는 것

@Entity //javax.persistence.Entity
public class Baz { ... }

그.러.나. 현실적으로 POJO-compliant라고 기술된 많은 소프트웨어 제품이나 프레임워크들(persistence와 같은)은 실제로 미리 정의된 Annotation을 필요로 합니다.

이와 같은 것들의 특징은 Annotation을 추가하기 전에 POJO이고 Annotation을 제거했을 때, POJO 상태로 되돌아간다면 POJO로 간주할 수 있다는 것입니다.

 

아래는 POJO 코드의 간단한 예시입니다

public class MyPojo {    
    private String name;    
    private int age;  
    public String getName() {    	
    	return name;    
    }
    public String getAge() {
    	return age;    
    }    
    public void setName(String name) {
    	this.name = name;
    }    
    public void setAge(int age) {
    	this.age = age;    
    }
}

위와 같이 Java Bean을 사용하지 않고 Getter와 Setter로 구성된 가장 순수한 형태의 기본 Java 객체를 POJO라 합니다.

---

POJO 프레임워크

POJO 를 지향하면서 단순히 EJB 이전으로 돌아간다면 의미가 없기 때문에 POJO의 장점을 활용할 수 있는 POJO 프레임워크가 등장하게 됩니다.

POJO 프레임워크는 POJO를 사용하는 장점과 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주는 프레임워크입니다. 대표적으로 하이버네이트(Hibernate)와 스프링(Spring)이 있습니다

 

하이버네이트(Hibernate)

하이버네이트는 Persistence 기술과 오브젝트-관계형 DB 매핑을 순수한 POJO를 이용해 사용할 수 있게 만드는 POJO기반의 퍼시스턴스 프레임워크입니다. JDBC API를 직접 사용해 개발하는 것 못지않은 성능과 복잡한 퍼시스턴스 로직을 개발 가능하게 해주었기 때문입니다. 그리고 하이버네이트가 사용하는 POJO 엔티티들은 객체지향적인 다양한 설계와 구현이 가능하다는 점입니다.

 
스프링(Spring)

스프링은 Enterprise 서비스들을 POJO 기반으로 만든 비즈니스 오브젝트에서 사용할 수 있게 해줍니다. IoC 컨테이너를 제공해서, 인스턴스들의 라이프 사이클을 관리하고, 특정 인터페이스를 구현하거나 상속할 필요가 없고 라이브러리를 지원하기에 용이하며 객체 또한 가벼운 것이 특징이며, OOP를 더 OOP답게 쓸 수 있게 해주는 AOP 기술을 적용해서 POJO 개발을 더 쉽게 만들어줍니다.

 

오잉 특정 기술에 종속적이면 POJO가 아니라면서요?
스프링(Spring)에서 하이버네이트(Hibernate)를 사용할 수 있는 이유는 바로 스프링에서 정한 표준 인터페이스가 있기 때문입니다. 스프링 개발자들은 ORM이라는 기술을 사용하기 위해서 JPA라는 표준 인터페이스를 정해두었고, 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래에서 구현되어 실행됩니다.

이것이 바로 스프링이 새로운 엔터프라이즈 기술을 도입하면서도 POJO를 유지하는 방법입니다. 이런 방법을 스프링의 PSA (Portable Service Abstraction) 라고 이야기 합니다.

---

진정한 POJO

단순히 POJO 프레임워크를 사용한다고, POJO 인 것은 아닙니다.

POJO 기반의 코드인지를 확인하는 두 가지 기준은 다음과 같습니다.

 

1. 객체지향적으로 설계 되었는가?

• 반복적인 템플릿 코드와 테스트하기 힘든 구조, 확장 및 재활용의 어려움이 남아있다면 EJB의 문제점을 여전히 안고 있는 것입니다.

2. 테스트가 용이한가?

• 잘 만들어진 POJO 어플리케이션은 자동화된 테스트 코드 작성이 편리합니다. 코드 작성이 편리하면 좀 더 꼼꼼하게 만들게 되고, 코드 검증과 품질 향상에 유리해집니다. 또한, 잘 만들어진 테스트 코드베이스가 있다면 리팩토링할 여유가 생겨 POJO 코드를 좀 더 나은 설계구조로 변경할 수 있습니다.

토비의 스프링에서는 진정한 POJO를 아래와 같이 정의했다고 합니다.

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

진정한 POJO.. 멋집니다.

 

출처:
- POJO - (Plain Old Java Object)란 뭘까?
- [Spring] POJO(Plain Old Java Object)란?
- https://www.martinfowler.com/bliki/POJO.html