POJO(22.11.05TIL)

오늘 클린코드 북스터디에서 AOP 부분을 읽었다. 로버트 마틴 아저씨는 계속해서 POJO를 사용해야 한다고 울부짖었는데 POJO가 어떤것인지 몰라서 정확한 메시지는 이해하지 못했다. 하지만 전달하려는 메시지는 어떤 것을 설계하던지 간에 가장 간단한 방법으로 구현해야 한다는 것이라고 들렸다. 스프링 주차때 잠깐 POJO를 본 것 같은데 정확히는 모르는 것 같아서 한번 찾아보았다.

 

POJO란

POJO의 풀네임을 한번 살펴보자.  Plain Old Java Object => 오래된 방식의 간단한 자바 오브젝트를 의미한다. 더 정확하게 말하면 자바 언어 사양 이외에 어떠한 제한에도 묶이지 않은 객체라고 할 수 있다.(특정 기술의 상속과 구현을 하지 않은 객체) 근데 간단한 자바 오브젝트인데 왜 이렇게 있어보이는 이름을 붙여서 찬양을 할까?

 

왜 POJO를 써야할까

스프링 프레임워크 이전에는 원하는 엔터프라이즈 기술이 있다면 그 기술을 직접적으로 사용하는 객체를 설계했다. 따라서 특정 기술과 환경에 종속되어 의존하게 되어 무거워진 자바 코드는 가독성이 떨어져서 유지보수에 어려움이 생겼다. 객체지향 언어의 장점을 다시 살리기 위해 POJO라는 개념이 등장했다.

 

POJO가 어떻게 ORM을 사용하는데?

DB와 객체지향을 연결해주는 방법인 ORM을 사용하려면 ORM프레임워크를 사용해야 한다. (ex. hibernate...) ORM을 사용하려면 특정 기술에 종속적이라는 말이 되는데 근데 스프링에서는 어떻게 POJO를 유지하면서 Hibernate를 사용할 수 있을까? 이를 위해 JPA가 등장한다. JPA라는 표준 인터페이스 아래에서 여러 ORM 프레임워크들이 구현되어서 실행된다. JPA덕분에 스프링은 POJO를 유지하면서 새로운 엔터프라이즈 기술을 도입할 수 있다.

 

코딩 구루인 아샬님부터 로버트 마틴까지 한입으로 모아서 하는말이 있다. 결국엔 핵심 로직은 단순한 것으로 짠다는 것이다. 코딩 도장을 풀때도, 과제를 구현할 때도 어떻게하면 최대한 단순한 로직으로 구현할 수 있을지 고민해보자!