[구조 패턴] 프록시 패턴(Proxy pattern)

의도 

• 프록시 패턴은 다른 객체에 대한 대체 또는 자리 표시자를 제공할 수 있는 구조 디자인 패턴이다. 
• 프록시 패턴은 어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴이다. 
• 원래 객체에 대한 접근을 제어하므로 당신의 요청이 원래 객체에 전달되기 전 / 후에 무언가를 수행할 수 있도록 한다. 

---

문제 상황

 

• 객체에 대한 접근을 제한하는 이유는 무엇일까?
• 방대한 양의 시스템 자원을 소비하는 거대한 자원이 있다고 가정하자. 
• 이 객체는 필요할 때가 있기는 하지만 항상 필요한 것은 아니다. 
• 필요할 때만 객체를 만들어서 초기화를  구현 가능하다. 
  • 그러면 객체의 모든 클라이언트들은 어떤 지연된 초기화 코드를 실행해야하는데 이는 많은 코드 중복을 초래한다. 
  • 이 코드를 객체의 클래스에 넣을 수 있다면 좋겠지만 그 클래스가 폐쇄된 타사 라이브러리의 일부라면 직접 넣을 수 없다. 

 

---

해결 방법

• 프록시 패턴은 원래 서비스 객체와 같은 인터페이스로 새 프록시 클래스를 생성하도록 한다. 
  • 그러면 프록시 객체를 원래 객체의 모든 클라이언트에게 전달하도록 앱을 업데이트 가능하다. 
• 클라이언트로부터 요청을 받으면 이 프록시는 실제 서비스 객체를 생성하고 모든 작업을 이 객체에 위임한다. 
• 프록시는 데이터베이스 객체로 자신을 변장한다. 
• 프록시는 지연된 초기화, 결괏값 캐싱을 클라이언트와 실제 데이터베이스가 알지 못하는 상태에서 처리 가능하다. 
• 프록시는 원래 클래스와 같은 인터페이스를 구현하므로 실제 서비스 객체를 기대하는 모든 클라이언트에 전달될 수 있다. 

---

실제 상황 적용

• 신용 카드: 은행 계좌의 프록시
• 은행 계좌: 현금의 프록시

---

구조

•  ServiceInterface: 프록시가 객체로 위장할 수 있으려면 인터페이스를 따라야한다. 
• Service: 비즈니스 로직을 제공하는 클래스
• Proxy: 서비스 객체를 가리키는 참조 필드가 있다. 
  • 프록시가 요청한 처리를 완료하고나서 요청을 서비스 객체에 전달한다. 
  • 프록시들은 서비스 객체들의 수명 주기를 관리한다. 
• Client: 같은 인터페이스를 통해 서비스들 및 프록시들과 함께 작동해야한다. 서비스 객체를 기대하는 모든 코드에 프록시를 전달할 수 있기 때문이다. 

---

다른 패턴과의 관계

• 데코레이터 <=> 프록시 객체
  • 공통점: 한 객체가 일부 작업을 다른 객체에 위임해야하는 합성 원칙을 기반으로 만든다. 
  • 차이점
    • 데코레이터의 합성은 항상 클라이언트에 의해 제어된다.
      • 추가 기능을 붙이는 경우 많이 쓴다. 
    • 프록시는 일반적으로 자체적으로 자신의 서비스 객체의 수명 주기를 관리한다.  
      • 캐시, 접근 제어 시 많이 사용한다.
•  cf) AOP는 데코레이터와 프록시 패턴을 기반으로 구현된다.
•  

 

 

 

출처 - 「  」

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