[Spring] 디자인 패턴 - Strategy Pattern

이 전 포스팅에서 알아본 Template Method Pattern은 "추상 클래스"에 자식 클래스에서 변경되는 로직의 골격을 선언 및 공통으로 사용하는 로직의 골격을 정의(*구현)하고 "자식 클래스"에서는 부모 클래스를 상속받아 변경되는 로직을 정의(*구현)하는 방식이였습니다.

이 패턴에서는 상속을 사용하여 "특정" 부모 클래스에 의존하지만, 아래 코드와 같이 자식 클래스 입장에서 '구현 클래스'만 딱 생각해보면 부모 클래스의 기능을 전혀 사용하지도 않는데, 부모 클래스의 영향을 받게 됩니다.

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

+ 별도의 자식 클래스나 익명 클래스를 만들어야 하는 부분도 꽤 번거롭다는 단점이 있습니다.

 

이번에는 Template-Method 패턴의 단점을 보완할 수 있는 Strategy 패턴에 대해 알아보도록 하겠습니다.!

Strategy 패턴이란?

 

 

strategy 패턴

심플하게 설명하자면 이렇습니다.

• 변하지 않는 부분을 Context에 클래스로 정의 및 구현
  • Context가 Template Method Pattern의 템플릿 역할을 한다고 보시면 됩니다.
• 변하는 부분을 Strategy에 인터페이스로 정의 및 선언
  • Strategy 인터페이스의 구현체로 변하는 부분을 구현합니다.
  • Strategy는 Template Method Pattern의 변하는 알고리즘 역할
• Spring을 다루면서 기본적으로 사용해온 방식이 바로 전략 패턴이라고 볼 수 있음.

전략 패턴(Strategy Pattern)의 의도?
알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들어 알고리즘을 독립적으로 변경 가능하게 만들자. 

 

Strategy 패턴 v1 - Context 생성 시점에 의존관계 주입 

Strategy

public interface Strategy {
    void call();
}

• call() : 변하는 부분인 골격을 인터페이스로 선언해주었습니다. 
• 구현체에 따라 유동적으로 구현 

@Slf4j
public class StrategyLogic1 implements Strategy {

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

@Slf4j
public class StrategyLogic2 implements Strategy {

    @Override
    public void call() {
        log.info("비즈니스 로직2 실행");
   }
}

---

Context

Context에서는 Strategy를 컴파일 시점에서 갈아끼울 수 있도록 주입받아 사용합니다.

• 변하지 않는 부분인 공통 로직은 execute()에 구현하고 변하는 부분은 주입받은 Strategy을 통해 위임하여 실행합니다.
• Strategy Pattern의 핵심 : Context는 Strategy 인터페이스에만 의존한다는 점
  • 즉, Strategy의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않습니다.

@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();
        log.info("result Time = {}", endTime - startTime);
    }
}

• 1. context - Strategy 구현체를 주입받아 생성
• 2. execute() 실행
  • 2-1. 공통 로직 실행 
  • 2-2. 비즈니스 로직 : 주입한 Strategy 구현체에 위임하여 실행
• 3. context는 나머지 로직을 실행.

@Test
public void strategyTest() throws Exception {
    Strategy strategyLogic1 = new StrategyLogic1();
    ContextV1 context1 = new ContextV1(strategyLogic1);
    context1.execute();
}

+ Tip : 마찬가지로 익명 클래스를 통해 Strategy 구현체 생성해도 ok

 

+ Tip 인터페이스에 default, static을 제외하고 메소드가 1개 선언되어 있을 때 람다식 사용 가능 

• 뭔가 익숙한 방법이라고 생각이 들었는데, Spring 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것과 같은 원리였습니다.
• Context에 Strategy를 주입받아 사용하게 되면 조립(주입) 이후 변경이 번거롭고 싱글톤 패턴일 때 동시성까지 고려해주어야 하는 문제가 있습니다. ( 이 경우 Context를 새로 생성해서 다른 구현체를 주입받아 사용하는 방법이 권장됨 ) 
• 이어 선 조립 - 후 사용 방식 말고 더 유연하게 전략 패턴을 사용하는 방법을 알아보도록 하겠습니다.

Strategy 패턴 v2 - Context 생성 시점이 아닌 메소드에 Strategy를 파라미터 바인딩 

바로 아래와 같이 Context에 Strategy를 주입하지 않고 메소드에 파라미터로 Strategy를 전달받아 사용하는 방식입니다.

@Slf4j
public class ContextV2 {

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

 이러면 실행시점에 전략이 변경될 때, Context를 굳이 만들어줄 필요가 없어지게 됩니다! 이렇게 말이죠

@Test
public void strategyTest() throws Exception {
    Strategy strategyLogic1 = new StrategyLogic1();
    Strategy strategyLogic2 = new StrategyLogic2();

    ContextV2 context = new ContextV2();
    context.execute(strategyLogic1);
    context.execute(strategyLogic2);
}

 좀 더 클린하게 짜면 이렇게 할 수 있죠. 

@Test
public void strategyV4() throws Exception {
    ContextV2 context = new ContextV2();
    context.execute(() -> {
        log.info("비즈니스 로직1 실행");
    });
    context.execute(() -> {
        log.info("비즈니스 로직2 실행");
    });
}

하지만 지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립 - 후 실행이 아니라, 단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶은 것이니 그런 점에서는 v2가 더 적합한 것 같습니다.

---

Template-Callback 패턴

GOF의 Strategy 패턴을 Spring에서는 Template Callback 패턴으로 칭합니다.

1. Spring에서 JdbcTemplate처럼 다양한 템플릿 콜백 패턴이 사용되는데 xxxTemplate이라 쓰인 코드는 템플릿 콜백 패턴이 적용되었다고 봐도 됩니다.
2. Strategy 패턴의 Context -> Template, Strategy -> Callback ( 명칭만 다름 )

callback 함수라 함은, 다른 코드의 인수로 넘겨주는 실행 가능한 코드를 말합니다. (* callback을 조금 더 쉽게 말하면 코드가 호출(call)은 되는데 실제 실행은 코드를 넘겨준 곳의 뒤(back)에서 실행된다는 뜻)

 

@Slf4j
public class TemplateCallbackTest {

    @Test
    public void callbackTest() throws Exception {

        TimeLogTemplate template = new TimeLogTemplate();
        Callback callback = new Callback() {
            @Override
            public void call() {
                log.info("비즈니스 로직 실행1");
            }
        };
        template.execute(callback);
    }
}

// 메소드가 하나면 람다식 적용 ok.
@Test
void callbackV2() {
TimeLogTemplate template = new TimeLogTemplate();
    template.execute(() -> log.info("비즈니스 로직1 실행"));
    template.execute(() -> log.info("비즈니스 로직2 실행"));
}

---

Template-Callback 패턴 적용 

* 람다식으로 코드를 깔끔하게 작성하였습니다.

Controller 

@GetMapping("/v5/request")
public String request(@RequestParam String itemId) {
    return template.execute("OrderService.orderItem()", () -> {
        orderService.orderItem(itemId);
        return "ok";
    });
}

• template.execute(msg, new TraceCallback(){..}) : 템플릿을 실행하면서 콜백을 전달합니다. 

Service

public void orderItem(String itemId) {
    template.execute("OrderService.orderItem()", () -> {
        orderRepository.save(itemId);
        return null;
    });
}

Repository

public void save(String itemId) {
    template.execute("OrderRepository.save()", () -> {
                if (itemId.equals("ex")) {
                    throw new IllegalStateException("예외 발생");
                }
                sleep(1000);
                return null;
            }
    );
}

 

<정리> 

• 템플릿 콜백 패턴까지 진행해보면서 변하는 코드와 변하지 않는 코드(공통기능)를 분리해보면서 코드를 최적화 해보았습니다.
• 공통적으로 계층의 원본 코드를 수정해야 하는건 마찬가지 였는데요, 지금까지 설명한 방식은 실제 스프링 안에서 많이 사용되는 방식이지만, 스케일이 커질수록 고쳐야 할 원본 코드도 많아지는 것은 불변합니다.
• 다음에는 프록시 패턴을 적용시켜 원본 코드를 손대지 않고 로그 추적기를 적용할 수 있는 방법을 알아보도록 하겠습니다. 

 

<참고자료>

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