[스프링 핵심원리 - 고급편] #3. 템플릿 메서드

[YONGHYNG]

템프릿 메서드 패턴 - 시작

• 템플릿 메서드 패턴은 상위 클래스에서 기본적인 알고리즘의 흐름(템플릿) 을 정의하고, 세부 동작은 하위 클래스에서 구현하도록 하는 디자인 패턴
• 상위 클래스(추상 클래스) → 전체적인 로직의 틀(템플릿)을 제공
• 하위 클래스(구체 클래스) → 세부 동작을 직접 구현

로그 추적기 도입 전 - V0코드

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

//OrderServiceV0 코드
public void orderItem(String itemId) {
        orderRepository.save(itemId);
}

• /v0/request 라우트로 HTTP 요청이 들어옴
• orderService.orderItem(itemId); 를 호출
• 서비스 (OrderServiceV0) → orderItem()을 실행하고 저장소에 저장

로그 추적기 도입 후 - V3 코드

//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 (Exeption e) {
        trace.exception(status, e);
        throw e;
    }
    return "ok";
}

변경된 점:

- trace로 로그를 추적
- trace.begin("OrderService.orderItem()") → 서비스 시작 시 로그 기록
- orderRepository.save(itemId); → 저장소에 아이템 저장 (핵심 로직)
- trace.end(status); → 서비스 정상 종료 로그 기록
- 예외 발생 시 trace.exception(status, e); → 예외 발생 로그 기록

//OrderServiceV3 코드
public void orderItem(String itemId) {
    TraceStatus status = null;
    try {
        status = trace.begin("OrderService.orderItem()");
        orderRepository.save(itemId); //핵심
        trace.end(status);
    } catch (Exception e){
        trace.exception(status, e);
        throw e;
    }
}

변경된 점:

- trace.begin("OrderService.orderItem()") → 서비스 시작 시 로그 기록
- orderRepository.save(itemId); → 저장소에 아이템 저장 (핵심 로직)
- trace.end(status); → 서비스 정상 종료 로그 기록
- 예외 발생 시 trace.exception(status, e); → 예외 발생 로그 기록

• V0 시절 코드와 비교해서 V3 코드 비교
• V0 해당 메서드가 실제 처리해야 하는 핵심 기능만 깔끔하게 있음
• V3에는 핵심 기능보다 로그를 출력해야 하는 부가 기능 코드가 많고 복잡

핵심 기능 vs 부가 기능

• 핵심 기능은 해당 객체가 제공하는 고유 기능, 예를 들어서 orderService의 핵심 기능은 주문 로직
• 메서드 단위로 보면 orderService.orderItem()의 핵심 기능은 주문 데이터를 저장하기 위해 리포지토리를 호출하는 것이 핵심 기능은 주문 데이터를 저장하기 위해 리포지토리를 호출하는 orderRepository.save(itemId) 코드가 핵심 기능
• 부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능, 예) 로그 추적 로직, 트랜잭션 기능
• 이러한 부가 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용
• 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용, 즉 핵심 기능을 보조하기 위해 존재

동일한 패턴이 보임

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는 물론이고, 핵심 기능 부분이 중간에 있어서 단순하게 메서드 추출은 어려움

템플릿 메서드 패턴 - 예제1

TemplateMethodTest

package hello.advanced.trace.template;

import hello.advanced.trace.template.code.AbstractTemplate;
import hello.advanced.trace.template.code.SubClassLogic1;
import hello.advanced.trace.template.code.SubClassLogic2;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class TemplateMethodTest {

    @Test
    void templateMethodV0(){ //logic1()과 logic2()를 실행해서 비즈니스 로직을 수행
        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("비즈니스 로직1 실행");
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }  
}

• logic1()과 logic2()는 시간을 측정하는 부분과 비즈니스 로직을 실행하는 부분이 함께 존재
• 변하는 부분: 비즈니스 로직
• 변하지 않는 부분: 시간 측정

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

AbstractTemplate

package hello.advanced.trace.template.code;

import lombok.extern.slf4j.Slf4j;

@Slf4j
/**
* abstract(추상 클래스란)
* 직접 객체를 만들 수 없는 클래스
* 공통된 기능은 제공, 일부 기능은 자식 클래스에서 직접 구현해야 함

* abstract method(추상 메서드란?)
* 내용이 없는 메서드
* 자식 클래스에서 반드시 오버라이딩(재정의)해야 함

* 공통된 부분은 부모가 달리지는 부분은 자식
*/
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(); // 자식이 반드시 구현해야 하는 메서드
}

• 템플릿 메서드 패턴: 템플릿을 사용하는 방식, 템플릿은 기준이 되는 거대한 틀
• 템플릿이라는 틀에 변하지 않는 부분을 몰아두고, 일부 변하는 부분을 별로 호출해서 해결

SubClassLogic1

• 변하는 부분인 비즈니스 로직 1,2을 처리하는 자식 클래스, 템플릿이 호출하는 대상인 call() 메서드를 오버라이딩 함
• AbstractTemplate 코드를 보면, 변하지 않는 부분인 시간 측정 로직을 몰아둔 것을 확인, 이것이 이제 하나의 템플릿
• 그리고 템플릿 안에서 변하는 부분은 call() 메서드를 호출해서 처리
• 템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿 코드를 두고 변하는 부분은 자식 클래스에 두고 상속과 오버라이딩을 통해 처리함

package hello.advanced.trace.template.code;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class SubClassLogic1 extends AbstractTemplate {
                 @Override
                 protected void call() {
                 log.info("비즈니스 로직1 실행");
         }
}

SubClassLogic2

package hello.advanced.trace.template.code;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class SubClassLogic2 extends AbstractTemplate {
                 @Override
                 protected void call() {
                 log.info("비즈니스 로직2 실행");
         }
}

TemplateMethodTest - templateMethodV1() 추가

    /**
     * 템플릿 메서드 패턴 적용
     * */
    @Test 
    void templateMethodV1(){
        AbstractTemplate template1 = new SubClassLogic1();
        template1.execute();

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

실행 결과

비즈니스 로직1 실행
resultTime=0
비즈니스 로직2 실행
resultTime=1

• template1.execute()를 호출하면 템플릿 로직인 AbstractTemplate.execute()를 실행
• 중간 call() 메서드를 호출하면, 이 부분이 오버라이딩 되어 있음, 따라서 현재 인스턴스인 SubClassLogic1 인스턴스의 SubClassLogic1.call() 메서드가 호출 됨

템플릿 메서드 패턴은 이렇게 다형성을 사요으 변하는 부분과 변하지 않는 부분을 분리하는 방법

###템플릿 메서드 패턴 - 예제3

• 템플릿 메서드 패턴은 SubClassLogic1, SubClassLogic2 처럼 클래스를 계속 만들어야 하는 단점이 있음, 익명 내부 클래스를 사용하면 이런 단점 보완 가능
• 익명 내부 클래스를 사용하면 객체 인스턴스를 생성하면서 동시에 생성할 클래스를 상속 받은 자식 클래스 정의 가능, 이 클래스는 SubClassLogic1처럼 직접 지정하는 이름이 없고 클래스 내부에 선언되는 클래스여서 내부 클래스라 함

TemplateMethodTest - templateMethodV2() 추가

/**
 * 템플릿 메서드 패턴, 익명 내부 클래스 사용
 * */
@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("비즈니스 로직1 실행");
        }
    };
    log.info("클래스 이름2={}", template2.getClass());
    template2.execute();
}

• 실행 결과를 보면 임의로 만들어주는 익명 내부 클래스 이름은 TemplateMethodTest$1,
  TemplateMethodTest$2 확인 가능

###템플릿 메서드 패턴 - 적용1

AbstractTemplate

package hello.advanced.trace.template;

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

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) {
            throw e;
        }
    }
    
    protected abstract T call(); //부분을 처리하는 메서드, 상속으로 구현
}

• AbstractTemplate은 템플릿 메서드 패턴에서 부모 클래스, 템플릿 역할임
• 제네릭 사용, 반환 타입 정의
• 객체를 생성할 때 내부에서 사용할 LogTrace trace 전달 받음
• 로그에 출력할 message를 외부에서 파라미터로 잡음
• abstract T call()은 변하는 부분을 처리하는 메서드, 상속으로 구현

package hello.advanced.app.v4;

import hello.advanced.trace.TraceStatus;
import hello.advanced.trace.logtrace.LogTrace;
import hello.advanced.trace.template.AbstractTemplate;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

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

• AbstractTemplate : 제네릭을 String으로 설정, 따라서 AbstractTemplate의 반환 타입은 String이 됨
• 익명 내부 클래스 : 익명 내부 클래스를 사용, 객체를 생성하면서 AbstractTemplate를 상속받은 자식 클래스를 정의, 따라서 별도의 자식 클래스를 직접 만들지 않아도 됨
• template.execute("OrderController.request()") : 템플릿을 실행하면서 로그로 남길 message 전달

package hello.advanced.app.v4;


import hello.advanced.trace.logtrace.LogTrace;
import hello.advanced.trace.template.AbstractTemplate;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

@Repository
@RequiredArgsConstructor
public class OrderRepositoryV4 {

    private final LogTrace trace;

    public void save(String itemId) {
        //익명 내부 클래스로 구현하여 템플릿 메서드 패턴 적용
       //trace(로깅 객체)를 AbstractTemplate에 넘겨주어 트랜잭션 로그 관리를 자동으로 수행
        AbstractTemplate<Void> template = new AbstractTemplate<>(trace){
            @Override
            protected Void call() {
                //저장 로직
                if(itemId.equals("ex")) {
                    throw new IllegalStateException("예외 발생!");
                }
                sleep(1000);
                return null;
            }
        };
        template.execute("OrderRepository.save()");
    }
    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e){
            e.printStackTrace();
        }
    }
}

템플릿 메서드 패턴 - 적용2

• 템플릿 메서드 패턴 덕분에 변하는 코드와 변하지 않는 코드 명확하게 분리
• 로그를 출력하는 템플릿 역할을 하는 변하지 않는 코드는 AbstractTemplate에 담아두고, 변하는 코드는 자식 클래스를 만들어서 분리

지금까지 작성한 코드 비교

//OrderServiceV0 코드
public void orderItem(String itemId) {
       orderRepository.save(itemId);
}
//OrderServiceV3 코드
public void orderItem(String itemId) {
           TraceStatus status = null;
           try {
                   status = trace.begin("OrderService.orderItem()");
                   orderRepository.save(itemId); //핵심 기능
                   trace.end(status);
           } catch (Exception e) {
                   trace.exception(status, e);
                   throw e;
           }
}
//OrderServiceV4 코드
AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
       @Override
       protected Void call() {
             orderRepository.save(itemId);
             return null;
       }
};
template.execute("OrderService.orderItem()");

• OrderServiceV0: 핵심 기능만 있음
• OrderServiceV3: 핵심 기능과 부가 기능이 함께 섞임
• OrderServiceV4: 핵심 기능과 템플릿을 호출하는 코드가 섞임, V4는 템플릿 메서드 패턴을 사용한 덕분에 핵심 기능에 좀 더 집중할 수 있음

좋은 설계란?

• 진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러남
• 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했음
• 만약 로그를 남기는 로직을 변경해야 한다고 생각해보면, AbstractTemplate 코드를 변경해야 한다고 가정해 보면, 단순히 AbstractTemplate 코드만 변경하면 됨
• 템플릿이 없는 V3 상태에서 로그를 남기는 로직을 변경해야 한다고 생각해보자. 이 경우 모든 클래스를 다 찾아서 고쳐야 함, 클래스가 수백 개라면 생각만해도 끔찍

단일 책임 원칙(SRP)

• V4는 단순히 템플릿 메서드 패턴을 적용해서 소스코드 몇줄을 줄인 것이 전부가 아님
• 로그를 남기는 부분에 단일 책임 원칙을 지킴, 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만듦

###템플릿 메서드 패턴 - 정의

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

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

하지만

• 템플릿 메서드 패턴은 상속을 사용, 상속에서 오는 단점들을 그대로 안고 감, 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있음, 의존관계에 대한 문제, 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않음

• 이번 장에서 지금까지 작성했던 코드를 떠올리면, 자식 클래스를 작성할 때 부모 클래스의 기능을 사용한 것이 있었던가? 그럼에도 불구하고 템플릿 메서드 패턴을 위해 자식 클래스는 부모 클래스를 상속 받음

• 상속을 받는다는 것은 특정 부모 클래스를 의존하고 있다는 것, 자식 클래스의 extends 다음에 바로 부모 클래스가 코드상에 지정되어 있음, 따라서 부모 클래스가 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 됨, 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻, 자식 -> 부모 의존관계 반영

• 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야 함 이것은 좋은 설계가 아님, 그리고 이런 잘못된 의존관계 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향 줌

• 추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡 지금까지 설명한 이런 부분들을 더 깔끔하게 개선하려면 어떻게 해야할까? 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴(Strategy
  Pattern)