Spring에서 자주 쓰이는 디자인 패턴 3

템플릿 메서드 패턴, 전략 패턴(템플릿 콜백 패턴) 에서는..

사실..

변하지 않는 부분과 변하는 부분으로 나누어서

패턴을 사용하지 않을 때 보다는..

더 적은 코드로 따로 따로 분리 하여 코드 관리가 가능 했지만,

결국..

변하는 코드를 적용하기 위한 모든 클래스에

최소 최초에는 원본 코드를 건드려야한다.

-> 개발자의 부담으로 다가온다...

 

원본 코드도 건드리지 않고 변하는 부분에 해당하는 코드를 적용하도록 해보자..

 

이를 위해 프록시 개념에 대해 알아보자..

 

위 그림에서는 Client가 Server를 직접 호출 하고 있다.

 

반면, 위 그림에서는 중간에 Proxy라는게 있어서 Client는 Server를 간접 호출하고 있는 상황이다.

 

이때, 간접 호출할 수 있도록 도와주는 대리자 계층을 프록시라고 부른다.

 

 

프록시의 기능

간접 호출하기 때문에 프록시 자체적으로 중간에서 여러 일을 할 수 있다.

1. 접근 제어, 캐싱

-> 프록시가 중간에서 서버로의 접근을 제어 할 수 있다.

ex. 프록시가 서버의 데이터를 "캐싱"하여

시간이 오래 걸리는 서버로의 요청을 막고 빠르게 자체 전달(접근제어)

ex. 권한에 따라 프록시에서 서버로의 접근을 차단

 

2. 부가기능 추가

-> 프록시가 서버를 호출하기 전에 서버가 하지 않는 어떠한 기능을 추가적으로 수행할 수 있다.

ex. 로그 기능 수행

 

3. 프록시 체인

-> 프록시가 또다른 프록시를 호출 할 수 있다.

ex. 프록시 1에서는 로그 기능을 수행하고, 프록시 2에서는 또다른 기능을 제공

 

 

프록시의 가장 중요한 특징은

클라이언트가 프록시를 호출 할 때, 서버를 호출한것인지.. 프록시를 호출 한 것인지를 몰라야 한다.

 

따라서... 위와 같은 구조가 되어야한다.

프록시와 서버는 동일한 인터페이스(ServerInterface)를 구현한 상황이다.

클라이언트는 서버 인터페이스에만 의존하여..

DI를 통해 클라이언트 모르게 프록시 또는 서버로 각각 대체 할 수 있다.

-> 객체 의존관계를 변경하여도 클라이언트 코드를 변경하지 않아도 된다.

(클라이언트 입장에서는 뭐가 주입되어있는 상태인지 모르게 되는 것이다.)

 

프록시에서는 당연히 실제 서버의 객체를 가지고 이를 호출 해준다.

 

 

GOF 디자인 패턴에서 프록시 패턴과 데코레이터 패턴...

둘다 프록시 개념을 사용한다는 점에서 동일하다.

GOF에서는 이 두가지의 패턴을 의도(intent)에 따라 구분한다.

 

프록시 패턴 : 접근 제어가 목적

데코레이터 패턴 : 새로운 기능 추가가 목적

 

-> 다음 포스팅에서는 프록시 패턴에 대해 알아보고

그다음엔 데코레이터 패턴에 대해 알아보자..