Gof 구조 디자인 패턴 : proxy

현재 알게 모르게 나는 많은 Proxy 패턴을 적용한 기술을 사용하고 있다.

JPA, Spring Security, Transactional, DynamicProxy, Reflect API...

이러한 기술 자체는 정말 많은 생산성을 높여준다. 확장도 쉽고 성능도 개선하고 코드의 간결성까지 이러한 proxy패턴에 대해 조금 더 알아보자!

Proxy 패턴의 의도

다른 객체에 대한 접근을 제어하기 위한 대리자 역할을 하는 객체를 배치한다.

이러한 프록시는 원래 객체에 대한 접근을 제어하므로, 요청이 원래 객체에 전달되기 전/후에 무언가를 수행할 수 있게 한다.

Subject의 인터페이스는 프록시가 RealSubject로 위장하기 위해 필요한 인터페이스입니다.

실제 RealSubject는 유용한 비지니스 로직을 제공하는 클래스이죠.

이 Proxy 클래스는 RealSubject를 가리키는 참조 필드가 존재합니다. 프록시가 요청을 처리하기 전 해야 하는 동작들을 완료하면 이후 요청을 RealSubject에게 전달합니다.

Cilent는 같은 인터페이스를 통해 요청을 보냅니다.

사실 어떤 객체에 대한 접근을 제어하는 이유는 객체를 사용할 수 있을 때까지 객체 생성과 초기화에 들어가는 비용 및 시간을 아끼겠다는 의도가 큽니다.

이러한 프록시를 활용하기 위한 방안은 매우 많습니다.

요청 메세지와 인자를 가지고 다른 객체 저장소에 전달할 수도 있고, 프록시의 자기 자신을 반환하여 특정 작업을 하기 전까지 대기했다가 실제 객체를 생성 후 요청할 수도 있고, 권한 체크도 할 수 있습니다.

즉 어떠한 코드의 책임에서 숨겨야 할 부분을 프록시 객체에 숨길 수 있고, 최적화, RealSubject에 대한 접근 제어도 가능합니다.

구현

1. 만약 사용하려는 Subject의 인터페이스가 없는 경우 인터페이스르 생성하여 프록시와 실 객체 간의 상호 교환을 가능하게 해야 합니다. 다만 인터페이스를 사용하는 것이 부담되는 경우 상속을 통한 처리도 가능합니다.

2. 이제 실제 객체에 대한 참조 필드를 가진 프록시 클래스를 만들면 된다. 이러한 프락시는 실 객체에 대한 전체 수명 주기를 생성하고 관리할 수 있습니다.

3. 프록시는 부가 작업을 진행한 후 반드시 요청을 실 객체에게 위임해야 합니다.

4. 클라이언트 입장에서 프록시를 받을지 실제 서비스를 받을지 결정하는 생성 메서드를 고려해도 됩니다.

이러한 프록시 패턴은 클라이언트가 불 필요한 로직을 알지 못하는 상태에서 요청을 보낼 수 있습니다.

또한 프록시를 통해 실 객체의 생명주기를 관리할 수 있고, 지연 로딩을 통해 실제 객체를 생성하지 않고도 작동하도록 할 수 있습니다.

하지만 단점은 실 객체를 사용하기 전 부가 작업을 진행하는 프락시가 있기 때문에 클라이언트 입장에서 응답이 느리다고 할 수 있습니다.