내가 공부한것을 올리며, 중요한 단원은 저 자신도 곱씹어 볼겸 상세히 기록하고 얕은부분들은 가겹게 포스팅 하겠습니다.
1. 프록시 패턴, 데코레이터 패턴 - 소개
프록시는 아무 객체나 프록시가 될수있는것은 아니다.
객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지, 프록시에게 요청을 한 것인지 조차 몰라야 한다.
쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 사용해야 한다.
그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다.
클래스 의존관계를 보면 클라이언트는 서버 인터페이스( ServerInterface )에만 의존한다.
그리고 서버와 프록시가 같은 인터페이스를 사용한다. 따라서 DI를 사용해서 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있다.
▶ 프록시의 주요 기능
프록시를 통해서 할 수 있는 일은 크게 2가지로 구분할 수 있다.
- 접근 제어
- 권한에 따른 접근 차단
- 캐싱
- 지연 로딩
- 부가 기능 추가
- 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.
- 예) 요청 값이나, 응답 값을 중간에 변형한다.
- 예) 실행 시간을 측정해서 추가 로그를 남긴다.
프록시 객체가 중간에 있으면 크게 접근 제어와 부가 기능 추가를 수행할 수 있다.
둘다 프록시를 사용하는 방법이지만 GOF 디자인 패턴에서는 이 둘을 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분
- 프록시 패턴: 접근 제어가 목적
- 데코레이터 패턴: 새로운 기능 추가가 목적
2. 프록시 패턴 - 예제 코드1
프록시 패턴을 이해하기 위한 예제 코드를 만들어보자.
▶ Subject Interface
public interface Subject {
String operation();
}
이를 구현하는 RealSubject를 만들어보자!
▶ RealSubject
@Slf4j
public class RealSubject implements Subject {
@Override
public String operation() {
log.info("실제 객체 호출");
sleep(1000);
return "data";
}
private void sleep(int millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
RealSubject 는 Subject 인터페이스를 구현했다. operation() 은 데이터 조회를 시뮬레이션 하기 위해 1초 쉬도록 했다.
예를 들어서 데이터를 DB나 외부에서 조회하는데 1초가 걸린다고 생각하면 된다.
▶ ProxyPatternClient
public class ProxyPatternClient {
private Subject subject;
public ProxyPatternClient(Subject subject) {
this.subject = subject;
}
public void execute() {
subject.operation();
}
}
이를 사용하는 테스트를 하나 만들어보자.
public class ProxyPatternTest {
@Test
public void no_proxy_test() {
RealSubject realSubject = new RealSubject();
ProxyPatternClient client = new ProxyPatternClient(realSubject);
client.execute();
client.execute();
client.execute();
}
}
client.execute() 를 총 3번 호출한다. 데이터를 조회하는데 1초가 소모되므로 총 3 초의 시간이 걸릴것 이다!
실행 결과는 다음과 같다.
그런데 이 데이터가 한번 조회하면 변하지 않는 데이터라면 어딘가에 보관해두고 이미 조회한 데이터를 사용하는 것이 성능상 좋다.
이런 것을 캐시라고 한다.
프록시 패턴의 주요 기능은 접근 제어이다. 캐시도 접근 자체를 제어하는 기능 중 하나이다.
3. 프록시 패턴 - 예제 코드2
이번에는 프록시 패턴을 적용해보자!
런타임에서의 의존대상이 proxy로 변경되었다!
▶ CacheProxy
@Slf4j
public class CacheProxy implements Subject {
private Subject target;
private String cacheValue;
public CacheProxy(Subject target) {
this.target = target;
}
@Override
public String operation() {
log.info("프록시 호출");
if(cacheValue == null) {
cacheValue = target.operation();
}
return cacheValue;
}
}
프록시도 실제 객체와 동일하게 Subject 인터페이스를 구현해야 한다.
private Subject target
클라이언트가 프록시를 호출하면 프록시가 최종적으로 실제 객체를 호출해야 한다.
따라서 내부에 실제 객체의 참조를 가지고 있어야 하는데, 우리의 코드에서는 target이라는 이름으로 참조를 만들었다.
operation()
구현한 코드를 보면 cacheValue 에 값이 없으면 실제 객체( target )를 호출해서 값을 구한다. 이때 구한 값을 caching한다.
만약 cacheValue 에 cache된 값이 있다면 실제 객체를 전혀 호출하지 않고, 캐시 값을 그대로 반환한다.
따라서 처음 조회 이후에는 캐시( cacheValue ) 에서 매우 빠르게 데이터를 조회할 수 있다.
이를 사용하는 테스트 코드를 추가해 보자.
public class ProxyPatternTest {
@Test
void cacheProxyTest() {
Subject realSubject = new RealSubject();
Subject cacheProxy = new CacheProxy(realSubject);
ProxyPatternClient client = new ProxyPatternClient(cacheProxy);
client.execute();
client.execute();
client.execute();
}
}
RealSubject 와 CacheProxy의 객체를 생성하고 둘을 연결한다.
결과적으로 cacheProxy 가 realSubject 를 참조하는 런타임 객체 의존관계가 완성된다.
그리고 client 에는 realSubject 가 아닌 cacheProxy 를 주입한다.
이 과정을 통해서 client -> cacheProxy -> realSubject 런타임 객체 의존 관계가 완성된다.
테스트코드는 이전과 같이 client.execute()를 3번 호출한다. 하지만 실행 시간이 달라졌다!
캐시 기능을 통해 엄청 빨라졌다.
client.execute()을 3번 호출하면 다음과 같이 처리된다.
1. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 없다. -> realSubject를 호출, 결과를 caching (1초)
2. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 있다. -> cacheProxy에서 즉시 반환 (0초)
3. client의 cacheProxy 호출 -> cacheProxy에 캐시 값이 있다. -> cacheProxy에서 즉시 반환 (0초)
프록시를 도입 한 이후부터는 거의 1초안에 값을 반환하게 되었다.
프록시 패턴의 핵심은 RealSubject 코드와 클라이언트 코드를 전혀 변경하지 않고, 프록시를 도입해서 접근 제어를 했다는 점이다.
더 자세한 Proxy패턴의 설명은 다음 글을 읽어보길 권장한다.
'BackEnd > Spring' 카테고리의 다른 글
[Spring] 인터페이스, 구체 클래스 기반 프록시 (0) | 2022.08.10 |
---|---|
[Spring] 데코레이터 패턴 (0) | 2022.08.10 |
[Spring] 프록시 패턴과 데코레이터 패턴 예제 (0) | 2022.08.09 |
[Spring] 템플릿 콜백 패턴 (0) | 2022.08.07 |
[Spring] 전략 패턴 (0) | 2022.08.07 |
댓글