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

[Pracrobo]

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

프록시에 대해 알아보자

클라이언트와 서버

Client와 Server 라고 하면 개발자들은 보통 서버 컴퓨터를 생각하는데 사실 클라이언트와 서버의 개념은 상당히 넓게 사용된다. 클라이언트는 의뢰인, 서버는 ‘서비스나 상품을 제공하는 사람이나 물건’을 뜻한다. 따라서 클라이언트와 서버의 기본 개념을 정의하면 클라이언트는 서버에 필요한 것을 요청하고 서버는 클라이언트의 요청을 처리하는 것이다.

이 개념을 우리가 익숙한 컴퓨터 네트워크에 도입하면 클라이언트는 웹 브라우저, 요청을 처리하는 서버는 웹 서버가 된다.

이 개념을 객체에 도입하면 요청하는 객체는 클라이언트가 되고 요청을 처리하는 객체는 서버가 된다.

직접 호출과 간접 호출

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

그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다. 예를 들어서 대신 뭔가를 해달라고 부탁할 수 있는데 대신 해주는 것을 Proxy라 한다.

예시

• 엄마에게 라면 → 라면이 이미 집에 있다.

• 기대한 것보다 더 빨리 라면을 먹을 수 있다.(접근 제어, 캐싱)

• 아빠한테 주유를 부탁했는데 아빠가 세차까지 하고 왔다.

• 클라이언트가 기대한 것 외에 부가기능까지 얻게 되었다. (부가 기능 추가)

• 대리자가 또 다른 대리자를 부를때

• 동생한테 물건을 사달라했는데 동생이 셋째한테 물건 사오라고 요청

• 클라이언트는 대리자를 통해서 요청했기 때문에 그 이후 과정은 모른다 마지막에 동생을 통해 물건이 나에게 도착하기만 하면 된다. (프록시 체인)
  

대체 가능

여기까지 듣고 보면 아무 객체나 프록시가 될 수 있는 것 같다.

객체에서 프록시가 되려면 클라이언트는 서버에게 요청을 한 것인지 프록시에게 요청을 한 것인지 조차 몰라야 한다.

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

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

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

런타임 객체 의존 관계

이번에는 런타임 의존관계를 살펴보자.

런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 Clinet > Server 에서 Client > Proxy 로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 된다. 클라이언트 입장에서는 변경 사실조차 모른다.

DI를 사용하면 클라이언트 코드의 변경없이 유연하게 프록시를 주입할 수 있다.

프록시의 주요 기능

프록시를 통해서 할 수 있는 일은 크게 2가지다.

• 접근 제어
  • 권한에 따른 접근 차단
  • 캐싱
  • 지연 로딩
• 부가 기능 추가
  • 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.
  • 예) 요청 값이나 응답 값을 중간에 변형한다.
  • 예) 실행 시간을 측정해서 추가 로그를 남긴다.

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

GOF 디자인 패턴

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

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

둘다 프록시를 사용하지만 의도가 다르다는 점이 핵심이다.

용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아니다. 데코레이터 패턴도 프록시를 사용한다.

이왕 프록시를 학습하기로 했으니 GOF 디자인 패턴에서 설명하는 프록시 패턴과 데코레이터 패턴을 나누어 학습해보자.

참고

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

프록시 패턴 - 예제 코드 1

테스트 코드에 Lombok 적용하기

build.gradle 의존관계 추가.

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

이렇게 해야 테스트 코드에서 @Slf4j 와 같은 애노테이션이 작동한다.

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

프록시 패턴 도입하기 전 코드를 단순히 만들어 보자.

interface Subject

package hello.proxy.pureproxy.proxy.code;

public interface Subject {
    String operation();
}

Subject 인터페이스는 operation() 메서드 하나만 가지고 있다.

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

    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();
    }
}

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 - cacheProxyTest() 추가

    @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 런타임 객체 의존 관계가 완성된다.

• cacheProxyTest() 는 client.execute() 을 총 3번 호출한다. 이번에는 클라이언트가 실제 realSubject 를 호출하는 것이 아니라 cacheProxy 를 호출하게 된다.

실행 결과

• 처음에는 프록시 호출을 찍고(realSubjcet 호출, 결과를 캐시에 저장) 그다음에 캐시에서 값을 가져와 cacheProxy에서 즉시 반환(0, 0초)

결과적으로 캐시 프록시를 도입하기 전에는 3초가 걸렸지만 , 캐시 프록시 도입 이후에는 최초 1번만 1초가 걸리고 이후에는 거의 즉시 반환한ㄷ.

정리

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

그리고 클라이언트 코드의 변경없이 자유롭게 프록시를 넣고 뺄 수 있다. 실제 클라이언트 입장에서는 프록시 객체가 주입되었는지 실제 객체가 주입되었는지 알지 못한다.

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

데코레이터 패턴을 이해하기 위한 예제 코드를 작성해보자. 먼저 데코레이터 패턴을 도입하기 전 코드를 아주 단순하게 만들어보자.

Component 인터페이스

package hello.proxy.pureproxy.decorator.code;

public interface Component {
    String operation();
}

DecoratorComponentClient

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);

    }
}

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

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 DecoraterPatternTest {

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

실행

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

부가 기능 추가

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

• 데코레이터 패턴 : 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.
  • ex) 요청 값이나 응답 값을 중간에 변형한다.
  • ex) 실행 시간을 측정해서 추가 로그를 남긴다.

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

응답 값을 꾸며주는 데코레이터 프록시를 만들어보자.

• messageDecorator 를 의존하게 만들어준다.

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 실행");
        //data -> *****data*****
        String result = component.operation();
        String decoResult = "****" + result + "*****";
        log.info("MessageDecorator 꾸미기 적용 전={}, 적용 후 = {}", result, decoResult);
        return decoResult;
    }
}

• MessageDecorator 는 Component 인터페이스를 구현한다.
• 프록시가 호출해야 하는 대상을 component 에 저장한다.
• operation() 을 호출하면 프록시와 연결된 대상을 호출(component.operation() )하고 그 응답 값에 ***** 을 더해서 꾸며준 다음 반환한다.
• 예를 들어서 응답값이 data 라면 다음과 같다.
  • 꾸미기 전 ‘data’
  • 꾸민 후 : data

DecoratorPatternTest

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

• client 코드를 수정한 적이 없다.

실행

데코레이터 패턴 - 예제 코드 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;
    }
}

• TimeDecorator 는 실행 시간을 측정하는 부가 기능을 제공한다. 대상을 호출하기 전에 시간을 가지고 있다가 대상의 호출이 끝나면 호출 시간을 로그로 남겨준다.

Test

   @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를 실행하고 실행 시간을 측정해서 출력한 것을 확인할 수 있다.

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

GOF 데코레이터 패턴

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

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

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

Intent - 의도

사실 프록시 패턴과 데코레이터 패턴은 그 모양이 거의 같고 상황에 따라 정말 똑같을 때도 있다. 그러면 둘을 어떻게 구분하는 것일까?

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

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

정리

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