전략 패턴

slee2·2022년 3월 7일

(인프런)스프링 MVC 고급편

목록 보기

8/23

시작

package hello.advanced.trace.strategy;

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 ContextV1Test {

    @Test
    void strategyV0() {
        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

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

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

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

Strategy 인터페이스

StrategyLogic1

ContextV1

ContextV1 은 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다.

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

테스트

의존관계 주입을 하고, 원하는 모양으로 조립하여 실행한다.

Context 에 원하는 Strategy 구현체를 주입한다.
클라이언트는 context 를 실행한다.
context 는 context 로직을 시작한다.
context 로직 중간에 strategy.call() 을 호출해서 주입 받은 strategy 로직을 실행한다.

이전과 다른점은 이전 코드의 경우 부모 클래스를 extends로 상속받아 부모 클래스의 영향을 받는데, 이번에는 implements를 통해 위임을 받기 때문에 영향을 전혀 받지 않는다.

예제2

익명 클래스를 이용해보자.

참고로 익명 클래스를 아래와 같이 바로 주입을 시킬 수 있다.

근데 이걸 람다로 하면...ㄷ;

엄청 짧아진다.

람다를 쓰려면, 인터페이스 메서드가 하나만 있어야 가능하다.(call())

정리
변하지 않는 부분 - Context()
변하는 부분 - Strategy

선 조립, 후 실행
이 방식은 Context와 Strategy를 실행 전에 원하는 모양으로 조립해두고, 그 다음에 Context를 실행하는 선 조립, 후 실행 방식에서 매우 유용하다.
스프링으로 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것 과 같은 원리이다.
이 방식의 단점은 Context 와 Strategy 를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다.
Context 에 setter 를 제공해서 Strategy 를 넘겨 받아 변경하면 되지만, Context 를 싱글톤으로 사용할 때는 동시성 이슈 등 고려할 점이 많다. 그래서 전략을 실시간으로 변경해야 하면 차라리 이전에 개발한 테스트 코드 처럼 Context 를 하나 더 생성하고 그곳에 다른 Strategy 를 주입하는 것이 더 나은 선택일 수 있다.