7 분 소요

 인프런 스프링 핵심 원리 - 고급편을 학습하고 정리한 내용 입니다.

프록시 패턴 - 예제 코드1

테스트 코드에서 Lombok을 사용하기 위해

1
2
3

//테스트에서 lombok 사용  
testCompileOnly 'org.projectlombok:lombok'  
testAnnotationProcessor 'org.projectlombok:lombok'

build.gradle에 추가하자.

프록시 패턴 - 예제 코드 작성

해당 위치에 패키지를 만든다.

hello.proxy.pureproxy.proxy.code.Subject

1
2
3

public interface Subject {  
    String operation();  
}

예제에서 Subject인터페이스는 단순히 operation()메서드 하나만 가지고 있다.

hello.proxy.pureproxy.proxy.code.RealSubject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Slf4j  
public class RealSubject implements Subject{  
    @Override  
    public String operation() {  
        log.info("실제 객체 호출");  
        sleep(1000);  
        return "";  
    }  
  
    private void sleep(int millis) {  
        try {  
            Thread.sleep(millis);  
        } catch (Exception e) {  
            e.printStackTrace();  
        }  
    }  
}

RealSubject는 Subject인터페이스를 구현했다. operation()은 데이터 조회를 시뮬레이션 하기 위해 1초 쉬도록 했다.

호출할 때마다 시스템에 큰 부하를 주는 데이터 조회라고 가정하는 것이다.

hello.proxy.pureproxy.proxy.code.ProxyPatternClient

1
2
3
4
5
6
7
8
9
10
11

public class ProxyPatternClient {  
    private Subject subject;  
  
    public ProxyPatternClient(Subject subject) {  
        this.subject = subject;  
    }  
  
    public void execute() {  
        subject.operation();  
    }  
}

Subject인터페이스에 의존하고, Subject를 호출하는 클라이언트 코드이다.

execute()를 실행하면 subject.operation()를 호출한다.

hello.proxy.pureproxy.proxy.ProxyPatternTest

1
2
3
4
5
6
7
8
9
10
11
12
13

public class ProxyPatternTest {  
  
    @Test  
    void noProxyTest() {  
        RealSubject realSubject = new RealSubject();  
        ProxyPatternClient client = new ProxyPatternClient(realSubject);  
  
        client.execute();  
        client.execute();  
        client.execute();  
  
    }  
}

테스트 코드에서는client.execute() 를 3번 호출한다.

데이터를 조회하는데 1초가 소모되므로 총 3초의 시간이 걸린다.

3초 걸리는게 정상이다.

그런데 이 데이터가 한번 조회하면 변하지 않는 데이터라면 어딘가에 보관해두고 이미 조회한 데이터를 사용하는 것이 성능상 좋다.

이런 것을 캐시라고 한다.

프록시 패턴의 주요 기능은 접근 제어이다. 캐시도 접근 자체를 제어하는 기능 중 하나 이다.

이미 개발된 로직을 전혀 수정하지 않고, 프록시 객체를 통해서 캐시를 적용해보자.

프록시 패턴 - 예제 코드2

클라이언트가 realSubject를 직접 사용 하는게 아니라 proxy를 사용하도록 해야한다.

hello.proxy.pureproxy.proxy.code.CacheProxy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@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)를 호출해서 값을 구한다. 그리고 구한 값을 cacheValue에 저장하고 반환한다. 만약 cacheValue에 값이 있으면 실제 객체를 전혀 호출하지 않고, 캐시 값을 그대로 반환한다. 따라서 처음 조회 이후에는 캐시(cacheValue)에서 매우 빠르게 데이터를 조회할 수 있다.

cacheProxyTest()

테스트 추가

hello.proxy.pureproxy.proxy.ProxyPatternTest

1
2
3
4
5
6
7
8
9
10

@Test  
void cacheProxyTest() {  
    RealSubject realSubject = new RealSubject();  
    CacheProxy 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런타임 객체 의존 관계가 완성된다.

결과적으로 3초에서 1초로 시간이 줄어 들었다.

정리

프록시 패턴의 핵심은 RealSubject코드와 클라이언트 코드를 전혀 변경하지 않고, 프록시를 도입해서 접근 제어를 했다는 점이다.

그리고 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있다.

실제 클라이언트 입장에서는 프록시 객체가 주입 되었는지, 실제 객체가 주입 되었는지 알지 못한다.

데코레이터 페턴 - 예제 코드 1

프록시 패턴 예제와 비슷한 흐름으로 1에선 사용X 2에선 적용하는 방식으로 해보자.

해당 decorator 패키지에 만들었다.

hello.proxy.pureproxy.decorator.code.Component

1
2
3

public interface Component {  
    String operation();  
}

Component인터페이스는 단순히 String operation()메서드를 가진다.

hello.proxy.pureproxy.decorator.code.RealComponent

1
2
3
4
5
6
7
8

@Slf4j  
public class RealComponent implements Component{  
    @Override  
    public String operation() {  
        log.info("RealComponent 실행");  
        return "data";  
    }  
}
  • RealComponent는 Component인터페이스를 구현한다.
  • operation() : 단순히 로그를 남기고 "data" 문자를 반환한다.

hello.proxy.pureproxy.decorator.code.DecoratorPatternClient

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Slf4j  
public class DecoratorPatternClient {  
  
    private Component component;  
  
    public DecoratorPatternClient(Component component) {  
        this.component = component;  
    }  
  
    public void execute() {  
        String result = component.operation();  
        log.info("result= {}", result);  
    }  
}
  • 클라이언트 코드는 단순히 Component 인터페이스를 의존한다.
  • execute()를 실행하면 component.operation()을 호출하고, 그 결과를 출력한다.

hello.proxy.pureproxy.decorator.DecoratorPatternTest

1
2
3
4
5
6
7
8
9
10
11

@Slf4j  
public class DecoratorPatternTest {  
  
    @Test  
    void noDecorator() {  
        Component realComponent = new RealComponent();  
        DecoratorPatternClient client = new DecoratorPatternClient(realComponent);  
  
        client.execute();  
    }  
}

테스트 코드는 client -> realComponent 의 의존 관계를 설정하고, client.execute()를 호출한다.

1
2

RealComponent - RealComponent 실행 
DecoratorPatternClient - result=data

한번 감싸서 실행한 것일 뿐 어렵진 않다.

데코레이터 패턴 - 예제 코드 2

부가 기능 추가
앞서 설명한 것처럼 프록시를 통해서 할 수 있는 기능은 크게 접근 제어와 부가 기능 추가라는 2가지로 구분한다. 앞서 프록시 패턴에서 캐시를 통해 접근 제어를 알아 보았다. 이번에는 프록시를 활용해서 부가 기능을 추가해보자.

이렇게 프록시로 부가 기능을 추가하는 것을 데코레이터 패턴이라 한다.

데코레이터 패턴 : 원레 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.

  • 예) 요청 값이나, 응답 값을 중간에 변형한다.
  • 예) 실행 시간을 측정해서 추가 로그를 남긴다.

응답 값을 꾸며주는 데코레이터

MessageDecorator를 만들어 보자. 테스트 패키지에 만든다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Slf4j  
public class MessageDecorator implements Component{  
  
    private Component component;  
  
    public MessageDecorator(Component component) {  
        this.component = component;  
    }  
  
    @Override  
    public String operation() {  
        log.info("MessageDecorator 실행");  
  
        String result = component.operation();  
        String decoResult = "*****" + result + "*****";  
        log.info("MessageDecorator 꾸미기 적용 전 = {}, 꾸미기 적용 후 = {}", result, decoResult);  
        return decoResult;  
    }  
}

자 Component 인터페이스를 구현한다.

그리고 생성자를 통해서 비즈니스 로직을 받아서 사용한다.

1

String result = component.operation();

다음과 같은 비즈니스 로직을

1
2
3
4
5
6
7
8
9
10

log.info("MessageDecorator 실행");

// 비즈니스 로직
String result = component.operation();


String decoResult = "*****" + result + "*****";  
log.info("MessageDecorator 꾸미기 적용 전 = {}, 꾸미기 적용 후 = {}", result, decoResult); 
return decoResult;

문자열을 꾸며주는 로직 사이에 위치 시켜서 추가적인 일을 하게 만든다.

테스트를 해보자.

1
2
3
4
5
6
7
8

@Test  
void decorator1() {  
    Component realComponent = new RealComponent();  
    Component messageDecorator = new MessageDecorator(realComponent);  
    DecoratorPatternClient client = new DecoratorPatternClient(messageDecorator);  
  
    client.execute();  
}

realComponent를 만들고 그걸 messageDecorator 안에 넣어서 생성한다.

그 후 DecoratorPatternClient 클라이언트 코드를 실행한다.

실행 결과를 보면 MessageDecorator가 RealComponent를 호출하고 반환한 응답 메시지를 꾸며서 반환한 것을 확인할 수 있다.

데코레이터 패턴 - 예제 코드 3

실행 시간을 측정하는 데코레이터

이번에는 기존 데코레이터에 더해서 실행 시간을 측정하는 기능까지 추가해보자.

프록시는 체이닝이 가능하기 때문에 timeDecorator에 messageDecorator를 물리고 거기다 realComponent를 물린다.

timeDecorator를 만들자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@Slf4j  
public class TimeDecorator implements Component{  
  
    private Component component;  
  
    public TimeDecorator(Component component) {  
        this.component = component;  
    }  
  
    @Override  
    public String operation() {  
        log.info("TimeDecorator 실행");  
        long startTime = System.currentTimeMillis();  
  
        String result = component.operation();  
  
        long endTime = System.currentTimeMillis();  
        long resultTime = endTime - startTime;  
        log.info("TimeDecorator 종료 realTime = {}ms", resultTime);  
        return result;  
    }  
}

TimeDecorator는 실행 시간을 측정하는 부가 기능을 제공한다.

대상을 호출하기 전에 시간을 가지고 있다가, 대상 의 호출이 끝나면 호출 시간을 로그로 남겨준다.

자 이제 이걸 어떻게 실행해야 할 지 테스트 코드를 통해 알아보자.

1
2
3
4
5
6
7
8
9

@Test  
void decorator2() {  
    Component realComponent = new RealComponent();  
    Component messageDecorator = new MessageDecorator(realComponent);  
    Component timeDecorator = new TimeDecorator(messageDecorator);  
    DecoratorPatternClient client = new DecoratorPatternClient(timeDecorator);  
  
    client.execute();  
}

client -> timeDecorator -> messageDecorator -> realComponent의 객체 의존 관계를 설정하고 실행한다.

실행 결과를 보면 TimeDecorator가 MessageDecorator를 실행하고 MessageDecorator가 RealComponenet를 실행한다.

프록시 패턴과 데코레이터 패턴 정리

Decorator를 생각해보면 일부 중복이 있다. 꾸며주는 역할을 하는 Decorator들은 스스로 존재할 수 없다. 항상 꾸며줄 대상이 있어야 한다. 따라서 내부에 호출 대상인 component를 가지고 있어야 한다.

그리고 component를 항상 호출해야 한다. 이 부분이 중복이다. 이런 중복을 제거하기 위해 component를 속성으로 가지고 있는 Decorator라는 추상 클래스를 만드는 방법도 고민할 수 있다. 이렇게 하면 추가로 클래스 다이어그램에서 어떤 것이 실제 컴포넌트인지, 데코레이터인지 명확하게 구분할 수 있다.

여기까지 고민한 것이 바로 GOF에서 설명하는 데코레이터 패턴의 기본 예제이다.

프록시 패턴 vs 데코레이터 패턴

여기까지 진행하면 몇 가지 의문이 들 것이다.

  • Decorator라는 추상 클래스를 만들어야 데코레이터 패턴일까?
  • 프록시 패턴과 데코레이터 패턴이 모양이 비슷하다.

의도(intent)

사실 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 같고, 상황에 따라 정말 똑같을 때도 있다.

그러면 둘을 어떻게 구분하는 것일까?

디자인 패턴에서 중요한 것은 해당 패턴의 겉모양이 아니라 그 패턴을 만든 의도가 더 중요하다. 따라서 의도에 따라 패턴을 구분한다.

  • 프록시 패턴의 의도 : 다른 개체에 대한 접근을 제어하기 위해 대리자를 제공
  • 데코레이터 패턴의 의도 : 객체의 추가 책임(기능)을 동적으로 추가하고, 기능 확장을 위한 유연한 대안 제공

즉 프록시를 사용하고 해당 프록시가 접근 제어가 목적이라면 프록시 패턴이고, 새로운 기능을 추가하는 것이 목적이라면 데코레이터 패턴이 된다.

댓글남기기

참고