프록시 - 프록시 패턴과 데코레이션 패턴이란?

이전의 디자인 패턴들은 로그 추적기를 이용할 때 원본 코드를 어쩔 수 없이 조금이라도 수정했었다. 코드가 많아지면 원본 코드를 수정하기 복잡하기에 원본 코드를 전혀 수정하지 않고 로그 추적기를 도입하려 한다.

 

프록시(Proxy)라는 개념을 이해하면 이 문제를 해결할 수 있다.

 

 

클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는게 보통이다.

클라이언트가 프록시를 간접 호출 (사진 : 인프런 스프링 강의)

위의 사진처럼 클라이언트가 서버에 직접 요청하는 것이 아니라, Proxy에 간접 호출을 하는 것이다.

클라이언트 -> Proxy를 참조, Proxy -> Server를 참조

 

프록시 체인으로 여러 프록시를 호출 가능 (사진 : 인프런 스프링 강의)

 

대체 가능 (프록시는 실제 서버처럼 동작할 수 있어야 함)

객체에서 프록시가 되기 위해서는 클라이언트가 요청을 할 때, 서버에 하는 것인지 프록시에 요청하는 것인지 몰라야 한다.

쉽게 말하자면 서버와 프록시는 같은 인터페이스를 사용해야 한다. 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작해야 한다.

 

사진 : 인프런 스프링 강의

서버와 프록시가 같은 인터페이스를 사용한다면 클라이언트는 ServerInterface의 구현체가 바뀌어도 상관하지 않는다.

Client -> Server에서 Client -> Proxy로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 되며 클라이언트 입장에서는 변경 사실조차 모르는 것이다.

 

 

 

 

프록시를 도입할 시 장점

1. 접근 제어

• 권한에 따른 접근 차단
• 캐싱 (프록시에 데이터가 있으면 굳이 서버까지 접근하지 않음)
• 지연 로딩 (프록시를 가져다 쓰다가 실제 요청이 있을 때 데이터에 접근함)

2. 부가 기능 추가

• 로그 등 부가 기능을 넣을 수 있음
• 요청 값이나 응답 값을 중간에 변형

 

 

GOF 디자인 패턴

둘 다 프록시를 사용하는 방법이어서 의도에 따라 프록시 패턴과 데코레인터 패턴으로 구분한다.

1. 프록시 패턴 : 접근 제어가 목적
2. 데코레이터 패턴 : 새로운 기능 추가가 목적

 

프록시는 개념이고, 프록시를 이용한 패턴이 프록시 패턴과 데코레이터 패턴이다. 데코레이터 패턴에 프록시라는 단어가 안들어가고, 프록시 패턴에 프록시가 들어가기 때문에 프록시를 이용하는 패턴이 무조건 프록시 패턴인 것은 아니다.