[Spring] 디자인 패턴 - Template Method 패턴

로그 추적기에 ThreadLocal을 도입해서 파라미터를 넘기는 불편함을 제거했습니다. 이번에는 로그 추적기에 여러 템플릿 메소드 패턴을 적용시켜 비즈니스 로직에서 핵심 기능과 부가 기능인 로그 기능을 분리해봅시다.

 

"핵심 기능"

• 해당 객체가 제공하는 고유의 기능을 말합니다.
• 예를 들면 OrderService의 orderItem()의 핵심 기능은 주문 로직입니다.
• OrderService의 orderItem()의 주문 로직 : orderRepository의 save()를 호출하여 주문을 저장

"부가 기능"

• 핵심 기능을 보조하기 위해 제공되는 기능
• 예를 들면 OrderService의 orderItem()의 부가 기능은 로그 추적 로직, 트랜잭션 기능

 

아래 코드를 보면 부가 기능과 핵심 기능이 하나의 메소드에 뒤섞여 있는 것을 확인할 수 있습니다. 이 코드를 좋은 코드라고 볼 수 없습니다. 로직이 단순해서 이정도지 로직이 꽤나 복잡해질 경우 핵심기능이 어떤 코드이고 부가기능이 어떤 코드인지 가독하기 굉장히 어려워질 수 있습니다.

핵심 기능과 부가 기능을 한 군데에 모아서 작성하기 보다, 분리하여 작성하는 것이 좋은 설계라고 할 수 있습니다.

public void orderItem(TraceId traceId, String itemId) {
	// 부가기능
    TraceStatus status = trace.begin("OrderService.orderItem()");

    try {  
        orderRepository.save(itemId); // 핵심 기능 
        trace.end(status); // 부가 기능 
    } catch (Exception e) {
        trace.exception(status, e); // 부가 기능
        throw e;
    }
}

 

이제 1) 템플릿 메소드 패턴이 무엇인지 알아보고, 2) 예제 코드로 적용해본 후, 3) 기존 로그 추적기에 적용시켜보도록 하겠습니다.

 

템플릿 메소드 패턴(Template Method Pattern)

정의 : 어떤 작업을 처리할 때 일부분(부가 기능)을 서브 클래스로 캡슐화해서 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역(핵심 기능)을 바꾸는 패턴입니다.

• 다시 말해 전체적으로 구조는 동일하되, 부분적으로 다른 구문으로 구성된 메소드의 코드 중복을 최소화할 때 유용하게 사용할 수 있는 패턴입니다.
• 앞서 개발한 로그 추적기로 대입 해보면 Controller계층, Service 계층, Repository 계층에서 로그 추적기를 적용시킴으로써 모든 계층에 같은 코드를 중복적으로 사용하는 문제가 있었는데, 이 부분들을 추상 클래스로 작성해서 부가 기능들을 추상 클래스에는 구현하고, 핵심 기능들은 추상 클래스에 선언만 해놓은 후, 이 추상클래스를 상속 받아 각 계층에 적용한다고 보면 됩니다.

 

템플릿 메소드 패턴 : 부모 클래스에 알고리즘의 골격인 템플릿을 정의한 후,
일부 변경되는 로직은 자식 클래스에 정의하는 것.

 

설명으로 이해하는 것보다 코드로 보면 더 쉽게 이해할 수 있습니다. 예제 코드로 템플릿 메소드 패턴을 만들어 보겠습니다.

---

템플릿 메소드 패턴 예시 코드

@Slf4j
public abstract class AbstractTemplate {

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

    protected abstract void call();
}

• 이 예제 코드에서는 부가 기능은 코드 실행 시간 출력입니다.
• execute() 메소드를 보면 핵심 기능을 call()로 호출하고, 나머지 공통 부가기능은 직접 구현을 해놓음으로써 선언하여 핵심 기능은 상속받은 클래스에서 구현하여 사용할 수 있게 구성하였습니다.

 

핵심 기능은 템플릿을 상속받아 구현

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

• 중복 코드인 부가 기능 코드는 직접 선언하고, 중복되지 않는 각각의 메소드의 고유 기능은 템플릿을 상속받아 직접 구현하여 부가 기능의 코드의 중복을 제거하였다고 볼 수 있습니다.

 

테스트 코드

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

• + 번외) 상속관계인 두 클래스가 있을때 자식 클래스를 사용하는 경우에, 선언부에는 부모 클래스로 작성하자.
  • 다형성을 적용하여 코드의 유연성과 재사용성을 높이며, 동적 바인딩을 적용할 수 있게 하기 위해.

테스트 결과

Tip : 익명 내부 클래스로 과도한 클래스 생성 보완

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

 

위와 같이 기능들을 구현할 때마다 클래스를 생성하는 것 보다, 코드를 재사용하지 않는 경우에는 익명 내부 클래스로 일회성으로 사용하는 방법도 있습니다. 이 때에는 당연한 얘기지만, 익명 내부 클래스이므로 AbstractTemplate template1 = new AbstractTemplate() 와 같이 형을 부모 클래스로 지정해줍니다.

익명 내부 클래스 적용

@Test
public void templateMethodV2() throws Exception {
    AbstractTemplate template1 = new AbstractTemplate() {
        @Override
        protected void call() {
            log.info("비즈니스 로직1 실행");
        }
    };

    template1.execute();

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

    template2.execute();
}

---

로그 추적기에 템플릿 메소드 패턴을 적용

예제 코드를 통해 템플릿 메소드 패턴을 어떻게 적용해야 하는지 감이 오는데요. 마지막으로 앞서 개발한 로그 추적기에 템플릿 메소드 패턴을 적용시켜 핵심 기능과 부가 기능을 분리해보도록 하겠습니다.

 

@Slf4j
@RequiredArgsConstructor
public abstract class AbstractTemplate<T> {
    private final LogTrace trace;

    public T execute(String msg) {
        TraceStatus status = null;
        try {
            status = trace.begin(msg);
            // 로직 호출
            T result = call();
            trace.end(status);

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

    protected abstract T call();
}

• 계층 마다 로직에 따라 리턴 타입이 달라질 수 있기 때문에 제너릭으로 모든 타입이 들어올 수 있게 열어두었습니다.
  •  protected abstract T call() : Controller에서는 핵심기능의 리턴타입이 String이고, 나머지 계층에서는 핵심기능의 리턴타입이 void이므로 핵심 기능 호출 메소드 call() 또한 리턴 타입을 T로 열어둠

Controller

@GetMapping("/v4/request")
public String request(@RequestParam String itemId) {

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

상속 관계를 사용하지 않고 익명 클래스를 사용하여 핵심 기능을 구현하는 클래스를 생성하지 않고 템플릿 메소드 패턴을 적용하였습니다.

• Controller 계층에서는 리턴타입이 String 이므로 템플릿 클래스 객체를 생성할 때 타입을 String으로 지정

 

Service

public void orderItem(String itemId) {

    AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
        @Override
        protected Void call() {
            orderRepository.save(itemId);
            return null;
        }
    };

    template.execute("OrderService.orderItem()");
}

• Service계층에서의 핵심로직의 리턴타입은 void이므로 템플릿 클래스의 객체를 생성할 때 타입을 Void로 지정

 

Repository

public void save(String itemId) {

    AbstractTemplate<Void> template = new AbstractTemplate<Void>(trace) {
        @Override
        protected Void call() {
            if (itemId.equals("ex")) {
                throw new IllegalStateException("예외 발생");
            }
            sleep(1000);
            return null;
        }
    };
    template.execute("OrderRepository.save()");
}

• Repository 계층 또한 리턴 타입이 없으므로 템플릿 객체 생성 시 타입을 Void로 지정하였습니다.

---

템플릿 메소드의 단점 

• 상속을 사용하므로 상속에서 오는 단점들이 따라옵니다.
  • 자식 클래스가 부모 클래스와 컴파일 시점에서 강하게 결합됩니다.
  • 이것을 돌려말하면 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않지만, 부모 클래스를 알아야 한다는 것입니다.
    • 자식 클래스에서 부모 클래스의 execute() 메소드를 사용하는가 ? X
  • 이것도 따지고 보면 좋은 설계는 아닙니다.
  • 그리고 패턴 적용을 위해 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 깔끔하진 않습니다.

템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴 (Strategy Pattern)인데, 이 다음 글에서 전략 패턴에 대해 알아보도록 하겠습니다.

---

<참고자료>

[Design Pattern] 템플릿 메서드 패턴이란 - Heee's Development Blog

 

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