[Spring] 디자인 패턴 : 원본 코드를 손대지 않고 부가기능 적용하기

🎓 이 글은 인프런에서 제공하는 "스프링 핵심 원리 - 고급편" 강의를 수강하면서 정리한 내용을 바탕으로 작성한 글입니다.

https://inf.run/FWeFN

 

이전글

[Spring] 디자인 패턴 : 적은 코드 수정으로 공통 로직을 작성하기

 

템플릿 메서드 패턴, 전략 패턴, 템플릿 콜백 패턴을 사용하면 적은 코드 수정으로 공통로직(부가기능) 을 적용할 수 있었다. 

그러나 결국 원본 코드를 수정해야한다는 단점이 있었다. 원본 코드를 손대지 않고 부가기능을 적용할 수 있는 방법을 알아보자. 

 

공통로직(로그 추적기) 요구사항

* 모든 PUBLIC 메서드의 호출과 응답 정보를 로그로 출력

* 애플리케이션의 흐름을 변경하면 안됨 - 로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨

* 메서드 호출에 걸린 시간

* 정상 흐름과 예외 흐름 구분 - 예외 발생 시 예외 정보가 남아야 함

* 메서드 호출의 깊이 표현

* HTTP 요청을 구분

* HTTP 요청 단위로 특정 ID 를 남겨서 어떤 HTTP 요청에서 시작된 것인지 명확하게 구분이 가능해야 함

* 트랜잭션 ID (DB트랜잭션X)

* NEW ! 보안상 일부 로그는 출력하면 안된다. 

 

---

 

• 프록시 패턴 : 프록시로 접근 제어를 하는 것 
• 데코레이터 패턴 : 프록시로 부가 기능을 추가하는 것

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

 

※ 프록시 패턴

목표 : 프록시를 사용한 캐시를 통한 접근 제어

 

▶ 프록시 패턴 구성

public interface Subject {
    String operation();
}

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

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

 

프록시(CacheProxy) 는 실체 객체(RealSubject)과 그 모양이 같아야하기 때문에 Subject 인터페이스를 구현해야 한다.

프록시는 실제 객체를 호출해야하기 때문에 내부에 실제 객체의 참조를 가지고 있어야 한다(target). 

cacheValue 에 값이 있으면 실제 객체를 전혀 호출하지 않고 캐시값을 그대로 반환한다. 따라서 처음 조회 이후에는 cacheValue 에서 매우 빠르게 데이터를 조회할 수 있다. 

 

 

▶ 프록시 패턴 사용

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

 

CacheProxy 가 RealSubject 를 주입 받으면서 CacheProxy가 RealSubject을 참조하는 런타임 객체 의존 관계가 완성된다. 

Client 에는 RealSubject 가 아닌 CacheProxy를 주입한다.

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

 

프록시 패턴의 핵심은 RealSubject 코드와 클라이언트 코드를 전혀 변경하지 않고, 프록시를 도입해서 접근 제어를 했다는 점이다. 그리고 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있다. 실제 클라이언트 입장에서는 프록시 객체가 주입되었는지, 실제 객체가 주입되었는지 알지 못한다. 

 

 

※ 데코레이터 패턴 : 인터페이스 기반

목표 : 프록시를 사용하여 부가 기능 추가하기

 

▶ 데코레이터 패턴 구성

public interface Component {
    String operation();
}

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

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 클래스는 실행 시간을 측정하는 부가기능을 제공한다. 대상을 호출하기 전에 시간을 가지고 있다가, 대상의 호출이 끝나면 호출 시간을 로그로 남겨준다. 

프록시가 호출해야 하는 대상을 component 에 저장한다. 

opearation() 을 호출하면 프록시와 연결된 대상을 호출하고, TimeDecorator 는 실행시간을 측정해서 출력한다. 

 

 

▶ 데코레이터 패턴 사용

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

 

객체 의존 관계는 client > timeDecorator  > realComponent 이다.

 

Decorator 는 스스로 존재할 수 없기에(항상 꾸며줄 대상이 있어야 함), 내부에 호출 대상인 component 를 가지고 있어야 한다. 

프록시 패턴과 데코레이터 패턴의 모양은 거의 같다. 그래서 어떤 상황에 무엇을 사용해야 할지 잘 모르겠다. 

 

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

 

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

 

프록시를 사용하기 위해서는 실제 객체를 스프링 빈으로 등록하지 않고, 프록시를 실제 스프링 빈 대신 등록해야한다는 것을 명심하자. 실제 객체 대신에 프록시 객체를 스프링 빈으로 등록했기 때문에 스프링 빈을 주입 받으면 실체 객체 대신에 프록시 객체가 주입된다. 실체 객체는 프록시 객체가 참조하고 있기 때문에 프록시를 통해 실제 객체를 호출할 수 있다. 실제 객체는 자바 힙 메모리에는 올라가지만 스프링 컨테이너가 관리하지는 않게된다. 

 

지금까지는 인터페이스를 기반으로 프록시를 도입했다. 

하지만 자바의 다형성은 인터페이스를 구현하든, 아니면 클래스를 상속하든 상위 타입만 맞으면 다형성이 적용된다. 클래스 기반으로 상속을 받아서 프록시를 만드는 것도 가능하다. 

 

 

※ 데코레이터 패턴 : 클래스 기반 상속

▶ 데코레이터 패턴 구성 

public class ConcreteLogic {

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

public class TimeProxy extends ConcreteLogic {

    private ConcreteLogic concreteLogic;

    public TimeProxy(ConcreteLogic concreteLogic) {
        this.concreteLogic = concreteLogic;
    }

    @Override
    public String operation() {
        log.info("TimeDecorator 실행");
        long startTime = System.currentTimeMillis();

        String result = concreteLogic.operation();

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("TimeDecorator 종료 resultTime={}ms", resultTime);
        return result;
    }

}

 

 

 

▶ 데코레이터 패턴 사용

public class ConcreteClient {

    private ConcreteLogic concreteLogic;

    public ConcreteClient(ConcreteLogic concreteLogic) {
        this.concreteLogic = concreteLogic;
    }

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

@Test
void addProxy() {
    ConcreteLogic concreteLogic = new ConcreteLogic();
    TimeProxy timeProxy = new TimeProxy(concreteLogic);
    ConcreteClient client = new ConcreteClient(timeProxy);
    client.execute();
}

 

ConcreteClient 생성자에 concreteLogic 이 아니라 timeProxy 를 주입하고 있다. 다형성에 의해 ConcreteLoic 도 들어갈 수 있고, timeProxy 도 들어갈 수 있다. 

 

이렇게 인터페이스가 없어도 클래스 기반으로 프록시를 생성할 수 있지만, 클래스 기반 프록시는 본인의 부모 클래스에만 적용할 수 있다. 인터페이스 기반 프록시는 인터페이스만 같으면 모든 곳에 적용할 수 있다. 따라서 인터페이스를 사용하는 것이 역할과 구현을 명확하게 나누기 때문에 더 좋다. 

 

그러나 이 설계에도 단점은 있다. 인터페이스가 필요하다는 그 자체이다. 모든 객체에 인터페이스를 도입해서 역할과 구현을 나누는 것이 좋지만, 실제로는 구현을 거의 변경할 일이 없는 클래스도 많다. 이때 무작정 인터페이스를 사용하는 것은 번거롭고 그렇게 실용적이지 않다.

이럴때는 인터페이스를 사용하지않고 구체클래스를 사용하는 것이 좋다 (인터페이스가 항상 필요하지는 않다)

 

지금까지 프록시를 사용해서 기존 코드를 변경하지 않고 부가기능을 적용하는 방법을 알아봤다.

문제는, 클래스 기반 프록시의 경우 부가기능을 적용해야 하는 대상 클래스가 100개라면 프록시 클래스도 100개를 만들어야 한다. (클래스 기반 프록시는 본인의 부모 클래스에만 적용할 수 있기 때문이다)

 

프록시 클래스를 하나만 만들어서 모든 곳에 적용할 수는 없을까 ? > 동적 프록시 기술을 알아보자.