[Design Pattern] 프록시 패턴(Proxy Pattern)에 대해 알아보자

Definition

프록시 패턴(Proxy Pattern)은 특정 객체로의 접근을 제어하는 대리인(특정 개체를 대변하는 객체)을 제공한다.

프록시는 다른 객체의 '대리인'

 

- 원격 프록시를 써서 원격 객체로의 접근을 제어할 수 있다.

- 가상 프록시(virtual proxy)를 써서 생성하기 힘든 자원으로의 접근을 제어할 수 있다.

- 보호 프록시(protection proxy)를 써서 접근 권한이 필요한 자원으로의 접근을 제어할 수 있다.

Structural Patterns

 

Situation

- 표현되는 객체는 시스템 외부에 있다.

 

- 객체는 요청시 생성되어야 한다.

 

- 원본 객체에 대한 액세스 제어가 필요하다.

 

- 객체에 액세스할 때 추가된 기능이 필요하다.

 

- 지연 초기화(가상 프록시). 이것은 때때로 필요하지만 항상 가동되어 시스템 리소스를 낭비하는 무거운 서비스 객체가 있는 경우이다.

 

- 앱이 시작될 때 객체를 생성하는 대신, 객체 초기화가 정말로 필요한 시점으로 지연될 수 있다.

 

- 액세스 제어(보호 프로시). 특정 클라이언트만 서비스 객체를 사용할 수 있도록 하는 경우. 예를 들어, 객체가 운영 체제의 중요한 부분이고 클라이언트가 다양한 실행 응용프로그램인 경우

 

- 프록시는 클라이언트의 자격 증명이 일부 기준과 일치하는 경우에만 서비스 객체에 요청을 전달할 수 있다.

 

- 원격 서비스의 로컬 실행(원격 프록시). 서비스 객체가 원격 서버에 있는 경우. 이 경우 프록시는 네트워크를 통해 클라이언트 요청을 전달하여 네트워크 작업의 모든 불쾌한 세부 사항을 처리한다.

 

- 로깅 요청(로깅 프록시). 서비스 개체에 대한 요청 기록을 유지하려는 경우. 프록시는 서비스에 전달하기 전에 각 요청을 기록할 수 있다. 

 

- 캐싱 요청 결과(캐싱 프록시). 클라이언트 요청의 결과를 캐시하고 이 캐시의 수명 주기를 관리해야 하는 경우. (데이터가 큰 경우 캐싱 필요)

 

- 프록시는 항상 동일한 결과를 생성하는 반복 요청에 대해 캐싱을 구현할 수 있다. 프록시는 요청의 매개변수를 캐시 키로 사용할 수 있다.

 

- 스마트 참조. 이것은 무거운 객체를 사용하는 클라이언트가 없을 때 해제 할 수 있다. 

 

- 프록시는 서비스 객체 또는 해당 결과에 대한 참조를 얻은 클라이언트를 추적할 수 있다. 때때로 프록시는 클라이언트를 통해 클라이언트가 여전히 활성 상태인지 확인할 수 있다. 클라이언트 목록이 비어있으면 프록시가 서비스 객체를 닫고 기본 시스템 리소스를 해제할 수 있다.

 

- 프록시는 클라이언트 서비스 개체를 수정했는지 여부도 추적할 수 있다. 그런 다음 변경되지 않은 개체는 다른 클라이언트에서 재사용할 수 있다.

 

Structure

https://refactoring.guru/design-patterns/proxy

Pros

- 클라이언트가 알지 못하는 상태에서 서비스 객체를 제어할 수 있다.

- 클라이언트가 신경 쓰지 않을 때 서비스 객체의 수명 주기를 관리할 수 있다.

- 프록시는 서비스 객체가 준비되지 않았거나 사용할 수 없는 경우에도 작동한다. 

- Open/Close Principle. 서비스나 클라이언트를 변경하지 않고 새 프록시를 도입할 수 있다.

 

Cons

- 많은 새 클래스를 도입해야 하므로 코드가 더 복잡해질 수 있다.

- 서비스 응답이 늦어질 수 있다.

- 객체를 생성할 때 한 단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능 저하가 발생할 수 있다.

 

비슷한 패턴

- Adapter는 래핑된 개체에 대해 다른 인터페이스를 제공하고 Proxy는 동일한 인터페이스를 제공하며 Decorator는 향상된 인터페이스를 제공한다.

- Facade는 복잡한 엔티티를 버퍼링하고 자체적으로 초기화한다는 점에서 Proxy와 유사하다. Facade와 달리 Proxy는 서비스 객체와 동일한 인터페이스를 가지고 있어 상호 교환이 가능하다.

- Decorator와 Proxy는 구조는 비슷하지만 의도는 매우 다르다. 두 패턴 모두 한 객체가 일부 작업을 다른 객체에 위임해야 하는 구성 원칙을 기반으로 한다. 차이점은 Proxy는 일반적으로 서비스 개체의 수명 주기를 자체적으로 관리하는 반면 Decorator들의 구성은 항상 클라이언트에 의해 제어된다.