[스프링 핵심 원리 - 고급편] 템플릿 메서드 패턴과 콜백 패턴

본문은 인프런의 [스프링 핵심 원리 - 고급편]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

스프링 핵심 원리 - 고급편
1. 쓰레드 로컬
2. 템플릿 메서드 패턴과 콜백 패턴
3. 프록시 패턴과 데코레이터 패턴
4. 동적 프록시 기술
5. 스프링이 지원하는 프록시
6. 빈 후처리기
7. @Aspect AOP
8. 스프링 AOP 개념
9. 스프링 AOP 구현
10. 포인트컷
11. 실무 주의사항

 
전 챕터에서는 쓰레드 로컬을 이용해서 thread-safe한 로그 추적기를 구현해봤다. 그러나 이 로그 추적기의 도입으로 핵심 기능 코드 외에 부가 기능을 처리하는 코드가 포함되었다. 각 계층(controller, service, repository)은 다음과 같은 동일한 패턴을 지닌다.

TraceStatus status = null;
try {
    status = trace.begin("OrderService.orderItem()");
    // 핵심 기능 (나머지는 로깅을 위한 부가적인 코드)
    trace.end(status);
} catch (Exception e) {
    trace.exception(status, e);
    throw e; 
}

 
 
이렇게 핵심 기능과 부가 기능이 섞이게 되면 코드를 유지보수하기가 상당히 까다로워질 수 있다. 본 챕터에서는 다양한 디자인 패턴을 이용해 변하는 것(핵심 기능)과 변하지 않는 것(부가 기능)을 분리하는 사례를 살펴보려고 한다.
 
 

1. 템플릿 메서드 패턴

1) 템플릿 메서드 패턴 정의

템플릿 메서드 패턴 구조

템플릿 메서드 패턴(Template Method Pattern)이란 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다. 이렇게 하면 자식 클래스가 알고리즘 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 즉, 다형성으로 문제를 해결하는 것이다. 쉽게 말해 템플릿 메서드 패턴이란 기준이 되는 거대한 틀인 템플릿에 변하지 않는 부분을 넣고, 변하지 않는 일부를 별도로 호출하는 패턴을 의미한다. 
 

2) 템플릿 메서드 패턴 예제

아래는 템플릿 메서드 패턴을 구현한 예제다. 변하지 않는 로직(execute)과 변하는 로직(call)로 분리했으며, 특히 변하는 로직은 추상 메서드로 선언되어 자식 클래스에서 오버라이딩하도록 되어 있다.
 

템플릿 메서드 패턴 구조2

 
AbstractTemplate

@Slf4j
public abstract class AbstractTemplate {

    public void execute() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        call(); //상속
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

    protected abstract void call(); //하위 클래스에서 오버라이딩한다
}

 
AbstractTemplate을 상속하는 SubClassLogic1과 SubClassLogic2 (call을 오버라이딩)

@Slf4j
public class SubClassLogic1 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("비즈니스 로직1 실행");
    }
}

@Slf4j
public class SubClassLogic2 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("비즈니스 로직2 실행");
    }
}

 
실제 메서드가 호출되는 과정은 다음과 같다. 먼저 클라이언트가 execute()를 호출하면 템플릿 로직인 AbstractTemplate.execute()가 실행된다. execute() 내부에선 call() 메서드를 호출하는데, 이 부분이 오버라이딩 되어있으므로 현재 인스턴스의 call() 메서드가 호출된다. 템플릿 메서드 패턴은 이렇게 다형성을 이용해 변하는 부분과 변하지 않는 부분을 분리한다.
 

템플릿 메서드 패턴 실행 과정

 
템플릿 메서드 패턴은 SubClassLogic1, SubClassLogic2처럼 클래스를 계속 만들어야 하는 단점이 있는데, 익명 내부 클래스를 사용하면 이런 단점을 보완할 수 있다. 익명 내부 클래스를 사용하면 인스턴스를 생성함과 동시에 생성할 클래스를 상속 받은 자식 클래스의 인스턴스를 정의할 수 있다.

@Test
void templateMethodV2() {
    AbstractTemplate template1 = new AbstractTemplate() {
        @Override
        protected void call() {
            log.info("비즈니스 로직1 실행");
        }
    };
    log.info("클래스 이름1={}", template1.getClass());
    template1.execute();

    AbstractTemplate template2 = new AbstractTemplate() {
        @Override
        protected void call() {
            log.info("비즈니스 로직2 실행");
        }
    };
    log.info("클래스 이름2={}", template2.getClass());
    template2.execute();
}

 

2) 템플릿 메서드 패턴 단점

템플릿 메서드 패턴을 사용하면 기존 구조가 갖고 있던 문제(핵심 기능과 부가 기능이 강결합)를 효과적으로 해결할 수 있지만, 근본적인 문제가 남아있다. 템플릿 메서드 패턴은 상속을 강요함으로써 자식 클래스가 부모 클래스를 의존하게 만든다. 즉, 상속이 갖고 있는 문제를 그대로 갖고 있는 것이다. (상속의 문제점에 대한 자세한 내용은 이펙티브 자바 아이템 18과 아이템 19을 참고하자)
 
결국 자식 클래스에서 부모 클래스의 기능을 사용하지 않더라도 부모 클래스의 변경에 따른 영향을 받게된다. 게다가 템플릿 메서드 패턴은 상속을 위해 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부담도 있다. 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴이다
 
 

2. 전략 패턴 

1) 전략 패턴 정의

전략 패턴 구조

템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 이용해서 문제를 해결했다. 전략 패턴(Strategy Pattern)은 변하지 않는 부분을 Context라는 곳에 두고 변하는 부분을 Strategy라는 인터페이스에 두어 이를 구현하는 패턴이다. 즉, 상속이 아닌 위임(구성)으로 문제를 해결한다.
 

2) 전략 패턴 예제1 - 필드에 전략을 보관하는 방식

전략 패턴에서 Context(컨텍스트, 문맥)는 변하지 않는 템플릿 역할을 하고, Strategy(전략)는 변하는 알고리즘 역할을 한다. 쉽게 말해서 컨텍스트는 크게 변하지 않지만, 그 문맥 속에서 일부 전략이 변경된다고 할 수 있다.
 
Strategy (변하는 알고리즘 역할)

public interface Strategy {
    void call();
}

 
Strategy를 구현하는 StrategyLogic1과 StrategyLogic2

@Slf4j
public class StrategyLogic1 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직1 실행");
    }
}

@Slf4j
public class StrategyLogic2 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직2 실행");
    }
}

 
 
ContextV1 (변하지 않는 템플릿 역할)

/**
 * 필드에 전략을 보관하는 방식
 */
@Slf4j
public class ContextV1 {

    private Strategy strategy;

    public ContextV1(Strategy strategy) {
        this.strategy = strategy;
    }

    public void execute() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        strategy.call();
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

 
 
ContextV1은 내부에 Strategy 타입의 필드를 가지고 있다. 이로써 필드에 변하는 부분인 Strategy의 구현체를 주입할 수 있게 된다. 위 코드전략 패턴의 핵심은 Context가 Strategy 인터페이스에만 의존하므로 Strategy의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다는 것이다. 스프링의 의존관계 주입이 바로 이 전략패턴을 따른다. 참고로 Strategy가 하나의 메서드만 갖고 있는 함수형 인터페이스이기 때문에 Context의 생성자에 익명 내부 클래스는 물론, 람다를 인수로 넘길 수도 있다.

/**
 * 스프링의 의존관계 주입과 유사한 방식
 */
@Test
void strategyV1() {
    StrategyLogic1 strategyLogic1 = new StrategyLogic1();
    ContextV1 contextV1 = new ContextV1(strategyLogic1); // 익명 내부 클래스나 람다 가능
    contextV1.execute();

    StrategyLogic2 strategyLogic2 = new StrategyLogic2();
    ContextV1 contextV2 = new ContextV1(strategyLogic2); // 익명 내부 클래스나 람다 가능
    contextV2.execute();
}

 
 
코드를 보면 의존관계 주입을 통해 ContextV1에 Strategy의 구현체인 strategyLogic이 주입되고, context.execute()를 호출해서 context를 실행하는 것을 볼 수 있다.

필드에 전략을 보관하는 전략 패턴의 실행 과정

 

3) 필드에 전략을 보관하는 방식의 특징 - 선 조립 후 실행

Context의 내부 필드에 Strategy를 두고 사용하는 방식은 Context와 Strategy를 먼저 조립해두고, 그 다음에 Context를 실행하는 선 조립 후 실행 방식에서 매우 유용하다. 컨텍스트와 전략을 한 번 조립하고 나면 이후로는 컨텍스트를 실행하기만 하면 된다. 이 방식은 스프링에서 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음 요청을 처리하는 것과 같은 원리이다.
 
물론 컨텍스트와 전략을 조립한 이후에는 전략을 변경하기가 번거롭다는 점이 단점 또한 존재한다. 컨텍스트의 setter를 제공해서 전략을 변경할 수 있지만, 컨텍스트를 싱글톤으로 사용하는 상황에선 동시성 이슈 등 고려할 점이 많다. 따라서 전략을 실시간으로 변경해야 하면 컨테스트를 하나 더 생성하고 다른 전략을 주입하는 것이 더 나을 수 있다. 더욱 유연하게 전략을 교체할 수 있는 방법을 고려해보자.

StrategyLogic1 strategyLogic1 = new StrategyLogic1();
ContextV1 contextV1 = new ContextV1(strategyLogic1);
contextV1.execute();

StrategyLogic2 strategyLogic2 = new StrategyLogic2();
ContextV1 contextV2 = new ContextV1(strategyLogic2);
contextV2.execute();

 
 

4) 전략패턴 2 - 전략을 파라미터로 전달받는 방식

이 방식은 선 조립 후 실행하는 방식이 아니라 Context를 실행할 때마다 전략을 인수로 전달하는 방식이다. 클라이언트는 컨텍스트를 원하는 시점에 전략을 전달할 수 있으므로 기존 방식보다 원하는 전략을 더욱 유연하게 변경할 수 있다.
 
ContextV2

/**
 * 전략을 파라미터로 전달받는 방식
 */
@Slf4j
public class ContextV2 {

    public void execute(Strategy strategy) {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        strategy.call(); //위임
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

 
하나의 Context만 생성한 후, 실행 시점에 여러 전략을 인수로 전달해서 유연하게 실행하는 것을 확인할 수 있다.

@Test
void strategyV1() {
    ContextV2 contextV2 = new ContextV2();
    contextV2.execute(new StrategyLogic1());
    contextV2.execute(new StrategyLogic2());
}

 

전략을 파라미터로 전달받는 전략 패턴의 실행 과정

 

5) 전략패턴 정리

• 필드에 Strategy를 저장하는 방식으로 전략 패턴을 구현하기 - ContextV1
  • 스프링과 같은 선 조립 후 실행 방식에 적합
  • 전략이 변경될 필요가 없는 케이스에 적합
• 파라미터에 Strategy를 저장하는 방식으로 전략 패턴을 구현하기 - ContextV2
  • 실행할 때마다 전략을 유연하게 변경 가능
  • 반대로 실행할 때마다 전략을 계속 지정해주어야 한다는 부분이 번거로울 수 있다

 
 

3. 템플릿 콜백 패턴

1) 콜백이란?

ContextV2는 변하지 않는 템플릿 역할을 하고, 변하는 부분은 파라미터로 넘어온 Strategy의 코드를 실행해서 처리한다. 이렇게 다른 코드의 인수로 넘겨주는 실행 가능한 코드를 콜백(callback)이라고 한다. 쉽게 말해서 callback은 코드의 호출(call)이 코드를 넘겨준 곳의 뒤(back)에서 이뤄지는 것이다.
 

2) 템플릿 콜백 패턴 정의

스프링에서는 ContextV2와 같은 방식의 전략 패턴을 템플릿 콜백 패턴(Template Callback Pattern)이라고 한다. 전략 패턴에서 Context가 템플릿 역할을 하고 Strategy 부분이 콜백으로 넘어온다고 생각하면 된다. 참고로 템플릿 콜백 패턴은 GOF 패턴은 아니며, 스프링 내부에서 흔히 사용되는 방식이므로 스프링 안에서만 이렇게 부르며, 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이다.
 
스프링에서는 JdbcTemplate, RestTemplate, TransactionTemplate, RedisTemplate처럼 다양한 탬플릿 콜백 패턴이 사용된다. 스프링에서 이름의 접미사로 '-Template'이 붙어있다면 템플릿 콜백 패턴으로 구현되어 있다고 생각하면 된다.
 

3) 템플릿 콜백 패턴 예제

TimeLogTemplate (변하지 않는 템플릿 역할)

@Slf4j
public class TimeLogTemplate {

    public void execute(Callback callback) {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        callback.call(); //위임
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

 

 
Callback (변하지 않는 알고리즘 역할)

public interface Callback {
    void call();
}

 
별도의 클래스를 만들어서 전달해도 되지만, 콜백을 사용할 경우 익명 내부 클래스나 람다를 사용하는 것이 편리하다. 재사용을 위해 콜백을 별도의 클래스로 만들어도 된다.

@Test
void callbackV2() {
    TimeLogTemplate template = new TimeLogTemplate();
    template.execute(() -> log.info("비즈니스 로직1 실행"));
    template.execute(() -> log.info("비즈니스 로직2 실행"));
}

 
아래 두 개의 그림을 보면 알 수 있겠지만, 이름만 다를 뿐 실제로는 전략을 파라미터로 전달받는 전략 패턴과 동일하다.

템플릿 콜백 패턴의 실행 과정

전략을 파라미터로 전달받는 전략 패턴의 실행 과정