POJO

위의 그림은 Spring 삼각형 이라는 것으로 POJO라는 것은 Spring에서 사용하는 핵심 개념들인 IoC/DI, AOP, PSA를 통해 달성할 수 있다.

 

POJO를 직역하면 순수한 자바 객체가 되는데 POJO프로그래밍이란 다른 기술이나 규약 혹은 특정 환경에 종속적이지 않고 순수 자바 객체만을 사용하는 프로그래밍이다.

 

즉, 특정한 다른 기술들을 변경하더라도 비지니스 로직에 영향을 주지 않도록 서로의 역할을 독립적으로 코드를 작성하는 프로그래밍이다. 예를 들면 MariaDB에서 MySQL로 데이터베이스가 바뀌더라도 비지니스 로직을 수정할 일이 없어야한다.

 

이와 같이 최대한 다른 환경이나 기술에 종속적이지 않도록 하기 위한 POJO 프로그래밍 코드를 작성하기 위해 Spring에서 지원하고 있는 3가지 기술이  IoC/DI, AOP, PSA이다.

 

IoC(Inversion of Control)

Framwork란 전체적인 애플리케이션의 기본이 되는 뼈대를 제공하는데 이러한 뼈대를 제공 받게 되면 애플리케이션의 흐름의 주도권이 개발자가 아닌 Framwork가 가지게 된다. 즉, Framwork를 사용하려면 해당 Framwork의 규약을 따라야 하게 되는 것이다. 이처럼 애플리케이션 흐름의 주도권이 뒤바뀐 것을 IoC(Inversion of Control)라고 한다.

 

예를 들어 자바를 이용한 일반적인 코드는 main() 메서드를 통해 프로세스가 진행이 된후 마지막에는 프로세스가 종료하게 된다.

하지만 웹 애플리케이션의 경우 위와 같이 main() 메서드의 모든 프로세스가 종료하게 되면 웹 서비스 또한 중단되게 되므로 이를 방지하기 위해 서블릿 기반의 애플리케이션을 만들 경우 서블릿 컨테이너 내의 컨테이너 로직이 서블릿을 직접 실행시켜 주기 때문에 main() 메서드가 필요 없다.

이와 같이 서블릿 컨테이너가 서블릿을 제어하고 있기 때문에 애플리케이션의 주도권은 서블릿 컨테이너에 있으며 이런 경우가 바로 서블릿과 웹 애플리케이션 간에 IoC(제어의 역전)의 개념이 적용된 것이다.

 

Spring에서는 이 IoC의 개념을 DI를 이용해서 적용한다.

 

Spring의 IoC 컨테이너에서 DI를 이용하여 Bean(IoC컨테이너가 관리하는 자바 객체)들을 생성 및 관리하게 함으로써 제어권을 Spring에게 넘겨 주며 각 프로세스간의 역할을 분명하게 만들어 객체간의 결합도를 낮추고 유지 및 보수를 더 용이하게 해준다.

 

(DI 이전 포스트 : https://mason-lee.tistory.com/56 )

(참고 자료 : https://velog.io/@gillog/Spring-DIDependency-Injection )

 

 

AOP(Aspect Oriented Programming)

관점 지향 프로그래밍 (AOP)은 애플리케이션을 이루고 있는 여러 핵심기능(core concern)들 중에서 공통적으로 적용되는 공통기능(cross-cutting concern, 횡단 관심사)들을 분리하여 코드를 작성하는 방식이다. 

 

위의 그림을 보면 커피 메뉴 등록, 커피 주문, 커피 주문 변경과 같이 핵심기능들에게 필요한 로깅, 보안, 트랜잭션과 같은 공통기능들을 따로 분리하여 공통 관심 사항의 기능들이 애플리케이션의 핵심 로직에 전반적으로 코드를 두루 사용하는 것을 AOP라고 한다.

 

AOP를 사용함으로써 중복된 코드를 줄여 코드의 간결성을 증가시키고 객체들을 독립적으로 관리하게 되어 애플리케이션의 유지, 보수를 더욱 편리하게 해준다.

 

(참고 자료 : https://ko.wikipedia.org/wiki/%EA%B4%80%EC%A0%90_%EC%A7%80%ED%96%A5_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D )

 

 

PSA(Portable Service Abstraction)

PSA는 추상화를 이용하여 환경의 변화나 세부기술의 변경에 관계없이 일관된 방식으로 해당 기술에 접근하게 설계하는 것이며 Spring에서는 PSA가 적용된 모듈들을 제공한다.

 

인터페이스와 추상화를 이용한다면 의존성을 갖는 다른 클래스들은 해당 인테페이스를 통해 일관된 방식으로 접근이 가능하며 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구사항을 반영할수 있다.

 

예를들어 Spring에서 제공하는 JDBC 모듈을 사용하면 어떠한 RDBMS를 사용하더라도 비지니스 로직은 변경되지 않는다.

위의 그림과 같이 JDBC 인터페이스라는 규격에 맞게 다른 RDBMS를 연결하게되면 같은 비지니스 로직을 사용하더라도 애플리케이션이 정상 작동된다.

 

 

마무리

POJO를 사용하는 이유는 객체지향프로그래밍을 사용하는 이유와 굉장히 비슷하다.

 

클래스들간의 의존성과 결합도를 낮추고 독립성을 높여 애플리케이션의 유지, 보수를 더욱 편리하기 위함이며 이러한 이유로 객체 지향 프로그래밍부터 지금까지 계속해서 독립성을 강조하는 것이 느껴 졌다. 

 

앞으로 애플리케이션 프로그래밍 코드를 작성할 때 항상 내가 작성한 코드가 객체지향스러운가에 대한 고민을 하는 습관을 가져야 겠다.