시작

이전에 로그 추적기를 만들었고, 파라미터를 넘기는 불편함을 없애기 위해 쓰레드 로컬을 도입했다.

로컬 추적기 도입 전과 후를 비교해보자.

도입 전

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

도입 후

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

try-catch가 붙다보니 양이 엄청 많고 복잡하다.

핵심 기능 vs 부가 기능

• 핵심 기능은 해당 객체가 제공하는 고유의 기능이다.
• 부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다. 예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용된다. 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용한다.

이 문제를 좀 더 효율적으로 처리할 수 있는 방법이 있을까?
V3 코드를 유심히 살펴보면 동일한 패턴이 있다.

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

구조가 모두 동일하고, 중간에 핵심 기능을 사용하는 코드만 다르다.
이 중복을 메서드로 뽑으면 될 거 같은데, try-catch도 그렇고, 핵심 기능이 중간에 있어서 메서드로 뽑기 애매하다.

변하는 것과 변하지 않는 것을 분리
핵심 기능 부분은 변하고, 로그 추적기를 사용하는 부분은 변하지 않는다.
이 둘을 분리해서 모듈화해야 한다.

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

예제

package hello.advanced.trace.tmplate;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@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

템플릿 메서드 패턴 구조는 위 그림과 같다.
추상 메서드를 만들고, call()이라는 메서드를 변하는 부분으로 넣을 것이다.

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

변하는 부분을 call()로 두고 오버라이딩 처리를 한다.

1과 2를 각각 만들었다.

테스트

로직1 -> call -> 로직2 -> call
오버라이딩이 각각 SubClassLogic1(), 2에 있으므로 다르게 실행이 된다.

이렇게 다형성을 이용해 변하는 부분과 변하지 않는 부분을 구현하는 것을 템플릿 메서드 패턴이라고 한다.

예제3

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

이렇게 익명 클래스를 이용해 바로 만들수 있다.
자바는 이렇게 익명 클래스로 만들 경우에 임의로 $1와 같이 숫자를 붙여준다.

어플리케이션에 적용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) {
            trace.exception(status, e);
            throw e;
        }
    }

    protected abstract T call();
}

제네릭 사용한다.
이전에 만들었던 내용을 조금씩 바꾼것 밖에 없다.

제네릭을 String으로 하고 call을 오버라이딩할때, 안에 비즈니스 로직을 넣는다.
마지막으로 리턴값인 "ok"를 반환시키면 된다.

반환 타입이 없을때는 제네릭을 Void로 타입을 설정한 뒤, null을 반환하면 된다.

익명 클래스때문에 좀 지저분한 느낌이 있긴하지만, 그래도 이전보다는 덜하다.

적용2

템플릿 메서드 패턴 덕분에 변하는 코드와 변하지 않는 코드를 분리했다.

//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 : 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다.

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

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

정의

GOF 책에서 이와 같이 말한다.

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

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

부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것.
이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다.

하지만, 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
자식 클래스에서 부모 클래스 메서드를 쓰지 않는데도 상속을 받고 있다.

상속을 받는다는 것은 특정 부모 클래스를 의존하고 있다는 것이다.
부모의 영향을 받게 된다. 부모 클래스에 새로운 메서드가 추가되면 자식은 이를 오버라이딩 해야한다.

이는 좋은 코드가 아니다. 추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다.

템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴 (Strategy Pattern)이다.