[Spring] 템플릿 메서드 패턴과 전략 패턴

 

 

 

템플릿 메서드 패턴은 변하는 부분과 변하지 않는 부분을 분리하기 위해 사용되는 디자인 패턴이다.

 

하나의 메서드는 비즈니스 로직을 실행하는 부분과 비즈니스 로직의 실행 시간을 측정하는 부분으로 구성된다.

여기서 핵심 기능은 비즈니스 로직을 실행하는 부분이고, 실행 시간을 측정하는 부분은 부가적인 기능이다.

 

핵심 기능과 부가 기능을 분리해보자.

 

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

public class SubLogic1 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("로직1 실행");
    }
}

public class SubLogic2 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("로직2 실행");
    }
}

AbstractTemplate template1 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("로직1 실행");
            }
        };
        
AbstractTemplate template2 = () -> { log.info("로직2 실행"); };

 

 

템플릿은 기준이 되는 틀이다.

템플릿에 변하지 않는 부가기능을 몰아넣고 변할 수 있는 핵심 기능은 별도로 호출해서 처리하자.

(따라서 인터페이스 대신 추상클래스를 사용했다)

 

변경이 필요할 때 유연하게 대처할 수 있어야 좋은 설계라고 할 수 있고, 그런 점에서 템플릿 메서드 패턴을 적절히 사용하면 좋은 설계를 구현할 수 있다고 할 수 있다.

 

부모 클래스에 변경되지 않는 템플릿을 제공하고, 변경되는 로직은 자식 클래스에 정의해 자식 클래스가 전체 구조를 변경하지 않고 특정 부분만 재정의해서 사용한다.

 

템플릿 메서드 패턴을 적용 시 코드에 변경이 필요할 때 쉽게 변경할 수 있다.

 

익명 클래스와 람다 표현식을 사용해 템플릿 메서드 패턴의 복잡성을 줄일 수 있긴 하지만, 

그럼에도 변형이 필요할 때 마다 구현체의 수가 증가한다는 단점이 있고,

상속을 사용할 수 밖에 없다 보니 상속에서 발생하는 단점을 그대로 가져가게 된다.

 

실제로 위의 예시에서 자식 클래스는 부모 클래스의 기능을 전혀 사용하고 있지 않지만 자식 클래스와 부모 클래스가 상속으로 컴파일 시점에서 강하게 결합된다.

 

이런 단점을 극복하기 위해 전략 패턴이 도입됐다.

 

전략 패턴은 변하지 않는 부분을 Context에 두고 변하는 부분을 인터페이스 (Strategy) 에서 구현하도록 하는 방식으로 문제를 해결한다.

 

 

 

Context : 변하지 않는 템플릿

Strategy : 변하는 로직

 

 

public interface Strategy {
    void call();
}

public class StrategyLogic1 implements Strategy {
    @Override
    public void call() {
        log.info("로직1");
    }
}


public class Context {

    private Strategy strategy;

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

 

 

스프링의 DI 와 같은 개념이다. (예시도 스프링의 생성자 주입 방식을 따라하고 있다)

템플릿 메서드 패턴은 상속을 통해 로직을 변경하지만, 전략 패턴은 인터페이스를 구현하는 개별 클래스로 로직을 감싸서 변경한다. (구성)

 

위의 예시는 Context와 Strategy를 실제로 실행하기 전에 모두 구성해두기에 한 번 결정된 전략을 변경하기는 힘들다.

따라서 파라미터에 Strategy를 전송하는 방식으로 구성하면 좀 더 유연하게 대처할 수 있다.

 

public class Context {

    public void execute(Strategy strategy) {
        long startTime = System.currentTimeMillis();
        strategy.call(); 
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("{}", resultTime);
    }
}

Context context = new Context();
context.execute(new StrategyLogic1());
context.execute(new StrategyLogic2());

 

 

두 가지 예시 모두 전략 패턴이고, 인터페이스의 추상 메서드가 하나 뿐이기에 함수형 인터페이스이고, 람다식을 사용해서 짧게 구현할 수 있다.

 

실행할 때 마다 전략을 변경해야 할 경우 두 번째 방법을, 동적으로 전략을 변경하지 않아도 되는 경우 첫 번째 방법을 사용함을 고려해보자.

 

전략 패턴의 의도는 Context와 Strategy를 구분해서 변하는 부분과 변하지 않는 부분을 구분하는 점이다.

디자인 패턴을 구분할 때는 의도를 생각해보자. 

 

전략 패턴에서의 전략을 콜백으로 볼 수 있다.

 

스프링은 JdbcTemplate, RedisTemplate 등 다양한 Template을 제공하는데, 여기서 템플릿 콜백 패턴이 사용된다.

템플릿은 Context 콜백은 Strategy로 생각하면 이해하기 쉽다.