프록시 패턴
정의
프록시란 '대리'라는 의미로 프록시에게 어떤 일을 대신 시키는것이다.
예를 들어 보안분야에서, 보안상의 이유로 서버를 외부에 노출시키지 않기 위해 서버와 클라이언트단 중간에서 접점을 담당하는 서버를 보고 프록시서버라고 부른다.
인터페이스를 사용하고 실행시킬 클래스에 대해 객체가 들어갈 자리에 대리(Proxy) 객체를 대신 투입하여, 클라이언트는 실제 실행시킬 클래스에 대한 메소드를 호출하여 반환값을 받는지 대리(Proxy) 객체의 메소드를 호출해서 반환값을 받는지 모르게 하는것을 말한다.
구조
클라이언트가 Subject 인터페이스의 request()를 호출하면 구현클래스인 RealSubject의 request()가 호출된다. 이때 프록시가 대신 RealSubject의 request()메서드를 호출하고 그 반환값을 클라이언트에게 전달하는것이다.
프록시 패턴을 사용하는 이유
프록시 패턴을 사용하면 흐름을 제어할수 있다. 그렇다면 흐름제어는 왜 필요한가? 흐름을 제어하가 위한것이 프록시패턴을 이용하는 가장 큰 이유인데 간단히 말하면 동기적인 처리를 최대한 비동기적으로 처리하기 위함이라고 생각한다.
프록시 객체를 사용하지않는 아래 사진과같은 상황을 생각해보자.
(출처 : https://refactoring.guru/design-patterns/proxy)
많은 양의 리소스를 필요로하는 상황에서 디비쿼리가 엄청나게 느려질 수 있다.
이럴때 지연초기화를 위한 코드작성을 해야하는데 이를 모든 클래스마다 직접 넣어버리면 엄청나게 많은 코드중복이 발생할것이다.
따라서 아래사진과같이 프록시객체를 이용하면 요청을 프록시객체가 먼저 받은뒤에 흐름을 제어하여 디비에 쿼리를 날릴 수 있게된다.
장점
- 사이즈가 큰 객체(ex : 이미지)가 로딩되기 전에도 프록시를 통해 참조를 할 수 있다.
- 실제 객체의 public, protected 메소드들을 숨기고 인터페이스를 통해 노출시킬 수 있다.
- 로컬에 있지 않고 떨어져 있는 객체를 사용할 수 있다.
- 원래 객체의 접근에 대해서 사전처리를 할 수 있다.
단점
- 객체를 생성할때 한단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능이 저하될 수 있다.
- 프록시 내부에서 객체 생성을 위해 스레드가 생성, 동기화가 구현되야 하는 경우 성능이 저하될 수 있다.
- 로직이 난해해져 가독성이 떨어질 수 있다.
