[Spring AOP] 템플릿 메서드 패턴과 콜백 패턴

템플릿 메서드 패턴과 콜백 패턴

#Spring/고급

템플릿 메서드 패턴 - 도입 배경

이전 챕터에서는, 로그 추적기를 사용하기 위해 메서드 시그니처를 변경하는 것의 문제를 ThreadLocal을 통해 해결하였다.
그런데 로그 추적기를 막상 프로젝트에 도입하려고 하니 문제점이 보인다.

1~2줄짜리 비즈니스 로직이, 로그 추적기라는 부가 기능 때문에 코드가 엄청 늘어났다.

//OrderControllerV0 코드
@GetMapping("/v0/request")
public String request(String itemId) {
    orderService.orderItem(itemId);
    return "ok";
}

//OrderControllerV3 코드
@GetMapping("/v3/request")
public String request(String itemId) {
    TraceStatus status = null;
    try {
        status = trace.begin("OrderController.request()");
        orderService.orderItem(itemId); //핵심 기능
        trace.end(status);
    } catch (Exception e) {
        trace.exception(status, e);
        throw e;
    }
    return "ok";
}

V0는 해당 메서드가 실제 처리해야 하는 핵심 기능만 깔끔하게 남아있다. 반면에 V3에는 핵심 기능보다 로그를 출력해야 하는 부가 기능 코드가 훨씬 더 많고 복잡하다. (부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다. ex. 로그 추적, 트랜잭션)
심지어 핵심 기능을 위한 코드보다 부가 기능을 위한 코드가 더 많다. 이 문제를 해결할 방법을 찾아보자.

V3 코드를 유심히 잘 살펴보면 다음과 같이 동일한 패턴이 있다.

TraceStatus status = null;
try {
    status = trace.begin("message");
    //핵심 기능 호출
    trace.end(status);
} catch (Exception e) {
    trace.exception(status, e);
    throw e;
}

Controller, Service, Repository의 코드를 잘 보면, 로그 추적기를 사용하는 구조는 모두 동일하다. 중간에 핵심 기능을 사용하는 코드만 다를 뿐이다.
try-catch 내부에 핵심 로직이 들어가있어, 변하지 않는 부분을 메서드로 분리해내는 것은 어렵다.

물론, 나는 람다를 열심히 공부했기 때문에, 핵심 기능 코드 조각을 람다로 전달하면 이 문제를 해결할 수 있겠다라는 생각을 바로 하였지만, 람다의 등장 배경을 공부했던 것처럼, 설계의 원칙부터 살펴보자.

변하는 것과 변하지 않는 것을 분리
좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이다.
여기서 핵심 기능 부분은 변하고, 로그 추적기를 사용하는 부분은 변하지 않는 부분이다. 이 둘을 어떻게 분리할까?

템플릿 메서드 패턴(Template Method Pattern)은 이런 문제를 해결하는 디자인 패턴이다.

템플릿 메서드 패턴

예제 1

@Slf4j
public class TemplateMethodTest {

    @Test
    void templateMethodV0() {
        logic1();
        logic2();
    }

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

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

• 변하는 부분: 비즈니스 로직
• 변하지 않는 부분: 시간 측정

이제 템플릿 메서드 패턴을 사용해서 변하는 부분과 변하지 않는 부분을 분리해보자.

예제2

추상 클래스 내부에서 변하지 않는 부분은 구현하고, 변하지 않는 부분 내의 변하는 부분(비즈니스 로직)을 추상 메서드로 분리한다.
이 추상 클래스를 상속하여 구체적인 비즈니스 로직을 구현하는 것이다.

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

템플릿 메서드 패턴은 이름 그대로 템플릿을 사용하는 방식이다. 템플릿은 기준이 되는 거대한 틀이다. 템플릿이라는 틀에 변하지 않는 부분을 몰아둔다. 그리고 일부 변하는 부분을 별도로 호출해서 해결한다.

@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 실행");
    }
}

템플릿 메서드 패턴 적용

@Test
void templateMethodV1() {
    AbstractTemplate template1 = new SubClassLogic1();
    template1.execute();

    AbstractTemplate template2 = new SubClassLogic2();
    template2.execute();
}

예제3: 익명 클래스

템플릿 메서드 패턴은 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();
}

로그 추적기 프로젝트에 적용

public abstract class AbstractTemplate<T> {

    private final LogTrace trace;

    public AbstractTemplate(LogTrace trace) {
        this.trace = trace;
    }

    public T execute(String message) {
        TraceStatus status = null;
        try {
            status = trace.begin(message);

            //로직 호출
            T result = call();

            trace.end(status);
            return result;
        } catch (Exception e) {
            trace.exception(status, e);
            throw e;
        }
    }

    protected abstract T call();
}

• AbstractTemplate은 템플릿 메서드 패턴에서 부모 클래스이고, 템플릿 역할을 한다.
• <T> 제네릭을 사용했다. 반환 타입을 정의한다.
• 템플릿 코드 중간에 call() 메서드를 통해서 변하는 부분을 처리한다.
• abstract T call()은 변하는 부분을 처리하는 메서드이다. 이 부분은 상속으로 구현해야 한다.

@RestController
@RequiredArgsConstructor
public class OrderControllerV4 {

    private final OrderServiceV4 orderService;
    private final LogTrace trace;

    @GetMapping("/v4/request")
    public String request(String itemId) {
        AbstractTemplate<String> template = new AbstractTemplate<>(trace) {
            @Override
            protected String call() {
                orderService.orderItem(itemId);
                return "ok";
            }
        };
        return template.execute("OrderController.request()");
    }
}

@Service
@RequiredArgsConstructor
public class OrderServiceV4 {

    private final OrderRepositoryV4 orderRepository;
    private final LogTrace trace;

    public void orderItem(String itemId) {
        AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
            @Override
            protected Void call() {
                orderRepository.save(itemId);
                return null;
            }
        };
        template.execute("OrderService.orderItem()");
    }
}

• AbstractTemplate<Void>
  • 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면 Void 타입을 사용하고 null을 반환하면 된다.

v0, v3, v4 비교

• OrderServiceV0: 핵심 기능만 있다.
• OrderServiceV3: 핵심 기능과 부가 기능이 함께 섞여 있다.
• OrderServiceV4: 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다.

V4는 템플릿 메서드 패턴을 사용한 덕분에 핵심 기능에 좀 더 집중할 수 있게 되었다.

진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자. 그래서 AbstractTemplate 코드를 변경해야 한다 가정해보자. 단순히 AbstractTemplate 코드만 변경하면 된다.

단일 책임 원칙(SRP)
소스 코드를 줄이는 것 뿐만 아니라, 로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다. 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.

템플릿 메서드 패턴의 정의 - GOF 디자인 패턴

GOF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의했다.

템플릿 메서드 디자인 패턴의 목적은 다음과 같습니다.

"작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다." [gof]

부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다. 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.

하지만, 템플릿 메서드 패턴은 상속에서 오는 단점을 그대로 안고 간다. 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 상속을 받는 다는 것은 특정 부모 클래스를 의존하고 있다는 것이다. 자식 클래스가 부모 클래스의 영향을 받는다.

자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야한다. 이것은 좋은 설계가 아니다.

추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다.
더 깔끔하게 개선하려면 어떻게 해야할까? 전략 패턴의 등장

전략 패턴

탬플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결했다.
전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다.
상속이 아니라 위임으로 문제를 해결하는 것이다!!!

GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.

알고리즘 제품군(Strategy들)을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

예제 1

public interface Strategy {
    void call();
}

이 인터페이스는 변하는 알고리즘 역할을 한다.

@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 실행");
    }
}

변하는 알고리즘은 Strategy 인터페이스를 구현하면 된다.

/**
 * 필드에 전략을 보관하는 방식
 */
@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를 통해 일부 전략이 변경된다 생각하면 된다.

전략 패턴의 핵심은 Context는 Strategy 인터페이스에만 의존한다는 점이다. 덕분에 Strategy의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.
스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴이다.

@Test
void strategyV1() {
    Strategy strategyLogic1 = new StrategyLogic1();
    ContextV1 context1 = new ContextV1(strategyLogic1);
    context1.execute();

    Strategy strategyLogic2 = new StrategyLogic2();
    ContextV1 context2 = new ContextV1(strategyLogic2);
    context2.execute();
}

이렇게 원하는 모양(전략)으로 조립을 완료하고 난 다음에 context1.execute()를 호출해서 context를 실행한다.

예제2: 익명 클래스 사용 가능, 람다도 사용 가능

비즈니스 로직을 위해서 클래스 만드는거 귀찮음 익명 클래스 사용 가능. 인터페이스에 정의된 메서드 1개 람다 사용 가능

/**
 * 전략 패턴, 람다
 */
@Test
void strategyV4() {
    ContextV1 context1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
    context1.execute();

    ContextV1 context2 = new ContextV1(() -> log.info("비즈니스 로직2 실행"));
    context2.execute();
}

여기서 이야기하고 싶은 부분은 Context의 내부 필드에 Strategy를 두고 사용하는 부분이다. 이 방식은 Context와 Strategy를 실행 전에 원하는 모양으로 조립해두고(ex. 어떤 전략을 넣을건지), 그 다음에 Context를 실행하는 선 조립, 후 실행 방식에서 매우 유용하다.

이 방식의 단점은 Context와 Strategy를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다. 물론 Context에 setter를 제공해서 Strategy를 넘겨 받아 변경하면 되지만, Context를 싱글톤으로 사용할 때는 동시성 이슈 등 고려할 점이 많다.

이렇게 먼저 조립하고 사용하는 방식보다 더 유연하게 전략 패턴을 사용하는 방법은 없을까?

예제3: 직접 파라미터로 전달

전략을 실행할 때 직접 파라미터로 전달해서 사용해보자.

@Slf4j
public class ContextV2 {

    // V1에서 필드 삭제 후, 파라미터로 Strategy 받도록 변경

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

@Slf4j
public class ContextV2Test {
    /**
     * 전략 패턴 적용
     */
    @Test
    void strategyV1() {
        ContextV2 context = new ContextV2();
        context.execute(new StrategyLogic1());
        context.execute(new StrategyLogic2());
    }

    // 람다
    @Test
    void strategyV3() {
           ContextV2 context = new ContextV2();
            context.execute(() -> log.info("비즈니스 로직1 실행"));
            context.execute(() -> log.info("비즈니스 로직2 실행"));
    }
}

Context와 Strategy를 '선 조립 후 실행'하는 방식이 아니라 Context를 실행할 때 마다 전략을 인수로 전달한다.
클라이언트는 Context를 실행하는 시점에 원하는 Strategy를 전달할 수 있다. 따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연하게 변경할 수 있다.

정리

• ContextV1은 필드에 Strategy를 저장하는 방식으로 전략 패턴을 구사했다.
  • 선 조립, 후 실행 방법에 적합하다.
  • Context를 실행하는 시점에는 이미 조립이 끝났기 때문에 전략을 신경쓰지 않고 단순히 실행만 하면 된다.
• ContextV2는 파라미터에 Strategy를 전달받는 방식으로 전략 패턴을 구사했다.
  • 실행할 때 마다 전략을 유연하게 변경할 수 있다.
  • 단점 역시 실행할 때 마다 전략을 계속 지정해주어야 한다는 점이다.

우리 예제에서는 어떤 방법이 더 적합할까?
지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립, 후 실행이 아니다. 단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐이다.
따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2가 더 적합하다.

영한님은 디자인 패턴에서 중요한 것은 위에서 본 그림도 맞지만, 의도도 중요하다고 강조한다. 디자인 패턴이 다 비슷비슷한데, 어떤 패턴을 선택하는지는 의도로 구분하므로 의도의 중요성도 강조한다.
이 예제에서는 멤버 변수로 전략을 가지고 있어도 이 의도를 해결할 수 있고, 파라미터를 사용해도 이 의도를 해결할 수 있다. 두 방식 모두 전략 패턴이라고 볼 수 있다.

템플릿 콜백 패턴

ContextV2는 변하지 않는 템플릿 역할을 한다. 그리고 변하는 부분은 파라미터로 넘어온 Strategy의 코드를 실행해서 처리한다. 이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백(callback)이라 한다.

콜백 정의

프로그래밍에서 콜백(callback) 또는 콜애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다. (위키백과 참고)

쉽게 이야기해서 callback은 코드가 호출(call)은 되는데 코드를 넘겨준 곳의 뒤(back)에서 실행된다는 뜻이다. (Strategy 코드를 Context로 던졌다. Strategy 코드가 뒤에서 실행된다고 해서 call back 이다)

• ContextV2 예제에서 콜백은 Strategy이다.

자바 언어에서 콜백

• 자바 언어에서 실행 가능한 코드를 인수로 넘기려면 객체가 필요하다. 자바8부터는 람다를 사용할 수 있다.

템플릿 콜백 패턴

• 스프링에서는 ContextV2와 같은 방식의 전략 패턴을 템플릿 콜백 패턴이라 한다. 전략 패턴에서 Context가 템플릿 역할을 하고, Strategy 부분이 콜백으로 넘어온다 생각하면 된다.
• 참고로 템플릿 콜백 패턴은 GOF 패턴은 아니고, 스프링 내부에서 이런 방식을 자주 사용하기 때문에, 스프링 안에서만 이렇게 부른다. 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이라 생각하면 된다.
• 스프링에서는 JdbcTemplate, RestTemplate, TransactionTemplate, RedisTemplate처럼 다양한 템플릿 콜백 패턴이 사용된다. 스프링에서 이름에 XxxTemplate가 있다면 템플릿 콜백 패턴으로 만들어져 있다 생각하면 된다.

템플릿 콜백 패턴 - 적용

로그 추적기 예제에 템플릿 콜백 패턴을 적용해보자!
TraceCallback 인터페이스

package hello.advanced.trace.callback;

public interface TraceCallback<T> {
    T call();
}

TraceTemplate

package hello.advanced.trace.callback;

import hello.advanced.trace.TraceStatus;
import hello.advanced.trace.logtrace.LogTrace;

public class TraceTemplate {

    private final LogTrace trace;

    public TraceTemplate(LogTrace trace) {
        this.trace = trace;
    }

    public <T> T execute(String message, TraceCallback<T> callback) {
        TraceStatus status = null;
        try {
            status = trace.begin(message);

            //로직 호출
            T result = callback.call();

            trace.end(status);
            return result;
        } catch (Exception e) {
            trace.exception(status, e);
            throw e;
        }
    }
}

• TraceTemplate는 템플릿 역할을 한다.
• execute(..)를 보면 message 데이터와 콜백인 TraceCallback callback을 전달 받는다

Service 클래스 예시

@Service
public class OrderServiceV5 {

    private final OrderRepositoryV5 orderRepository;
    private final TraceTemplate template;

    public OrderServiceV5(OrderRepositoryV5 orderRepository, LogTrace trace) {
        this.orderRepository = orderRepository;
        this.template = new TraceTemplate(trace);
    }

    public void orderItem(String itemId) {
        template.execute("OrderService.orderItem()", () -> {
            orderRepository.save(itemId);
            return null;
        });
    }
}

• this.template = new TraceTemplate(trace): trace 의존관계 주입을 받으면서 필요한 TraceTemplate 템플릿을 생성한다. 참고로 TraceTemplate를 처음부터 스프링 빈으로 등록하고 주입받아도 된다. 이 부분은 선택이다.
  • 이 예제처럼 하면 테스트코드 할 때 편하다는 장점이 있다고 한다.
• template.execute()를 실행하면서 템플릿을 실행하면서 콜백을 전달한다.

정리
이번 챕터에서는 변하는 코드와 변하지 않는 코드를 분리하고, 더 적은 코드로 로그 추적기를 적용하기 위해

• 템플릿 메서드 패턴
• 전략 패턴
• 템플릿 콜백 패턴

을 적용해봤다. 최종적으로 템플릿 콜백 패턴을 적용하고 콜백으로 람다를 사용해서 코드 사용도 최소화 할 수 있었다.

한계
아무리 최적화를 해도 결국 로그 추적기를 적용하기 위해서 원본 코드를 수정해야 한다는 점이다.
원본 코드를 손대지 않고 로그 추적기를 적용할 수 있는 방법이 있을까? 다음 챕터에서(프록시 패턴)

Ref) 스프링 핵심 원리 - 고급편 강의 | 김영한 - 인프런