POJO

예전에 Spring이라고 검색하면 가장 많이 보이는 단어들이 있었습니다.

(아주 지극히 개인적인 의견입니다.)

 

바로 DAO, DTO, VO와 POJO라는 단어들입니다.

DAO, DTO, VO는 내용 자체는 간단하니 찾아보시면 될 것 같습니다. (코드 예제도 함께 보시면 좋을 듯합니다.)

 

오늘은 POJO에 대해 알아보겠습니다.

 

 

POJO (Plain Old Java Object)

오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어

(출처: wiki)

 

의미는 크게 와닿지 않네요.. 뭔가 뭉쳐있는 애들을 분리시키고 나누어서(?) 더 좋게 바꿔보겠다 라는 의도로 보입니다.

하지만, POJO의 구성요소에 대해서 보시면 친근하게 느끼실 수 있을 겁니다.

 

POJO 구조도

 

 

일반적으로 Trinity force같은 그림으로 표현을 하시는데, 저는 그냥 제 입맛대로 구성해보았습니다.

 

 

위에서 봤던 위키 정의를 그림의 내용과 함께 조금 더 우리가 와닿게 표현하면 아래와 같습니다.

"IoC/DI, AOP, PSA를 통해 객체지향적인 특징을 살리고 개발을 비지니스 로직에 집중할 수 있도록 의도"

 

이전에 포스팅했던 'SOLID 를 조금 더 잘 따를 수 있도록 개발을 진행하자!' 라는 이야기라고 봐도 무방해 보입니다.

그렇다면 POJO를 구성하는 세가지 요소는 어떤 기능들을 하는지 알아보겠습니다.

 

 

IoC/DI

IoC: 제어의 역전 (Inversion of Control)

DI: 의존성 주입 (Dependency Injection)

 

두 용어는 서로 다른 뜻을 가지고 있지만, 실제로는 거의 동일한 의미로 사용됩니다.

이전에 포스팅했던 Bean에 대한 내용에서 설명드렸으니 자세한 내용은 생략하도록 하겠습니다.

https://exponential-e.tistory.com/39?category=862311

1. Spring Framework, Bean

 

 

원래 제어를 갖고있어야 하는 클래스에게로부터 제어를 뺏어오는 것 -> 제어의 역전이었고,

뺏어온 제어를 사용해야하는 클래스에게 제공해주는 것 -> 의존성 주입 이었습니다.

제어를 갖고있어야하는 클래스와 제어를 제공받는 클래스는 같은 클래스를 의미합니다.

여기서 제어란 클래스에서 직접 만들어 사용해야하는 기능 정도로 보시면 됩니다. 즉, 의존성이죠.

 

'의존성을 왜 밖에 두지?'라고 의문이 생기신다면, 비즈니스 로직에서 분리하기 위함이라 생각하시면 됩니다.

즉, 비즈니스 로직을 구현하는 클래스에서 다른 부가적인 기능들은 굳이 해당 클래스에 선언하지 않고 주입받아 사용한다는 이야기입니다.

-> 각 클래스의 기능이 명확해질 것이고 수정이 필요할 때 필요한 부분만 간단하게 변경할 수 있겠죠.

 

 

AOP

Aspect Oriented Programming

관점 지향 프로그래밍이라고 합니다.

 

흩어진 관점(concern)을 모아서 개발하자!

이런 의미인데, 비슷한 기능들을 모아두고 필요할 때 호출한다는 느낌입니다.

즉, 이 또한 클래스는 각자의 기능에 충실하고 부가적인 관점들은 모아 코딩하는 방법입니다.

AOP에 대한 내용은 꽤나 길어질 것 같아 다음 포스팅에서 집중적으로 다뤄보겠습니다.

 

 

PSA

Portable Service Abstraction

환경의 변화와 관계없이 일관된 방식의 기술로의 접근 환경을 제공하려는 추상화 구조

 

잘 만들어진 인터페이스를 뜻합니다.

Spring에서 제공하는 대부분의 API가 이에 속합니다.

 

어떤 구현체를 사용하고 이를 변경한다 하더라도 이에 대한 인터페이스가 잘 정의되어 있다면 따로 수정이 필요 없겠죠.

사용하는 기술이 바뀌더라도 비즈니스 로직에 영향이 없도록 인터페이스를 만들자는 것이 PSA의 의미라고 보시면됩니다.

예를들어 JDBC에서 Hibernate로 변경하고 싶을 때 전체적인 로직을 건드리지 않아도 의존성 주입만으로 변경이 가능하죠.

 

 

 

이 세가지 요소를 잘 충족시킨다면 객체지향적인 개발이 가능하고, 수정과 변경에 꽤나 유연하게 대처할 수 있겠죠.

위에서 말씀드린 바와 같이 다른 내용들은 대부분 언급을 했고, 다음엔 AOP 관련 내용을 정리해보겠습니다.

 

잘못된 내용이나, 이해가 잘 안되는 부분은 댓글로 알려주시면 늦지않게 답변 드리겠습니다. 감사합니다.