[JAVA] POJO (Plain Old Java Object)

 

이글의 목차

 

What Is a POJO?

이상적인 POJO

POJO를 지향하게 되다. Feat. EJB(Enterprise JavaBeans)

POJO 프레임워크

POJO 기반의 코드인지 아닌지 확인하는 두 가지 기준

진정한 POJO란 

 

 

 

Baeldung의 What is a POJO Class? 를 번역해서 정리한 글입니다.

(구글링한 내용을 추가로, 이해하기 쉬운 순서로 편집했습니다. 항상 단어가 어렵네요~)

https://www.baeldung.com/java-pojo-class#what-is-a-pojo

 

 

 

 

1. What Is a POJO?

"a *straightforward type / with no references to any particular frameworks. A POJO has no naming convention for our properties and methods."

straightforward : 간단한, 수월한

특정 기술이나 프레임워크에 종속되지 않는 간단한 유형이다.  POJO에는 속성 및 메서드에 대한 명명 규칙이 없다. 

말그대로 해석하면  오래된 방식의 간단한 자바 오브젝트.

 

---

이 용어는 2000년 9월 마틴 파울러, 레베카 파슨스, 조시 맥켄지에 의해 만들어졌습니다.

"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."

우리는 왜 사람들이 자기들 시스템에 일반적인 오브젝트를 사용하는 것에 반대하는지 궁금했고, 그 이유는 단순한 오브젝트에 멋진 이름이 없기 때문이라고 결론을 지었습니다. 그래서 우리는 멋진 이름을 지었고, 매우 인기를 얻었습니다.

---

 

"This class can be used by any Java program as it's *not tied to any framework."

 

*not tied to : ~에 얽매이지 않는

이 클래스는 어떤 프레임워크에도 얽매이지 않으므로 모든 Java 프로그램에서 사용할 수 있다.

public class EmployeePojo {

// JAVA 문법으로만 작성된 클래스 예제
    public String firstName;
    public String lastName;
    private LocalDate startDate;

    public EmployeePojo(String firstName, String lastName, LocalDate startDate) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.startDate = startDate;
    }

    public String name() {
        return this.firstName + " " + this.lastName;
    }

    public LocalDate getStart() {
        return this.startDate;
    }
}

 

* convention 관습

* lack 부족, 결핍

"But, we aren't following any real *convention for constructing, accessing, or modifying the class's state."

그러나 우리는 클래스의 상태를 구성, 액세스 또는 수정하기 위한 어떤 실제 관례도 따르고 있지 않다.

This *lack of convention causes two problems:

이러한 관습의 부족은2가지 문제점을 야기하는데,

 

First, it increases the learning curve for coders trying to understand how to use it.

Second, it may limit a framework's ability to favor convention over configuration, understand how to use the class, and augment its functionality."

첫째, 그것을 사용하는 방법을 이해하려고 노력하는 프로그래머들의 학습 곡선을 증가시킨다.

=> 즉, 프로그래머가 코드를 이해하는데 시간이 더 든다.(글쓴이의 첨언)

 

둘째, class를 어떻게 사용할지 이해하고, 기능을 강화하며, 구성보다 관례를 선호하는 프레임워크의 기능을 제한할 수 있다.

= > 정해진 컨벤션이 없기에 어떻게 보면 프레임워크의 기능을 제한한다.(글쓴이의 첨언)

 

 

 

 

 

2. 이상적인 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을 포함하는 것.

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

 

그러나 기술적 어려움과 다른 이유로 인해, POJO-compliant라고 기술된 많은 소프트웨어 제품이나 프레임워크들(persistence와 같은)은 실제로 미리 정의된 Annotation을 제대로 동작하는 기능을 구현하기 위해 필요로 합니다.

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

 

 

 

 

 

 

3. POJO를 지향하게 되다. feat. EJB(Enterprise JavaBeans)

EJB(Enterprise JavaBeans)란 자바 개발에 있어 로우개발에 신경을 안 쓰고 어플리케이션을 쉽게 만들어 준 기술이다.
하지만, EJB는 객체지향성을 감소시키는 단점이 있었다.

EJB의 사용과 프로그램의 규모 증가로 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생기게 되고 또한, 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지며 점점 객체지향성을 잃어갔습니다.

 

그래서 개발자들은 옛날 순수한 객체지향성이 컸던 시절로 돌아가자는 취지로 POJO를 개발하게 되었습니다.

 

 

 

 

 

4. POJO 프레임워크

단순히 EJB 이전으로 돌아간다면 의미가 없기 때문에 POJO 프레임워크가 등장하게 됩니다. POJO 프레임워크는 POJO를 사용하는 장점과 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주는 프레임워크입니다. 많은 POJO 프레임워크가 있지만 그 중에서 꼽히는 것은 하이버네이트와 SPRING입니다.

스프링은 POJO를 이용한 엔터프라이즈 애플리케이션 개발을 목적으로 하는 프레임워크라 한다.

스프링 애플리케이션 = POJO를 이용해서 만든 애플리케이션 로직 + POJO가 어떻게 관계를 맺고 동작하는지 정의해놓은 설계정보

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

 

 

 

 

 

5. POJO 기반의 코드인지 아닌지 확인하는 두 가지 기준

1.객체지향적인 설계원칙에 충실하도록 개발되어 있는가?

POJO의 자바 오브젝트라는 것은 단순히 자바 언어 문법을 지켜 만든 것이 아니라, 객체지향언어로서의 자바 오브젝트의 특징을 가지고 있는지가 중요합니다. 끊임없이 반복적으로 등장하는 템플릿 코드와 테스트하기 힘든 구조, 확장이나 재활용의 어려움이 그대로 남아있다면 EJB의 문제점을 여전히 안고있는 것이죠.

2. 테스트 코드 개발의 용이성이나 테스트 코드를 잘 작성했는지의 여부

수정-빌드-배포-테스트의 사이클을 벗어나지 못하고 있다면, EJB로 개발했던 시절과 대체 무엇이 다른지 생각해봐야합니다. 잘 만들어진 POJO 애플리케이션은 자동화된 테스트 코드 작성이 편리합니다. 코드 작성이 편리하면 좀 더 자주 꼼꼼하게 만들게 되고, 반복적으로 실행할 수 있으므로 코드 검증과 품질 향상에 유리해집니다. 또한, 잘 만들어진 테스트 코드베이스가 있다면, 리팩토링할 여유가 생겨 POJO 코드를 좀 더 나은 설계구조로 변경할 가능성도 높아지게 됩니다.

 

 

 

 

 

6. 진정한 POJO란

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

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가?
많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. . .(중략). .
진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고
필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

 

 

 

도움이 된 사이트

https://dev-coco.tistory.com/82

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

https://velog.io/@dion/what-is-POJO