[Design Pattern] 프록시 패턴 (Proxy)

Proxy Pattern

프록시는 다른 대상에 대해서 대체자 또는 Placeholder를 제공할 수 있는 구조적 디자인 패턴입니다.
프록시는 원래 개체에 대한 액세스를 제어하므로 요청이 원래 개체에 전달되기 전 또는 후에 작업을 수행할 수 있습니다.
즉, 프록시(Proxy) 뜻 그대로 대신하여 어떠한 역할을 수행한다는 것으로 이해하면 됩니다.

개체를 참조할 때 직접 참조하지 않고 대리자를 통해서 접근한다면 개체의 메모리에 직접 접근하지 않고 개체를 참조할 수 있을 뿐 아니라 
필요한 시점까지 개체의 생성, 수정, 삭제를 미룰 수 있습니다.
(완벽히 같지는 않지만 비슷한 예로 CDN을 떠올리면 좋을 것 같습니다!)

장점

• OCP(개방/폐쇄 원칙)을 준수합니다.
  • 서비스 또는 클라이언트를 변경하지 않고 새 프록시를 도입하여 문제를 해결할 수 있습니다.
• 서비스 개체가 준비되지 않았거나 사용할 수 없는 경우에도 작동합니다.
• 개체와 동일한 인터페이스를 제공하고 메소드 호출 전/후로 별도의 로직을 수행할 수 있습니다.
  • 보호, 원격, 로깅, 캐싱, 가상 프록시 등...

단점

• 개체를 생성하는 등의 접근을 할 때에는 프록시를 거치기 때문에 성능에 영향을 줄 수 있습니다.
• 많은 개체를 위해 프록시 패턴이 적용되는 경우 코드가 복잡해질 수 있습니다.

구현 방법

1. 기존 서비스 인터페이스가 없는 경우 프록시와 서비스 클래스를 교체할 수 있도록 생성합니다.
   서비스 클래스에서 항상 인터페이스를 추출하거나 프록시를 서비스 클래스의 하위 클래스로 만들어 상속합니다.
2. 프록시 클래스를 생성하고 서비스에 대한 참조를 저장하기 위한 필드도 추가합니다.
   이를 통해 프록시가 서비스의 생명 주기를 생성하고 관리할 수 있게 됩니다. (드물게 클라이언트가 생성자를 통해 주입하기도 합니다.)
3. 인터페이스 또는 상속 받은 클래스의 메소드를 구현합니다. 대부분 전처리 후 서비스 개체에 역할 수행을 위임합니다.
   이후 프록시 또는 서비스 개체를 반환합니다. 단, 서비스 개체의 결과를 임의로 변형시키면 안 됩니다.

프록시(Proxy) vs. 데코레이터(Decorator)

• 목적
  • 프록시 패턴 : 실제 개체의 접근과 흐름 제어
  • 데코레이터 패턴 : 실제 개체의 기능 추가

프록시(Proxy) vs. 릴레이(Relay)

• 동작
  
  • 프록시 서버 : 클라이언트는 프록시 서버를 서비스 개체로, 서비스 개체는 프록시 서버를 클라이언트로 인지하여 통신
  • 릴레이 서버 : 개체 간 중계 역할
  • 즉, 서비스 개체를 프록시만 알고 있느냐 클라이언트도 아느냐의 차이
• 캐싱
  • 프록시 서버 : 기본적으로 캐싱 지원
  • 릴레이 서버 : 실시간 전송이 기본

참조

Stackoverflow

refactoring.guru

IT Wiki