Proxy pattern?

모든 글은 유튜브 얄팍한 코딩사전에 출처를 두고있습니다.

이번에는 Proxy 패턴에 대해 학습해보자.

Proxy?

먼저 Proxy 패턴에 대해 간단하게 정의해보자.

가벼운 작업을 대신 수행할 수 있는 대리인

위와 같이 간단하게 정의할 수 있을 것 같다.
가벼운 작업에 대한 요청을 괜히 실제 클래스에게 맡기지 않고
대리인 역할을 할 클래스가 처리하도록 하는 것이다.

대리인 역할을 하는 클래스는 무거운 작업을 처리하지 않고
무거운 요청이 들어오면 실제 클래스에게 위임하게 된다.

사용 이유

예를 들어 유튜브와 같은 영상 스트리밍 사이트를 생각해보자.
기본적으로 사이트에선 영상의 제목과 썸네일을 출력하게 된다.
이 때, 커서를 올리면 영상의 프리뷰를 재생하게 되는데,
이런 동작들을 만약 하나의 클래스에서 모두 담당한다면 어떨까?

무거운 객체를 즉시 생성해야 하기 때문에, 부하가 클 수도 있을 것이다.
그럴 때 Proxy 패턴이 굉장히 도움이 될 수 있다.
우리는 이런 역할을 객체의 Lazy loading(지연 로딩) 이라고 한다.

또한 요청에 대한 보안을 담당할 수 있는 방패 역할도 할 수 있을 것이다.

구현

아래와 같이 영상 프리뷰를 재생하는 클래스가 구현되어 있다.

위 클래스는 실제 동작을 담당하는 클래스이다.
아래는 프록시 객체를 구현한 것이다.

제목을 출력하는 간단한 작업을 프록시에게 위임할 수 있다.
그럼, 굳이 무거운 실제 작업 객체를 생성하지 않아도 처리가 가능하다.
무거운 작업에 대한 요청이 들어올 때, 실제 객체에게 요청을 전달한다.

위와 같은 동작 뿐만 아니라, 전처리나 캐싱 등의 용도로도 많이 사용된다.
캐싱과 같은 과정을 통해 실제 객체의 부하를 줄여주는 것이다.

보호 프록시

이외에도 다양한 방식으로 프록시를 응용할 수 있는데,
그 중 하나의 방식이 바로 보호 프록시(Protection Proxy)이다.

간단하게 예를 들어 회사의 직급 체계를 한 번 생각해보자.
보통 회사에선 직급 별로 열람할 수 있는 인사 정보의 수준이 다르다.
해당 과정에 검증 과정이 빠진다면, 큰 문제가 발생할 수도 있다.

이 때, 기존의 인사 정보 열람 시스템을 굳이 고쳐야 할까?
Proxy 패턴을 사용한다면, 굳이 고치지 않아도 된다.

[코드 구현]

장단점

Proxy 패턴의 장점은 아래와 같다.

• 기존 대상 클래스에 대한 변경 없이 기능 확장이 가능하다.
  • 이는 곧 OCP 원칙을 잘 준수한다는 의미이다.
• 대상 클래스는 본인의 임무에 충실, Proxy 객체가 나머지 기능을 담당한다.
  • 이는 곧 SRP 원칙을 잘 준수하는 것과 동일하다.
• 원래 기능도 실행하되, 부가적으로 기능을 수행하기 매우 유용하다.

아래와 같은 단점들도 존재한다.

• 프록시 객체가 많아지면 많아질수록 코드는 복잡해진다.
• 프록시 객체 자체가 무거워지면 동일하게 서버에 부하가 발생한다.