[Spring] 예제로 알아보는 [ 템플릿 메서드 패턴 ]

템플릿 메서드 패턴 - 사전적 정의 / 목적

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

이게 무슨 소리인가~ 알아보기 위해 스프링 예제 코드로 템플릿 메서드 패턴을 알아보겠다.

 

 

 

중복되는 로직의 반복

아래 코드는 컨트롤러의 request 메서드에 trace 라는 로그를 삽입한 코드다. 

핵심 로직은 orderService.orderItem(itemId) 와 return "ok" 부분이 전부인데, 로그 트래킹을 하면서 부가적인 try ~ catch 구문이 붙어 코드가 비교적 지저분해 보인다.

@RestController
@RequiredArgsConstructor
public class OrderControllerV3 {

    @GetMapping("/v3/request")
    public String request(String itemId) {
        TraceStatus status = null;
        try {
            status = trace.begin("OrderControllerV3.request()");
            orderService.orderItem(itemId);
            trace.end(status);
            return "ok";
        } catch (Exception e) {
            trace.exception(status, e);
            throw e; // 예외르 꼭 다시 던져주어야 한다.
        }
    }
}

만약 프로젝트 전체 코드에 로그 트래킹을 해야한다고 가정하자. 모든 컨트롤러와 서비스 레이어, 레포지토리 레이어의 메서드에 로그 트래킹을 위해, 위처럼 try ~ catch 구문을 달아야 하는 것은 개발자스럽지 못한 처사다. 

 

베스트 프랙티스는 물론 AOP 를 사용한 로그 트래커 삽입이겠지만, 우선 템플릿 메서드 패턴을 도입하여 위 코드를 어떻게 변경시킬 수 있는지 먼저 알아보자. 그 후엔 차례대로 전략 패턴과 템플릿 콜백 패턴을 적용하면서 더 나은 설계로 변경 시켜보겠다.

 

 

변하는 것과 변하지 않는 것을 분리 

좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이다. 위 코드에서 변하는 부분은 핵심로직인 service 레이어를 호출하는 부분이고, 변하지 않는 부분은 try ~ catch 구문과 trace.begin() 로그 트래킹 부분이다. 변하지 않는 부분을 템플릿화 하여 공통 요소로 뺄 수 있다면, 그리하여 해당 템플릿을 필요할 때만 호출하는 방법을 생각해보자. 

 

 

템플릿 메서드 패턴 - 예제

템플릿 메서드 패턴은 이름 그대로 템플릿을 만들어 사용하는 방식으로, 템플릿이라는 틀에 위에서 언급한 변하지 않는 부분을 몰아둔다. 그리고 변하는 부분인, 핵심 로직은 별도로 호출하도록 설계 해보자. 아래 코드에서는 변하지 않는 부분을 execute() 메서드에 구현했고, 변하는 부분은 별도로 호출할 수 있도록 (아직 정의되지 않은) 추상 메서드로 선언해두었다. 이를 구성하는 클래스가 템플릿이 되는 것이다.

// AbstractTemplate.class
@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();
}

그리고 변하는 부분인 (비즈니스 로직1, 2를 처리하는) 자식 클래스를 SubClassLogic1, SubClassLogic2 으로 정의한다. 이 때 템플릿의 추상메서드인 call() 메서드를 오버라이딩 한다. 그리하여 오버라이딩 된 메서드가 호출된다.

// SubClassLogic1.class
@Slf4j
public class SubClassLogic1 extends AbstractTemplate {

    @Override
    protected void call() {
        log.info("비즈니스 로직 1 실행");
    }
}


// SubClassLogic2.class
@Slf4j
public class SubClassLogic2 extends AbstractTemplate {

    @Override
    protected void call() {
        log.info("비즈니스 로직 2 실행");
    }
}

SubClassLogic1, 2 클래스가 AbstractTemplate 이라는 추상 클래스를 상속 받는 것을 볼 수 있다.

자식 클래스인 SubClassLogic1, 2 는 자연스럽게 추상메서드인 call() 메서드를 오버라이드 하고,

이 때 자신만의 핵심 로직(변하는 부분)을 call() 메서드에 구현한다.

 

다형성이 적용되면서, 자식 클래스인 SubClassLogic1, 2 의 인스턴스는 AbstractTemplate 의 타입을 지니며 동시에 execute() 메서드를 호출할 수 있다. execute() 메서드가 호출되면서 그 내부에 선언된 call() 메서드가 실행되어, 자식 클래스에서 오버라이드 해 둔 코드가 실행된다.

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

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

결국 템플릿 메서드 패턴은, 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 별도로 정의하는 것이다. 그리하여 자식 클래스가 알고리즘 전체의 골격을 변경하지 않고, 특정 부분만 재정의 할 수 있다. 즉 상속과 오버라이딩을 통한 다형성을 활용하여 문제를 해결하는 패턴인 것이다.

 

 

익명클래스 / 람다식을 이용한 템플릿 메서드 패턴

템플릿 메서드 패턴을 적용하여 핵심로직과 부가로직을 분리해냈지만, 위 코드는 매번 SubClassLogic 을 생성 해야하는 불편함이 있다. 이 점은 익명 클래스나 람다식을 이용해 간소화 할 수 있다.

@Test
void templateMethodV2() {

    // 익명 클래스 사용
    AbstractTemplate template = new AbstractTemplate() {
        @Override
        protected void call() {
            log.info("비즈니스 로직1 실행");
        }
    };
    log.info("클래스이름1 = {}", template.getClass());
    template.execute();
	
    // 람다식 사용
    AbstractTemplate template2 = { log.info("비즈니스 로직2 실행"); };
    log.info("클래스이름2 = {}", template2.getClass());
    template2.execute();
    
    // 복잡해보이지만, 별도의 SubClassLogic1 같은 별도의파일을 만들지 않아도 된다.
}

 

 

 

템플릿 메서드 패턴을 적용

이제 기존 코드에 템플릿 메서드 패턴을 적용해보자. 우선 템플릿이 될 AbstractTemplate 추상 클래스를 생성한다. 템플릿에는 우리가 부가 로직이라 여긴, 변하지 않는 부분에 해당되는 try ~ catch 코드를 삽입한다. 그리고 그 내부에 call() 추상 메서드를 선언하여, 자식 클래스에서 오버라이드 된 비즈니스로직이 실행되도록 하자. 

// 부모 역할 (= 템플릿)
public abstract class AbstractTemplate<T> {

    private final LogTrace trace;

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

    // type 생성 시점을 객체 생성시점으로 미룬다.
    public T execute(String message){
        TraceStatus status = null;
        try {
            status = trace.begin(message);

            // logic 호출
            T result = call();

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

    protected abstract T call();
}


@RestController
@RequiredArgsConstructor
public class OrderControllerV4 {
    private final OrderServiceV4 orderService;
    private final LogTrace trace;
    @GetMapping("/v4/request")
    public String request(String itemId) {
    
        // 여기에 log관련 코드를 모두 몰아넣고, 추상메서드 구현부에 핵심로직을 넣는다
        AbstractTemplate<String> template = new AbstractTemplate<>(trace) {
            @Override
            protected String call() {
                orderService.orderItem(itemId);
                return "ok";
            } };
        return template.execute("OrderController.request()");
    }
}

 

어떤가? 단순히 try ~ catch 구문만 extract 한 것이 아니라, 로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 코드를 짰다. 로그와 관련된 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 설계한 것이다 < template method pattern 의 장점 > . 이제 로그를 남기는 로직을 변경해야 하면, 모든 메서드에 흩뿌려진 코드를 일일이 수정하지 않고 템플릿 코드만 수정하면 된다.

 

템플릿 메서드의 한계

앞서 설명한대로, 템플릿 메서드 패턴은 상속과 오버라이딩, 다형성의 특징을 이용하여 문제를 해결한다. 하지만 상속보다는 컴포지션을 활용하라는 말이 있듯이, 상속으로 인해 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 존재한다. 자식 클래스의 입장에서는 call() 이라는 추상메서드만 오버라이딩 할 뿐 부모 클래스의 기능을 전혀 사용하지 않은 채 상속만 받고 있는 상황이다. 

 

상속을 받는 것은, 자식 클래스가 부모 클래스를 의존한다는 의미이며, 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀있다는 의미이기도 하다. 이게 왜 좋지 못한 상황일까? 의존의 대상이 되는 클래스가 변경되면 의존하는 클래스도 변경의 영향을 받기 때문이다.

 

그렇다면 상속의 단점을 제거하면서, 위의 문제를 해결할 수 있는 방법은 없을까? 바로 상속이 아닌 위임을 활용하면 된다. 이를 활용할 수 있는 전략 패턴을 다음 포스팅에서 서술해보겠다.

 

 

 

코드 및 자료 출처 :https://inf.run/5BUY

스프링 핵심 원리 - 고급편 - 인프런 | 강의