POJO(Plain Old Java Object)

: 오래된 방식의 자바 객체. 자바 언어가 갖는 객체지향적 설계와 개발의 장점을 잃지 않고 특정 기술이나 프레임워크 등 외부 환경에 종속되지 않는 것.

e.g) 특정 Spring 프레임워크를 의존하게 되면 해당 객체는 POJO가 아니게 되는 것.

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

정의

: 어떠한 제한, 환경, 사양에 종속되지 않는 java object. 일반적으로 다음의 세가지를 하지 않고 객체지향적 원칙에 충실한 것이라고 한다.

1. extends를 통해 클래스를 확장한 것
2. implements를 통해 어떠한 인터페이스를 구현한 구현체
3. annotation을 포함하는 것

스프링 프레임워크는 POJO방식의 프레임워크

: 개발자들이 객체를 구성할 때 객체지향에만 집중해 구성한다. IoC와 DI, AOP 등은 Spring에서 모두 해주니 이런식으로 구성 가능하다.

장점

• 이를 통해 코드는 simple해진다. 개발자는 이용하고자 하는 기술의 low level을 깊이 알기보다 비즈니스, 서비스 로직에 집중할 수 있다.
• 특정 환경에 종속되지 않기 때문에 테스트에 용이하다.
• 객체지향적 설계에 집중해서 객체지향적 이점을 가져갈 수 있다.

code level POJO 예시

POJO를 적용한 예

public class User {
  private String userId;
  
  public User() {
    // ..
  }
  
  public String getUserId() {
    return this.userId;
  }
}

POJO를 적용하지 않은 예

@AllArgsConstructor
@Getter
public class User {
  private String userId;
}

트레이드 오프

: 위의 예시처럼 Lombok 라이브러리를 사용해 POJO에 정의해놓았던 boilerplate를 제거하니 POJO는 아니지만 훨씬 간결해졌다. pojo를 지향하는 것은 좋아보이지만 어떤 경우에도 pojo를 사용한다고 생각하기보다 트레이드 오프를 따져가며 선택한다면 상황에 따라 더 좋은 코드를 만들어 낼 수 있을 것 같다.

Reference)

https://ko.wikipedia.org/wiki/Plain_Old_Java_Object

https://happyer16.tistory.com/entry/POJOplain-old-java-object%EB%9E%80

https://siyoon210.tistory.com/120

https://m.blog.naver.com/writer0713/220700687650

https://limmmee.tistory.com/8

http://asuraiv.blogspot.com/2017/07/spring-pojo.html