[SpringBoot 핵심 원리] 템플릿 메소드 패턴과 콜백 패턴 (2)

윤경·2021년 12월 27일

SRP Springboot StrategyPattern TIL

Spring Boot

목록 보기

64/79

[5] 템플릿 메소드 패턴 - 적용1

: 만들어둔 애플리케이션 로그 추적기 로직에 템플릿 메소드 패턴 적용하기

✔️ AbstractTemplate.java

public abstract class AbstractTemplate<T> { // <T>: 타입에 대한 정보를 객체를 생성하는 시점으로 미룸

    private final LogTrace trace;

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

AbtractTemplate은 템플릿 메소드 패턴에서 부모 클래스이자 템플릿 역할을 한다.
<T> 제네릭을 사용해 반환타입을 정의했다.
객체를 생성할 때 내부에서 사용할 LogTrace trace를 전달받는다.
로그에 출력할 message를 외부에서 파라미터로 전달받는다.
템플릿 코드 중간에 call() 메소드를 통해 변하는 부분을 처리한다.
abstract T call()은 변하는 부분을 처리하는 메소드이다. 이 부분은 상속으로 구현해야 한다.

✔️ OrderControllerV4.java

...

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

        // 익명 내부 클래스 사용
        AbstractTemplate<String> template = new AbstractTemplate<String>(trace) {
            @Override
            protected String call() {
                orderService.orderItem(itemId);
                return "ok";
            }
        };
        return template.execute("OrderController.request()");
    }
...

➡️ 이외의 부분은 v3와 동일하기 때문에 생략했다.

AbstractTemplate<String>
: 제네릭을 String으로 설정했다. 따라서 AbstractTemplate의 반환 타입은 String이 된다.

익명 내부 클래스
: 익명 내부 클래스를 사용한다.
객체를 생성하면서 AbstractTemplate를 상속받은 자식 클래스를 정의했다.
따라서 별도의 자식 클래스를 직접 만들지 않아도 된다.

template.execute("OrderController.request()")
: 템플릿을 실행하면서 로그로 남길 message를 전달한다.

✔️ OrderServiceV4.java

...
    public void orderItem(String itemId) {

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

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

➡️ 이외의 부분은 v3와 동일하기 때문에 생략했다.

AbstractTemplate<Void>
: 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면 Void(void 아님) 타입을 사용하고 null을 반환하면 된다.
참고로 제네릭은 기본 타입인 void, int등을 선언할 수 없다.

✔️ OrderRepositoryV4.java

...
    public void save(String itemId) {

        AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
            @Override
            protected Void call() {
                // 저장 로직
                if(itemId.equals("ex")) {   // (다양한 예제를 위해)"ex"라는 것이 넘어오면 예외 발생시킬
                    throw new IllegalStateException("예외 발생!");
                }
                sleep(1000);    // 상품을 저장하는데 1초 정도 걸린다고 가정

                return null;
            }
        };
        template.execute("OrderRepository.save()");
    }
...

➡️ 이외의 부분은 v3와 동일하기 때문에 생략했다.

실행 결과

[6] 템플릿 메서드 패턴 - 적용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 코드만 변경하면된다.

템플릿이 없는 V3 상태에서는 로그를 남기는 로직을 변경해야 할 때 모든 클래스를 찾아 바꾸어야 하는 번거로움이 존재한다.

단일 책임 원칙(SRP)

: V4는 단순히 템플릿 메소드 패턴을 적용해 코드 몇 줄을 줄인 것만이 아니다.

로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다.
변경 지점을 하나로 모아 변경에 쉽게 대처할 수 있는 구조를 만들었다.

🔗 SOLID 원칙 알아보기

[7] 템플릿 메소드 패턴 - 정의

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

템플릿 메소드 디자인 패턴의 목적은 다음과 같습니다.
"작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다.
템플릿 메소드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다." [GOF]

작업에서 알고리즘의 골격을 정의 = 템플릿
일부 단계 = 변하는 부분

GOF 템플릿 메소드 패턴 정의

풀어서 설명하면 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다.

이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다.
결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.

하지만, 템플릿 메소드 패턴은 상속을 사용한다.
따라서 상속에서 오는 단점들이 그대로 적용된다.

특히 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다.
➡️ 의존관계에 대한 문제

자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
(저번에 작성했던 코드를 돌이켜보면 한 번도 자식 클래스에서 부모 클래스의 기능을 사용한 적이 없다.)
그럼에도 불구하고 템플릿 메소드 패턴을 위해 자식 클래스는 부모 클래스를 상속받고 있다.

상속 받는다. = 특정 부모 클래스를 의존하고 있다.

자식 클래스의 extends 다음에 바로 부모 클래스가 코드 상에 지정되어 있다.
따라서 부모 클래스의 기능 사용 여부와 관계없이 부모 클래스를 강하게 의존하게 된다.
여기서 강하게 의존된다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀있다는 뜻이다.

UML에서 상속을 받으면 삼각형 화살표가 자식 → 부모를 향하고 있는 것은 이런 의존관계를 반영하는 것이다.

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

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

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

[8] 전략 패턴 - 시작

별 내용 없음

[9] 전략 패턴 - 예제1

: 동일한 문제 전략 패턴 사용해 해결하기

템플릿 메소드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어 상속을 사용해 문제를 해결했다.

전략 패턴은 변하지 않는 부분을 Context라는 곳에 두고, 변하는 부분을 Strategy라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해 문제를 해결한다. (Context, Strategy 이름을 굳이 똑같이 짓지 않아도 된다.)
➡️ 상속이 아니라 위임으로 문제를 해결

전략 패턴에서 (거대한 문맥인) Context는 변하지 않는 템플릿 역할을 하고, Strategy는 변하는 알고리즘 역할을 한다.

GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.

알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환하게 만들자.
전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

✔️ Strategy.java (interface)

public interface Strategy {
    void call();
}

이 인터페이스는 변하는 알고리즘 역할을 한다.

✔️ StrategyLogic1.java

@Slf4j
public class StrategyLogic1 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직1 실행");
    }
}

변하는 알고리즘은 Strategy 인터페이스를 구현하면 된다.
(여기서는 비즈니스 로직1을 구현함)

그리고 동일하게 StrategyLogic2.java를 2로 바꾸어 구현하였다.

✔️ ContextV1.java

/**
 * 필드에 전략을 보관하는 방식
 */
@Slf4j
public class ContextV1 {

    private Strategy strategy;

    public ContextV1(Strategy strategy) {
        this.strategy = strategy;
    }

    public void execute() {
        long startTime = System.currentTimeMillis();

        // 비즈니스 로직 실행
        strategy.call();    // 위임
        // 비즈니스 로직 종료

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

ContextV1은 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다.
전략 패턴에서는 이것을 컨텍스트(문맥) 이라고 한다.

쉽게, 컨텍스트(문맥)은 크게 변하지 않지만, 그 문맥 속에서 strategy를 통해 일부 전략이 변경된다 생각하면 된다.

Context는 내부에 Strategy strategy 필드를 가지고 있다. 이 필드에 변하는 부분인 Strategy의 구현체를 주입하면 된다.

전략 패턴의 핵심은 Context는 Strategy 인터페이스에만 의존한다는 점이다.
덕분에 Strategy의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.

어디서 많이 본 코드라고 느낄 수 있는데,

📌 스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴

✔️ ContextV1Test.java

...
    /**
     * 전략 패턴 사용
     */
    @Test
    void strategyV1() {
        StrategyLogic1 strategyLogic1 = new StrategyLogic1();
        ContextV1 context1 = new ContextV1(strategyLogic1); // context에 내가 원하는 것을 주입
        context1.execute();

        StrategyLogic2 strategyLogic2 = new StrategyLogic2();
        ContextV1 context2 = new ContextV1(strategyLogic2);
        context2.execute();
    }
...

코드를 보면 의존관계 주입을 통해 ContextV1에 strategy의 구현체인 strategyLogic1을 주입하는 것을 확인할 수 있다.
이렇게 Context 안에 원하는 전략을 주입한다.
원하는 모양으로 조립을 완료한 다음 context1.execute()를 호출해 context를 실행한다.

전략 패턴 실행 그림

Context에 원하는 Strategy 구현체를 주입

클라이언트는 context를 실행

context는 context 로직을 시작

context 로직 중간에 strategy.call()을 호출해 주입 받은 strategy 로직을 실행

context는 나머지 로직을 실행

테스트 결과

[10] 전략 패턴 - 예제2

: 전략 패턴도 익명 내부 클래스를 사용할 수 있다.

✔️ ContextV1Test.java

...
    @Test
    void strategyV2() {
        Strategy strategyLogic1 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        ContextV1 contextV1 = new ContextV1(strategyLogic1);
        log.info("strategyLogic1={}", strategyLogic1.getClass());
        contextV1.execute();

        Strategy strategyLogic2 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        };
        ContextV1 contextV2 = new ContextV1(strategyLogic2);
        log.info("strategyLogic2={}", strategyLogic2.getClass());
        contextV2.execute();
    }

    @Test
    void strategyV3() { // 인라인으로 코드가 간결해짐
        ContextV1 contextV1 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        contextV1.execute();

        ContextV1 contextV2 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
        contextV2.execute();
    }

    @Test
    void strategyV4() { // replace with lambda로 더욱 간결해짐 (option+enter)
        ContextV1 contextV1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
        contextV1.execute();

        ContextV1 contextV2 = new ContextV1(() -> log.info("비즈니스 로직2 실행"));
        contextV2.execute();
    }

✔️ V2()

(실행 결과를 첨부하진 않았지만)
ContextV1Test$1, ContextV1Test$2와 같이 익명 내부 클래스가 생성되었다.

✔️ V3()

익명 내부 클래스를 변수에 담아두지 말고, 생성하면서 바로 ContextV1에 전달해도 된다.

✔️ V4()

익명 내부 클래스를 자바8부터 제공하는 람다로 변경할 수 있다.
람다로 변경하려면 인터페이스에 메소드가 1개만 있으면 되는데, 여기서 제공하는 Strategy 인터페이스는 메소드가 1개만 있으므로 람다로 사용할 수 있다.

정리하자면 일반적인 전략 패턴은 변하지 않는 부분을 Context에 두고 변하는 부분을 Strategy를 구현해서 만든다.
그리고 Context의 내부 필드에 Strategy를 주입해 사용했다.

선 조립, 후 실행

Context의 내부 필드에 Strategy를 두고 사용하는 부분

이 방식은 Context와 Strategy를 실행 전 원하는 모양으로 조립해두고, 그 다음 Context를 실행하는 선 조립, 후 실행 방식에서 매우 유용하다.

Context와 Strategy를 한 번 조립하고 나면 이후로는 Context를 실행하기만 하면 된다.
우리가 스프링으로 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음 실제 요청을 처리하는 것과 같은 원리이다.

이 방식의 단점은 Context와 Strategy를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다.
물론 Context에 setter를 제공해 Strategy를 넘겨 받아 변경하면 되지만, Context를 싱글톤으로 사용할 때는 동시성 이슈 등 고려해야 할 점들이 많다.

그래서 전략을 실시간으로 변경해야 한다면 차라리 이전에 개발한 테스트 코드처럼 Context를 하나 더 생성하고 그곳에 Strategy를 주입하는 것이 더 나은 선택일 수 있다.

[11] 전략 패턴 - 예제3

: 전략 패턴 조금 다르게 사용하기

이전에는 Context의 필드에 Strategy를 주입해 사용했지만 이번에는 전략을 실행할 때 파라미터로 전달해 사용

✔️ ContextV2Test.java

@Slf4j
public class ContextV2Test {

    /**
     * 전략 패턴 적용
     */
    @Test
    void strategyV1() {
        ContextV2 context = new ContextV2();
        context.execute(new StrategyLogic1());  // 전략을 파라미터로 전달 받는 방식
        context.execute(new StrategyLogic2());
    }

    /**
     * 전략 패턴 익명 내부 클래스
     */
    @Test
    void strategyV2() {
        ContextV2 context = new ContextV2();
        context.execute(new Strategy() {    // execute 안에서 실행할 코드 조각을 넘긴다고 생각
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
    }

    /**
     * 전략 패턴 익명 내부 클래스2, 람다
     */
    @Test
    void strategyV3() {
        ContextV2 context = new ContextV2();

        context.execute(() -> log.info("비즈니스 로직1 실행"));
        context.execute(() -> log.info("비즈니스 로직2 실행"));
    }
}

✔️ ContextV2
ContextV2는 전략을 필드로 가지지 않는다.
대신 전략을 execute(..)가 호출될 때마다 항상 파라미터로 전달받는다.

✔️ V1()
Context와 Strategy를 선 조립 후 실행 하는 방식이 아니라 Context를 실행할 때마다 전략을 인수로 전달한다.

클라이언트는 Context를 실행하는 시점에 원하는 Strategy를 전달할 수 있다.
따라서 이전 방식과 비교해 원하는 전략을 더욱 유연하게 변경 가능하다.

테스트 코드를 보면 하나의 Context만 생성한다. 그리고 하나의 Context에 실행 시점에 여러 전략을 인수로 전달해 유연하게 실행하는 것을 확인할 수 있다.

전략 패턴 파라미터 실행 그림

클라이언트는 Context를 실행하면서 인수로 Strategy를 전달

Context는 execute() 로직 실행

Context는 파라미터로 넘어온 strategy.call() 로직을 실행

Context의 execute() 로직 종료

✔️ V2()
여기서도 물론 익명 내부 클래스를 사용할 수 있다.
코드 조각을 파라미터로 넘긴다고 생각하면 더 자연스럽다.

✔️ V3()
람다를 사용해 코드를 더 단순하게 만들었다.

정리하자면

ContextV1은 필드에 Strategy를 저장하는 방식으로 전략 패턴을 구사
: 선 조립, 후 실행 방법에 적합
Context를 실행하는 시점에는 이미 조립이 끝났기 때문에 전략을 신경쓰지 않고 단순히 실행만 하면 된다.
ContextV2는 파라미터에 Strategy를 전달받는 방식으로 전략 패턴을 구사
: 실행할 때마다 전략을 유연하게 변경할 수 있음
단점 역시 실행할 때마다 전략을 계속 지정해주어야 함

템플릿

지금 우리가 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것

변하지 않는 부분을 템플릿이라고 하며,
그 템플릿 안에서 변하는 부분에 약간 다른 코드 조각을 넘겨 실행하는 것이 목적

ContextV1, ContextV2 두 가지 방식 다 문제를 해결할 수 있다.
하지만 지금 원하는 것은 단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶은 것이다.

따라서 지금은 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2가 더 적합하다고 할 수 있다.

윤경

개발 바보 이사 중

이전 포스트

[SpringBoot 핵심 원리] 템플릿 메소드 패턴과 콜백 패턴 (1) + 익명 내부 클래스

다음 포스트

[SpringBoot 핵심 원리] 템플릿 메소드 패턴과 콜백 패턴 (2)

Spring Boot

[5] 템플릿 메소드 패턴 - 적용1

✔️ AbstractTemplate.java

✔️ OrderControllerV4.java

✔️ OrderServiceV4.java

✔️ OrderRepositoryV4.java

실행 결과

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

좋은 설계란

단일 책임 원칙(SRP)

[7] 템플릿 메소드 패턴 - 정의

GOF 템플릿 메소드 패턴 정의

[8] 전략 패턴 - 시작

[9] 전략 패턴 - 예제1

✔️ Strategy.java (interface)

✔️ StrategyLogic1.java

✔️ ContextV1.java

📌 스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴

✔️ ContextV1Test.java

전략 패턴 실행 그림

테스트 결과

[10] 전략 패턴 - 예제2

✔️ ContextV1Test.java

✔️ V2()

✔️ V3()

✔️ V4()

선 조립, 후 실행

[11] 전략 패턴 - 예제3

✔️ ContextV2Test.java

전략 패턴 파라미터 실행 그림

템플릿

[SpringBoot 핵심 원리] 템플릿 메소드 패턴과 콜백 패턴 (1) + 익명 내부 클래스

[SpringBoot 핵심 원리] 템플릿 메소드 패턴과 콜백 패턴 (3) + 템플릿 콜백 패턴 / 전략 패턴 / 제네릭

0개의 댓글