스프링 코어2 - 템플릿 메서드 패턴(로그 추적기에 패턴 도입)

이전에 ThreadLocal을 사용하여 로그 추적기를 개발하였다. 하지만 로그 추적기를 도입한 코드와 도입하지 않은 코드를 보면 각 서비스 계층(controller, service, repository)에 로그 추적을 위한 코드가 삽입되어 SRP를 위반하는 코드이고, 보기에도 매우 지저분한 냄세가 나는 코드가 되었다.

 

로그 추적기 도입 전의 OrderController

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RequiredArgsConstructor
@RestController
public class OrderControllerV0 {
    private final OrderServiceV0 orderService;

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

 

로그 추적기를 도입 후의 OrderController

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

@RequiredArgsConstructor
@RestController
public class OrderControllerV4 {
    private final OrderServiceV4 orderService;
    private final LogTrace trace;/*의존 관계 주입받기*/

    @GetMapping("/v4/request")
    public String request(String itemId) {
        TraceStatus status = null;
        try {
            status = trace.begin("OrderController.request()");/*begin 사용*/
            orderService.orderItem(itemId);
            trace.end(status);
            return "ok";

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

딱 봐도 이건 아니다 싶다...

 

즉 OrderController에 핵심기능과 부가기능이 한 데 섞여 있는 것이다.

 

핵심기능 :

해당 객체가 제공하는 고유의 기능. ( 예로 주문 서비스의 핵심 기능은 주문 로직이다. orderController의 request 메서드에서는 orderService.orderItem()이 핵심기능이다. )

 

부가기능:

핵심 기능을 보조하기 위해서 제공되는 기능. (예로 로그 추적 로직, 트랜잭션 기능 등이다. orderController의 TraceStatus 객체를 사용하는 모든 부분이 부가기능이다.)

 

OrderControllerV0은 핵심 기능만 있지만 OrderControllerV4는 핵심 기능로직보다 부가기능 로직이 훨씬 길다!

 

OrderController, OrderService, OrderRepository를 보면 공통된 로직을 찾을 수 있다.

@RequiredArgsConstructor
@RestController
public class OrderControllerV4 {
    private final OrderServiceV4 orderService;
    private final LogTrace trace;

    @GetMapping("/v4/request")
    public String request(String itemId) {
        TraceStatus status = null;
        try {
            status = trace.begin("OrderController.request()");
            !!!... 핵심 기능 ...!!!
            trace.end(status);
            return "ok";

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

@RequiredArgsConstructor
@Service
public class OrderServiceV4 {
    private final OrderRepositoryV4 orderRepository;
    private final LogTrace trace;

    public void orderItem(String itemId){
        TraceStatus status = null;
        try {
            status = trace.begin("OrderService.orderItem()");
            !!!... 핵심 기능...!!!
            trace.end(status);
        } catch (Exception e) {
            trace.exception(status, e);
            throw e;
        }
    }
}

@RequiredArgsConstructor
@Repository
public class OrderRepositoryV4 {
    private final LogTrace trace;

    public void save(String itemId) {
        TraceStatus status = null;
        try {
            status = trace.begin("OrderService.orderItem()");
            !!!... 핵심 기능...!!!
            trace.end(status);
        } catch (Exception e) {
            trace.exception(status, e);
            throw e;
        }
    }

    private void sleep(int millis){
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

이렇게 보면 [!!!...핵심 기능...!!!] 부분만을 제외하면 모두 같은 것을 알 수 있다.

하여 중복되는 부분을 메서드로 뽑아내면 될 것 같지만 'try~ catch~'부분과 핵심기능이 중간에 있어서 단순히 메서드로 추출하기는 쉽지 않다.

 

하여 템플릿 메서드 패턴을 적용해보자.

변하지 않는 것과 변하는 것을 분리하는 것이 좋은 어플리케이션 설계이다. 여기서 핵심 기능 부분은 변하고, 로그 추적기 부분은 변하지 않는 부분이다. 이 둘을 모듈화해야 한다. 템플릿 메서드 패턴을 적용하면 이와 같은 것이 가능해진자.

 

---

템플릿 메서드 패턴 알아보기

 

템플릿 메서드 패턴을 주문 서비스에 적용하기 전에 예시와 그것을 테스트하면서 템플릿 메서드 패턴을 살펴보자.

 

아래의 templateMethodV0은 logic1()과 logic2()를 실행한다. logic1, logic2 메서드는 비즈니스 로직 부분만 제외하면 모든 곳이 같은 코드이다. 하여 불필요한 중복이 발생하고 있는 것이다.

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



실행결과:

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

 

여기에 템플릿 메서드 패턴을 적용할 것이다. 템플릿 클래스는 추상 클래스로 만들고 중복되는 로직은 직접 구현하되, 각 구현체마다 달라지는 부분은 상속받는 클래스가 직접 구현하도록 한다. 코드로 보자

 

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

위 AbstractTemplate을 보면 이전의 logic1, logic2메서드에서 중복되는 부분은 직접 구현하였지만 달라지는 부분은 추상 클래스로 남겨두고 구현하지 않았다. 

 

이제 이를 구체적인 서브클래스가 구현하면 되는 것이다.

@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 SubClassLogic1();
    template2.execute();
}


실행결과:

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

결과는 물록 이전과 같고, OCP, SRP를 지킬 수 있는 코드가 되었다.

 

 

하지만 한번 더 나아가서 굳이 SubClass클래스를 만들지 않고, 아래처럼 익명 내부 클래스로 정의하여 사용할 수 있다.

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

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

실행결과는 같다.

 

이제 이를 주문 서비스에 적용해보자.

 

먼저 추상 템플릿은 아래와 같다.

import hello.advanced.app.trace.TraceStatus;
import hello.advanced.app.trace.logtrace.LogTrace;
import lombok.NoArgsConstructor;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public abstract class AbstractTemplate<T> {

    private final LogTrace trace;

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

이제 각각의 서비스 계층에서 call 메서드만 구현해주면 되는 것이다.

 

OrderController

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

@RequiredArgsConstructor
@RestController
public class OrderControllerV5 {
    private final OrderServiceV5 orderService;
    private final LogTrace trace;

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

 

OrderService

package hello.advanced.app.v5;

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

@RequiredArgsConstructor
@Service
public class OrderServiceV5 {
    private final OrderRepositoryV5 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 을 반환하면 된다.
참고로제네릭은기본타입인 void, int 등을 선언할 수 없다.

 

 

OrderRepository

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

@RequiredArgsConstructor
@Repository
public class OrderRepositoryV5 {
    private final LogTrace trace;

    public void save(String itemId) {
        AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
            @Override
            protected Void call() {
                sleep(itemId, 1000);//비즈니스 로직
                return null;
            }
        };
        template.execute("OrderRepository.save()");
    }


    private void sleep(String itemId, int millis){
        System.out.println(itemId+"을 저장");
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

 

이제 템플릿 메서드 패턴을 적용하여 변하는 코드와 변하지 않는 코드를 명확하게 분리하였다. 로그를 출력하는 템플릿 역학을 하는 변하지 않는 코드는 모두 'ABstractTemplate'에 담아두고, 변하는 코드는 자식 클래스를 만들어 분리하였다.

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

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

 

 

---

 

템플릿 메서드 패턴의 장점과 커다란 단점

 

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

 

작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면

하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다.

 

하지만

템플릿 메서드 패턴은 상속을 사용한다. 따라서 상속에서 오는 단점들을 그대로 안고간다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
이번 장에서 지금까지 작성했던 코드를 떠올려보자. 자식 클래스를 작성할 때 부모 클래스의 기능을 사용한 것이 있었던가?

그럼에도 불구하고 템플릿 메서드 패턴을 위해 자식 클래스는 부모 클래스를 상속 받고 있다.

상속을 받는 다는 것은 특정 부모 클래스를 의존하고 있다는 것이다. 자식 클래스의 extends 다음에 바로 부모 클래스가 코드 상에 지정되어 있다. 따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻이다. UML에서 상속을 받으면 삼각형 화살표가 자식 -> 부모 를 향하고 있는 것은 이런 의존관계를 반영하는 것이다.

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

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

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

 

 

 

 

 

 

 

김영한님의 인프런 강의와 PDF를 바탕으로 정리하였습니다.