POJO: Plain Old Java Object

정의

목적 및 특징

• 특정 환경과 기술에 종속되지 않는다.
• 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않다.

• 객체 지향적 원리에 충실한다.
• 단일 책임 원칙(SRP)

• 필요에 따라 재활용될 수 있는 방식으로 설계

예시

1. Java Bean이 대표적이다.
• 쉽게 말해 Java를 이용해서 객체를 구성하는 방식을 그대로 스프링에서 사용할 수 있다는 의미
• DTO
• VO

2. Spring



• 스프링의 주요 기술인 IoC & DI, AOP, PSA는 애플리케이션을 POJO로 개발할 수 있게 해주는 기술들이다.

POJO가 가지면 안되는 것

• 상속하면 안됨

• 인터페이스 구현하면 안됨

• 어노테이션을 포함하면 안됨

장점

1. 특정 환경과 기술에 종속되지 않는다.

2. 특정 환경에 종속되지 않아 테스트 용이

3. 특정 규약에 종속되지 않아 로우레벨 코드와 비즈니스 코드가 분리되어 개발자는 비즈니스 로직에 충실한 개발이 가능함 + 가독성

4. 필요에 따라 재활용 가능

면접 질문

• POJO가 무엇인가요?

• POJO를 사용하는 이유에는 무엇이 있을까요?
POJO를 지키지 않으면, 개발자가 작성하는 코드에 해당 객체의 책임인 비즈니스 로직과 관련없는 Framework 구현 코드가 섞여들어간다. (단일책임원리 X)
또한 특정 기술과 환경에 종속되어 의존하게 되면, 코드 가독성 뿐만아니라 유지보수, 확장성에도 어려움이 생긴다.
이러한 객체지향의 장점을 잃어버린 자바를 되살리기 위해 POJO라는 개념이 등장한 것

• POJO의 특징에 객체 지향 원리_단일 책임 원리에 대해 말씀해주셨는데, 단일 책임 원칙이 무엇일까요?
• 하나의 클래스에 하나의 역할만 가져야한다는 원칙이다.
• 책임 영역이 확실해짐으로써 객체마다 역할이 분배되고, 가독성, 유지보수성이 향상된다.
• 변경이 발생할 때, 파급 효과가 적으면 SRP를 잘 따른 것이라 할 수 있다.

• POJO의 개념을 사용한 프레임워크에는 무엇이 있을까요?
• Spring
• Bean
• 특수 POJO로 POJO보다 조금 유연하게 적용(Annotation)

• POJO 기반의 코드인지 확인하는 중요한 기준
• 객체지향적인 설계원칙에 충실하도록 개발되어 있는가?
• 단일 책임 원칙
• 반복적으로 등장하는 템플릿 코드, 테스트하기 힘든 구조, 확장이나 재활용의 어려움이 있다면 POJO 기반 코드가 아니다.
• 테스트 코드 개발의 용이성
• 잘 만들어진 POJO 애플리케이션은 자동화된 테스트 코드 작성이 편리하다.
• 코드 작성이 편리할수록 더 자주 더 꼼꼼하게 테스트할 수 있어 코드 검증과 품질 향상에 유리해진다.
• 잘만들어진 테스트 코드베이스가 있다면, 리팩토링할 여유가 생겨 POJO 코드를 좀 더 나은 설계 구조로 변경할 가능성도 높아진다.
• "POJO 프로그래밍의 꽃은 테스트 코드 작성"

• POJO가 가지면 안되는 것

• POJO VS Bean
• Bean은 POJO 중 하나
• POJO가 더 큰 범위
• Bean이 더 엄격한 조건
• Bean
• 필드가 private
• Getter나 Setter 가져야 함
• 필드는 생성자, Getter, Setter에 의해서만 접근되어야 함
• 기본 생성자가 필요(No-args)
• 리플렉션이 해당 객체 생성하기 위함

• POJO를 유지하면서 특정 기술을 사용하고 싶다면?(스프링이 POJO를 유지하면서 Hibernate를 사용할 수 있는 이유)
• 스프링에서 정한 표준 인터페이스가 있기 때문
• 스프링 개발자들은 ORM이라는 기술을 사용하기 위해서 'JPA'라는 표준 인터페이스를 정했다.
• 이에따라 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래, 구현되어 실행된다.
• 이것이 스프링이 새로운 엔터프라이즈 기술을 도입 하면서도 POJO를 유지하는 방법임
• 이러한 방법을 스프링의 PSA라고 얘기합니다.

• PSA가 무엇인가요?
추상화 계층을 사용하여 어떤 기술을 내부에 숨기고 개발자에게 편의성을 제공해주는 것
하나의 추상화로 여러 서비스를 묶어둔 것