[스프링 핵심원리 - 고급편] #4. 프록시 패턴과 데코레이터 패턴(2)

[YONGHYNG]

프록시, 프록시 패턴, 데코레이터 패턴 - 소개

• 클라이언트와 서버의 개념은 상당히 넓게 사용됨 클라이언트는 의뢰인이라는 뜻이고, 서버는 '서비스나 상품을 제공하는 사람이나 물건'
• 따라서 클라이언트와 서버의 기본 개념을 정의하면 클라이언트는 서버에 필요한 것을 요청하고, 서버는 클라이언트의 요청을 처리하는 것
• 이 개념을 우리가 익숙한 컴퓨터 네트워크에 도입하면 클라이언트는 웹 브라우저가 되고 ,요청을 처리하는 서버는 웹 서버가 됨
• 이 개념을 객체에 도입하면, 요청하는 객체는 클라이언트가 되고, 요청을 처리하는 객체는 서버가 됨

• 클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과 직접 받음
• 위 내용을 직접 호출이라고 함

• 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있음
• 예를 들어서 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있고 여기서 대신 장을 보는 대리자를 영어로 프록시(Proxy)

예시

• 재미있는 점은 직접 호출과 다르게 간접 호출을 하면 대리자가 중간에서 여러가지 일을 할 수 있다는 점
• 엄마에게 라면을 사달라고 부탁 했는데, 엄마는 그 라면은 이미 집에 있다고 할 수도 있음, 그러면 기대한 것 보다 더 빨리 라면을 먹을 수 있음 (접근 제어, 캐싱), 아버지께 자동차 주유를 부탁했는데, 아버지가 주유 뿐만 아니라 세차까지 하고 왔음, 클라이언트가 기대한 것 외에 세차라는 부가 기능까지 얻게 됨
• (부가 기능 추가) 그리고 대리자가 또 다른 대리자를 부를 수도 있음, 예를 들어서 내가 동생에게 라면을 사달라고 했는데, 동생은 또 다른 누군가에게 라면을 사달라고 다시 요청할 수도 있다. 중요한 점은 클라이언트는 대리자를 통해서 요청했기 때문에 그 이후 과정은 모른다는 점, 동생을 통해서 라면이 나에게 도착하기만 하면 됨(프록시 체인)
  

대체 가능

• 그런데 여기까지 듣고 보면 아무 객체나 프록시가 될 수 있는 것 같음, 객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지, 프록시에게 요청을 한 것인지 조차 몰라야 함
• 쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 사용해야 함, 그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 함

서버와 프록시가같은 인터페이스 사

• 클래스 의존관계를 보면 클라이언트는 서버 인터페이스( ServerInterface )에만 의존. 그리고 서버와 프록시가 같은 인터페이스를 사용, 따라서 DI를 사용해서 대체 가능

• 이번에는 런타임 객체 의존 관계를 보면, 런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 Client -> Server 에서 Client -> Proxy 로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 됨
• 클라이언트 입장에서는 변경 사실 조차 모름, DI를 사용하면 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있음

프록시의 주요 기능

1. 접근 제어

• 권한에 따른 접근 차단
• 캐싱
• 지연 로딩

2. 부가 기능 추가

• 원래 서버가 제공하는 기능에 더해서 부가 기능 수행

• 요청 값이나, 응답 값을 중간에 변형

• 실행 시간을 측정해서 추가 로그 남김

• 프록시 객체가 중간에 있으면 크게 접근 제어와 부가 기능 추가를 수행

GOF 디자인 패턴

• 둘다 프록시를 사용하는 방법이지만 GOF 디자인 패턴에서는 이 둘을 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분

• 프록시 패턴: 접근 제어가 목적

• 데코레이터 패턴: 새로운 기능 추가가 목적

• 둘다 프록시를 사용하지만, 의도가 다르다는 점이 핵심이다. 용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아님, 데코레이터 패턴도 프록시를 사용

참고 프록시라는 개념은 클라이언트 서버라는 큰 개념안에서 자연스럽게 발생할 수 있음, 프록시는 객체안에서의 개념도 있고, 웹 서버에서의 프록시도 있다. 객체안에서 객체로 구현되어있는가, 웹 서버로 구현되어 있는가 처럼 규모의 차이가 있을 뿐 근본적인 역할은 같음

프록시 패턴 - 예제 코드1

Subject

package hello.proxy.pureproxy.proxy.code;

public interface Subject {
      String operation();
}

• 예제에서 Subject 인터페이스는 단순히 operation() 메서드 하나만 가지고 있음
• RealSubject와 CacheProxy 모두 이 인터페이스를 구현

RealSubject

package hello.proxy.pureproxy.proxy.code;

import lombok.extern.slf4j.Slf4j;

@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

package hello.proxy.pureproxy.proxy.code;

public class ProxyPatternClient {

    private Subject subject;

    public ProxyPatternClient(Subject subject){
        this.subject = subject;
    }

    public void execute(){
        subject.operation();
    }
}

• Subject 인터페이스에 의존하고, Subject 를 호출하는 클라이언트 코드
• execute()를 실행하면 subject.operation()을 호출

ProxyPatternTest

package hello.proxy.pureproxy.proxy;

import hello.proxy.pureproxy.proxy.code.ProxyPatternClient;
import hello.proxy.pureproxy.proxy.code.RealSubject;
import org.junit.jupiter.api.Test;

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초의 시간이 걸림

실행 결과

프록시 패턴 - 예제 코드2

CacheProxy

package hello.proxy.pureproxy.proxy.code;

import lombok.extern.slf4j.Slf4j;

@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 )에서 매우 빠르게 데이터를 조회할 수 있음

ProxyPatternTest

package hello.proxy.pureproxy.proxy;

import hello.proxy.pureproxy.proxy.code.CacheProxy;
import hello.proxy.pureproxy.proxy.code.ProxyPatternClient;
import hello.proxy.pureproxy.proxy.code.RealSubject;
import hello.proxy.pureproxy.proxy.code.Subject;
import org.junit.jupiter.api.Test;

public class ProxyPatternTest {

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

    @Test
    void cacheProxyTest(){
        Subject realSubject = new RealSubject();
        Subject cacheProxy = new CacheProxy(realSubject);
        ProxyPatternClient client = new ProxyPatternClient(cacheProxy);
        client.execute();
        client.execute();
     }
}

• cacheProxyTest()1 : realSubject 와 cacheProxy 를 생성하고 둘을 연결, 결과적으로 cacheProxy 가 realSubject 를 참조하는 런타임 객체 의존관계가 완성
• 그리고 마지막으로 client 에 realSubject 가 아닌 cacheProxy 를 주입, 이 과정을 통해서 client->cacheProxy -> realSubject 런타임 객체 의존 관계가 완성
• cacheProxyTest() 는 client.execute() 을 총 3번 호출, 이번에는 클라이언트가 실제 realSubject
  를 호출하는 것이 아니라 cacheProxy 를 호출

실행 결과

client.execute()을 3번 호출하면 다음과 같이 처리

• 1.client의 cacheProxy 호출 cacheProxy에 캐시 값 없음, realSubject를 호출, 결과를 캐시에 저장 (1초)
• 2.client의 cacheProxy 호출 cacheProxy에 캐시 값 있음, cacheProxy에서 즉시 반환 (0초)
• 3.client의 cacheProxy 호출 cacheProxy에 캐시 값이 있음, cacheProxy에서 즉시 반환 (0초)

정리

• 결과적으로 캐시 프록시를 도입하기 전에는 3초가 걸렸지만, 캐시 프록시 도입 이후에는 최초에 한번만 1초가 걸리고, 이후에는 거의 즉시 반환
• 프록시 패턴의 핵심은 RealSubject 코드와 클라이언트 코드를 전혀 변경하지 않고, 프록시를 도입해서 접근 제어를 했다는 점
• 그리고 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있음, 실제 클라이언트 입장에서는 프록시 객체가 주입되었는지, 실제 객체가 주입되었는지 알지 못함

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

Component 인터페이스

package hello.proxy.pureproxy.decorator.code;

public interface Component {
    String operation();
}

• Component 인터페이스는 단순히 String operation() 메서드를 가짐

RealComponent

package hello.proxy.pureproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class RealComponent implements Component{

    @Override
    public String operation() {
        log.info("RealComponent 실행");
        return "data";
    }
}

• RealComponent 는 Component 인터페이스를 구현
• operation() : 단순히 로그를 남기고 "data" 문자를 반환

DecoratorPatternClient

package hello.proxy.pureproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@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() 을 호출하고, 그 결과를 출력

DecoratorPatternTest

package hello.proxy.pureproxy.decorator;

import hello.proxy.pureproxy.decorator.code.Component;
import hello.proxy.pureproxy.decorator.code.DecoratorPatternClient;
import hello.proxy.pureproxy.decorator.code.RealComponent;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class DecoratorPatternTest {

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

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

실행 결과

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

부가 기능 추가

• 프록시를 통해서 할 수 있는 기능은 크게 접근 제어와 부가 기능 추가라는 2가지로 구분 함
• 프록시 패턴에서 캐시를 통한 접근 제어를 알아봄 이번에는 프록시를 활용해서 부가 기능을 추가, 이렇게 프록시로 부가 기능을 추가하는 것을 데코레이터 패턴이라 함

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

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

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

MessageDecorator

package hello.proxy.pureproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@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;
    }
}

• MessageDecorator 는 Component 인터페이스를 구현
• 프록시가 호출해야 하는 대상을 component 에 저장
• operation() 을 호출하면 프록시와 연결된 대상을 호출( component.operation()) 하고, 그 응답 값에
  ***** 을 더해서 꾸며준 다음 반환

예상 : 응답 값

• 꾸미기 전: data
• 꾸민 후 : data

package hello.proxy.pureproxy.decorator;

import hello.proxy.pureproxy.decorator.code.Component;
import hello.proxy.pureproxy.decorator.code.DecoratorPatternClient;
import hello.proxy.pureproxy.decorator.code.MessageDecorator;
import hello.proxy.pureproxy.decorator.code.RealComponent;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class DecoratorPatternTest {

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

    @Test
    void decorator1(){
        Component realComponent = new RealComponent();
        Component messageDecorator = new MessageDecorator(realComponent);

        DecoratorPatternClient client = new DecoratorPatternClient(messageDecorator);
        client.execute();
    }
}

• client -> messageDecorator -> realComponent 의 객체 의존 관계를 만들고 client.execute() 를 호출

예상 값

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

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

TimeDecorator

package hello.proxy.pureproxy.decorator.code;

import lombok.extern.slf4j.Slf4j;

@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 종료 resultTime={}ms", resultTime);
        return result;
    }
}

DecoratorPatternTest

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

• 실행 결과를 보면 TimeDecorator 가 MessageDecorator 를 실행하고 실행 시간을 측정해서 출력한 것을 확인할 수 있음

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

GOF 데코레이터 패턴

• 여기서 생각해보면 Decorator 기능에 일부 중복이 있다. 꾸며주는 역할을 하는 Decorator 들은 스스로 존재할 수 없음
• 항상 꾸며줄 대상이 있어야 한다. 따라서 내부에 호출 대상인 component 를 가지고 있어야 함
• component 를 항상 호출, 이 부분이 중복, 이런 중복을 제거하기 위해 component 를 속성으로 가지고
  있는 Decorator 라는 추상 클래스를 만드는 방법도 고민할 수 있음
• 위처럼 하면 추가로 클래스 다이어그램에서 어떤 것이 실제 컴포넌트 인지, 데코레이터인지 명확하게 구분 가능
• 여기까지 고민한 것이 바로 GOF에서 설명하는 데 코레이터 패턴의 기본 예제

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

궁금증?

• Decorator 라는 추상 클래스를 만들어야 데코레이터 패턴일까?
• 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 비슷한 것 같은데?

의도(intent)

• 사실 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 같고, 상황에 따라 정말 똑같을 때도 있음
• 디자인 패턴에서 중요한 것은 해당 패턴의 겉모양이 아니라 그 패턴을 만든 의도가 더 중요, 따라서 의도에 따라 패턴을 구분
• 프록시 패턴의 의도: 다른 개체에 대한 접근을 제어하기 위해 대리자를 제공
• 데코레이터 패턴의 의도: 객체에 추가 책임(기능)을 동적으로 추가하고, 기능 확장을 위한 유연한 대안 제공

정리

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