그냥 하는 노트와 메모장

프록시 패턴(Proxy pattern) 본문

GoF design pattern

프록시 패턴(Proxy pattern)

coloredrabbit 2019. 3. 9. 11:59

* 프록시 패턴 (Proxy pattern)

  [정의] - 어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴

  [대표 사례]

    1. 원격 프록시: 원격 객체에 대한 접근을 제어

    2. 가상 프록시: 생성하기 힘든 자원에 대한 접근을 제어

    3. 보호 프록시: 접근 권한이 필요한 자원에 대한 접근을 제어

 

 

 

[ 그림 : UML(출처: https://en.wikipedia.org/wiki/Proxy_pattern) ]

 

 

  핵심은 클라이언트의 요청을 곧바로 전달하지 않고 필요한 과정을 수행한 뒤에 원격 객체에 요청을 넘겨주는 것이다. 필요한 과정에 어떤 로직이 들어가느냐에 따라 XX 프록시라고 이름을 붙혀준다. 다시 말하지만 프록시 객체의 핵심은 요청을 대신하는 것(delegate)이다. 딱 여기까지만, 더 이상의 요구 조건은 없다. 클라이언트의 요청을 프록시가 받아서 어떤 동작을 할 지는 개발자 마음이다.

 

 

[ 그림 : 대리자 (출처: https://www.tlnt.com/the-5-critical-things-that-a-good-manager-never-ever-delegates-3/)]

 

  프록시는 진짜 객체를 대신하는 역할을 맡는다.

  하나의 예로 원격 프록시(Remote proxy)는 원격 객체에 대한 로컬 대변자(local representative) 역할을 한다. 원격 객체는 JVM 힙에 있는 다른 객체를 말한다.

  로컬 대변자는 로컬 대변자의 메소드를 호출하면 원격 객체의 메소드 호출을 전달해주는 역할을 맡고 있다. 따라서 프록시는 원격 객체와 가깝다기 보다는 클라이언트가 사용하는 객체와 가깝다고 볼 수 있다. 일반적인 경우 프록시 객체가 하나 있고 클라이언트와 서버가 통신하기 위해 프록시 객체를 거치는 구조를 사용하는데 거쳐야 하는 객체가 여러 개라면 클라이언트가 접근할 수 있는 가장 마지막 단계의 객체를 프록시라고 한다.

 

 

 

다른 패턴과의 연관성

 

* 프록시와 팩토리 메소드

  클라이언트에게 프록시를 제공해야할 때, 내부 생성 로직을 캡슐화하고 완성된 객체를 반환하는 팩토리 메소드를 사용할 수 있다. 원격 객체와 프록시는 같은 인터페이스를 구현함을 기억하자.

 

 

 

* 프록시와 데코레이터

< 프록시 > < 데코레이터 >

[ 프록시 이미지 (출처: https://medium.com/@mithunsasidharan/understanding-the-proxy-design-pattern-5e63fe38052a) ]

[ 데코레이터 이미지 (출처: https://hackernoon.com/apply-the-decorator-pattern-in-net-using-autofac-957502b771f7) ]

 

 

- 공통점

  현재 객체에 행동을 추가할 수 있다.

  ※ 프록시는 행동을 추가할 수 있으나 이는 부가적인 것일 뿐, 패턴의 "목적"이 아니다. 이런 행동들은 프록시의 변형의 핵심 요소가 된다. 하지만 프록시의 핵심은 아니다.

 

- 차이점

  1. 데코레이터는 객체를 감싼다. 반면 프록시는 원격 객체를 감싸는 것이 아니라 원격 호출(소켓 등)을 한다.

  2. 프록시는 접근 제어를 한다. 반면 데코레이터는 접근 제어가 아니라 반복 호출일 뿐이다.

 

'GoF design pattern' 카테고리의 다른 글

옵저버 패턴(Observer pattern)  (0) 2019.03.09
Comments