본문 바로가기

Design Pattern

[Design pattern] Proxy

Proxy 

디자인 패턴은 컴포넌트의 클라이언트로 하여금 컴포넌트 자체가 아니라 컴포넌트의 대리자와 통신하도록 해준다. 이런 위치 보유자는 효율을 향상시키고, 쉽게 엑스스 할 수 있게 해주며 권한을 부여받지 못한 액세스를 방지하는 등의 역활을 할 수 있다.


문제

컴포넌트에 액세스하는 작업은 런타임에 효과적이고 비용이 덜 들며 클라이언트와 컴포넌트 모두에 대해 안전해야 한다.

컴포넌트에 액세스하는 작업은 클라이언트의 입장에서 투명하고 간단해야 한다. 이 컴포넌트를 호출할 때 사용하는 동작이나 구문이, 직접 액세스할 수 있는 다른 컴포넌트를 호출할 때 사용하는 동작이나 구문과 특별히 다르거나 많이 변경해서는 안 된다. 

클라이언트는 원격 클라이언트에 액세스할 경우 일어날 수 있는 성능상 하락이나 비용상 손해에 대해서도 염두에 두어야 한다. 완전한 투명성을 얻는 대신에 서비스 간의 비용 때문에 그 이점을 퇴색시킬 우려가 있다. 


해법

클라이언트로 하여금 컴포넌트 자체가 아니라 컴포넌트의 대리자와 통신.

프록시라고 하는 이 대리자는 컴포넌트에 대한 인터페이스를 제공


구조


동작


구현

컴포넌트에서 액세스 제어로 처리해야 할 모든 책임을 파악해낸다.

가능하다면 프록시와 원본에 대한 인터페이스들의 공통 부분을 정의하는 추상 기본 클래스를 도입한다.

프록시의 함수를 구현한다.

프록시로 옮겨진 책임들을 원본과 클라이언트에서 제거한다.

원본에 대한 핸들을 프록시에 부여함으로써 프록시와 원본을 연결한다.

원본과 클라이언트 간의 모든 직접적인 관계를 제거한다.



장점

효율을 향상시키고 비용을 감소시킨다.

서버 컴포넌트의 위치로부터 클라이언트를 분리한다.

기능으로부터 하우스키핑 코드를 분리한다.


단점

우회 방식을 채택함으로 인해 효율이 저하된다.

지나치게 정교한 전략을 사용함으로써 과부하를 가져온다.

'Design Pattern' 카테고리의 다른 글

[Design pattern] MVC  (0) 2013.02.21
[Design pattern] Command Processor  (0) 2013.02.21
[Design pattern] Master-Slave  (0) 2013.02.21
[Design pattern] Whole-Part  (0) 2013.02.21
[Design pattern] 팩토리 매서드 패턴  (0) 2013.02.20