[스프링 핵심원리 - 고급편] #3. 전략 패턴

[YONGHYNG]

전략 패턴

• 객체의 행위를 변경할 때, 해당 객체의 코드를 수정하지 않고도 행위를 바꿀 수 있도록 하는 디자인 패턴
• 알고리즘을 인터페이스로 분리하고 필요할 때마다 다른 알고리즘을 선택해서 사용할 수 있도록 하는 방식
• 장점: 유연성 증가, OCP 준수, 코드 재사용성 증가, if - else 문을 사용하지 않고도 다양한 동작, 동적으로 변경 가능

전략 패턴 -예제1

• 탬플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결
• 전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결, 상속이 아니라 위임으로 문제를 해결하는 것
• 전략 패턴에서 Context 는 변하지 않는 템플릿 역할을 하고, Strategy 는 변하는 알고리즘 역할을 진행

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

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

Strategy 인터페이스

package hello.advanced.trace.strategy.code.strategy;

public interface Strategy {
    void call();
}

• 이 인터페이스는 변하는 알고리즘 역할 진행

StrategyLogic1

package hello.advanced.trace.strategy.code.strategy;
import lombok.extern.slf4j.Slf4j;

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

• 변하는 알고리즘은 Strategy 인터페이스를 구현하면 됨, 여기서는 비즈니스 로직 1을 구현

StrategyLogic2

package hello.advanced.trace.strategy.code.strategy;
import lombok.extern.slf4j.Slf4j;

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

• 비즈니스 로직2를 구현

ContextV1

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

/**
 * 필드에 전략을 보관하는 방식
 */
@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

   /**
     * 전략 패턴 적용
     * */
    @Test
    void strategyV1() {
        Strategy strategyLogic1 = new StrategyLogic1(); //객체 생성
        ContextV1 context1 = new ContextV1(strategyLogic1); //그햔체 주입
        context1.execute();

        Strategy strategyLogic2 = new StrategyLogic1();
        ContextV1 context2 = new ContextV1(strategyLogic2);
        context2.execute();
    }

• 의존 관계 주입을 통해 ContextV1에 StrategyLogic1을 주입하는 것을 확인, 이렇게 Context안에 원하는 전략을 주입,

원하는 모양으로 조립을 완료하고 난 다음에 context1.execute()를 호출해서 context를 실행

전략 패턴 실행 그림

• 1. Context에 원하는 Strategy 구현체 주입
• 2. 클라이언트는 context 실행
• 3. context는 context 로직 시작
• 4. context 로직 중간에 strategy.call()을 호출해서 주입 받은 strategy 로직을 실행
• 5. context는 나머지 로직 실행

실행 결과

 /**
     * 전략 패턴 익명 내부 클래스1
     * */
    @Test
    void strategyV2() {
        Strategy strategyLogic1 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        log.info("strategyLogic1={}", strategyLogic1.getClass());
        ContextV1 context1 = new ContextV1(strategyLogic1);
        context1.execute();
        
        Strategy strategyLogic2 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        log.info("strategyLogic2={}", strategyLogic2.getClass());
        ContextV1 context2 = new ContextV1(strategyLogic2);
        context2.execute();
        }

실행 결과

• 실행 결과를 보면 ContextV1Test$1 , ContextV1Test$2 와 같이 익명 내부 클래스가 생성된 것을 확인

   /**
         * 전략 패턴 익명 내부 클래스2
         * */
        @Test
        void strategyV3() {
            ContextV1 context1 = new ContextV1(new Strategy() {
                @Override
                public void call() {
                    log.info("비즈니스 로직1 실행");
                }
            });
            context1.execute();
            
            ContextV1 context2 = new ContextV1(new Strategy() {
                @Override
                public void call() {
                    log.info("비즈니스 로직2 실행");
                }
            });
            context2.execute();
        }

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

/**
         * 전략 패턴, 람다
         * */
        @Test
        void strategyV4() {
            ContextV1 context1 = new ContextV1 (() -> log.info("비즈니스 로직1 실행"));
            context1.execute();

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

• 익명 내부 클래스를 자바8부터 제공하는 람다로 변경 가능
• 람다로 변경하려면 인터페이스에 메서드가 1개만 있으면 됨, 여기서는 Strategy 인터페이스는 메서드가 1개만 있어 람다로 사용 가능함

선 조립, 후 실행

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

전략 패턴 - 예제3

• 이번에는 전략 패턴을 조금 다르게 사용하자, 이전에는 Context 의 필드에 Strategy 를 주입해서 사용, 이번
  에는 전략을 실행할 때 직접 파라미터로 전달해서 사용하자

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

/**
 * 전략을 파라미터로 전달 받는 방식
 */
@Slf4j
public class ContextV2 {

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

• ContextV2는 전략 필드로 가지지 않음, 대신 전략을 execute(...)가 호출될 떄 마다 항상 파라미터로 받음

TEST

package hello.advanced.trace.strategy;
import hello.advanced.trace.strategy.code.strategy.ContextV2;
import hello.advanced.trace.strategy.code.strategy.Strategy;
import hello.advanced.trace.strategy.code.strategy.StrategyLogic1;
import hello.advanced.trace.strategy.code.strategy.StrategyLogic2;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class ContextV2Test {

           /**
           * 전략 패턴 적용
           */
           @Test
           void strategyV1() {
                     ContextV2 context = new ContextV2();
                     context.execute(new StrategyLogic1());
                     context.execute(new StrategyLogic2());
           }
}

• Context 와 Strategy 를 '선 조립 후 실행'하는 방식이 아니라 Context 를 실행할 때 마다 전략을 인수로 전달
• 클라이언트는 Context 를 실행하는 시점에 원하는 Strategy 를 전달할 수 있음, 따라서 이전 방식과 비교해서 원하
  는 전략을 더욱 유연하게 변경할 수 있음
• 테스트 코드를 보면 하나의 Context 만 생성, 그리고 하나의 Context 에 실행 시점에 여러 전략을 인수로 전달
  해서 유연하게 실행하는 것을 확인 가능

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

• 1. 클라이언트는 Context 를 실행하면서 인수로 Strategy 를 전달
• 2. Context 는 execute() 로직을 실행
• 3. Context 는 파라미터로 넘어온 strategy.call() 로직을 실행
• 4. Context 의 execute() 로직이 종료

   /**
     * 전략 패턴 익명 내부 클래스
     */
    @Test
    void strategyV2() {
        ContextV2 context = new ContextV2();
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
    }
}

• 여기도 물론 익명 내부 클래스 사용 가능, 코드 조각을 파라미터로 넘긴다고 생각하면 자연스러움

/**
 * 전략 패턴 익명 내부 클래스2, 람다
 */
@Test
void strategyV3() {
       ContextV2 context = new ContextV2();
       context.execute(() -> log.info("비즈니스 로직1 실행"));
       context.execute(() -> log.info("비즈니스 로직2 실행"));
}

• 람다를 사용해서 코드를 더 단순하게 만들 수 있음

정리

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

템플릿

• 지금 우리가 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것
• 변하지 않는 부분을 템플릿이라고 함, 그 템플릿 안에서 변하는 부분에 약간 다른 코드 조각을 넘겨 실행하는 것이 목적
• ContextV1 , ContextV2 두 가지 방식 다 문제를 해결할 수 있지만, 어떤 방식이 조금 더 나아 보이는가?
• 지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립, 후 실행이 아님, 단순히 코드를 실행할
  때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐
• 따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2 가 더 적합

템플릿 콜백 패턴 - 시작

• 변하는 부분(콜백)과 변하지 않는 부분(템플릿)을 분리하는 패턴
• 메서드에서 실행할 로직을 매개변수(콜백)로 전달하여 실행
• 중복을 줄이고, 유연한 코드 구조를 제공
• 전략 패턴과 유사하지만, 템플릿 콜백 패턴은 인터페이스를 만들 필요 없이 간단하게 람다 표현식을 활용 가능
• ContextV2 는 변하지 않는 템플릿 역할을 함
• 그리고 변하는 부분은 파라미터로 넘어온 Strategy 의 코드를 실행해서 처리, 이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백이라 함

콜백 정의

• 쉽게 이야기해서 callback 은 코드가 호출( call )은 되는데 코드를 넘겨준 곳의 뒤( back )에서 실행된다는 뜻
• ContextV2 예제에서 콜백은 Strategy
• 여기에서는 클라이언트에서 직접 Strategy 를 실행하는 것이 아니라, 클라이언트가 ContextV2.execute(..) 를 실행할 때 Strategy 를 넘겨주고, ContextV2 뒤에서 Strategy 가 실행 됨

자바 언어에서 콜백

• 자바 언어에서 실행 가능한 코드를 인수로 넘기려면 객체가 필요, 자바8부터는 람다를 사용할 수 있음
• 자바 8 이전에는 보통 하나의 메소드를 가진 인터페이스를 구현하고, 주로 익명 내부 클래스를 사용, 최근에는 주로 람다를 사용

###템플릿 콜백 패턴 - 예제

• Context -> Template
• Strategy -> Callback

Callback 인터페이스

package hello.advanced.trace.strategy.code.template;

public interface Callback {
        void call();
}

• 콜백 로직을 전달하는 인터페이스

TimeLogTemplate

package hello.advanced.trace.strategy.code.template;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class TimeLogTemplate {

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

package hello.advanced.trace.strategy;

import hello.advanced.trace.strategy.code.template.Callback;
import hello.advanced.trace.strategy.code.template.TimeLogTemplate;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class TemplateCallbackTest {

    /**
     * 템플릿 콜백 패턴 - 익명 내부 클래스
     * */
    @Test
    void callbackV1() {
        TimeLogTemplate template = new TimeLogTemplate();

        template.execute(new Callback() {
           @Override
           public void call() {
             log.info("비즈니스 로직1 실행");
           }
        });
    }
    
    /**
     * 템플릿 콜백 패턴 - 람다
     * */
    @Test
    void callbackV2(){
        TimeLogTemplate template = new TimeLogTemplate();
        template.execute(() -> log.info("비즈니스 로직1 실행"));
        template.execute(() -> log.info("비즈니스 로직2 실행"));
    }
}

• 별도의 클래스를 만들어서 전달해도 되지만, 콜백을 사용할 경우 익명 내부 클래스나 람다를 사용하는게 편함
• 여러곳에서 사용하는 경우 재사용을 위해 콜백을 별도의 클래스로 만들어도 됨

템플릿 콜백 패턴 - 적용

TraceCallback 인터페이스

package hello.advanced.trace.callback;

public interface TraceCallback<T> {
       T call();
}

• 콜백을 전달하는 인터페이스
• 제네릭 사용, 콜백의 반환 타입 정의

package hello.advanced.trace.callback;

import hello.advanced.trace.TraceStatus;
import hello.advanced.trace.logtrace.LogTrace;

public class TraceTemplate {

    private final LogTrace trace;

    public TraceTemplate(LogTrace trace){
        this.trace = trace;
    }

    public <T> T execute(String message, TraceCallback<T> callback){
        TraceStatus status = null;
        try {
            status = trace.begin(message);

            //로직 호출
            T result = callback.call();

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

• TraceTemplate는 템플릿 역할을 함
• execute(...)을 보면 message 데이터와 콜백인 TraceCallback callback을 전달 받음
• 제네릭 사용, 반환 타입을 정의

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceCallback;
import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderControllerV5 {

    private final OrderServiceV5 orderService; //비즈니스 로직을 담당하는 서비스 객체
    private final TraceTemplate template; //공통된 로그 추적 로직을 담당하는 템플릿 객체

    public OrderControllerV5(OrderServiceV5 orderService, LogTrace trace) { //생성자 주입 받음
        this.orderService = orderService;
        this.template = new TraceTemplate(trace); //TraceTemplate을 생성 로그 추적을 위한 템플릿 설정
    }

    @GetMapping("/v5/request")
    public String request(String itemId) { //요청 파라미터로 itemId 값 받음
        /**
         * template.execute
         * 로그 추적 기능이 포함된 실행 템플릿 사용
         * */
        return template.execute("OrderController.requeest{}", new TraceCallback<>(){
            @Override
            public String call() {
                orderService.orderItem(itemId);
                return "ok";
            }
        });
    }
}

• this.template = new TraceTemplate(trace): trace 의존관계 주입을 받으면서 필요한 TraceTemplate 템플릿을 생성
• 참고 : TraceTemplate를 처음부터 스프링 빈으로 등록하고 주입 받아도 됨, 이 부분은 선택
• template.execute(... , new TraceCallback(){...}), 템플릿을 실행하면서 콜백을 전달, 여기서는 콜백으로 익명 내부 클래스 사용

OrderServiceV5

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.stereotype.Service;

@Service //서비스 빈으로 등록
public class OrderServiceV5 {

    private final OrderRepositoryV5 orderRepository;
    private final TraceTemplate template;

    public OrderServiceV5(OrderRepositoryV5 orderRepository, LogTrace trace) { //생성자, 의존성 주입
        this.orderRepository = orderRepository;
        this.template = new TraceTemplate(trace); //로그 추적을 위한 템플릿 설정
    }

       /**
     * template.execute(.., new TraceCallback(){..}) :
     * 템플릿을 실행하면서 콜백을 전달, 여기서는 콜백을 람다에 전달
     * */
    public void orderItem(String itemId){
        template.execute("OrderService.orderItem()", () -> {
            orderRepository.save(itemId);
            return null;
        });
    }
}

OrderRepositoryV5

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.stereotype.Repository;

@Repository //Spring 빈으로 등록, 데이터 저장을 담당하는 저장소 역할
public class OrderRepositoryV5 {

    private final TraceTemplate template; //로그 추적을 담당

    public OrderRepositoryV5(LogTrace trace){
        this.template = new TraceTemplate(trace);
    }

    public void save(String itemId){
        template.execute("OrderRepository.save()", () -> {

            //저장 로직
            if(itemId.equals("ex")) {
                throw new IllegalStateException("예외 발생!");
            }
            sleep(1000);
            return null; //TraceCallback<T> 인터페이스 사용에 따른 반환 값
        });
    }

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

실행 로그