템플릿 메서드 패턴과 콜백 패턴

템플릿 매서드 패턴


@Slf4j
public class TemplateMethodTest {

    @Test
    void templateMethodV0() {
        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("비즈니스 로직1 실행");
        // 비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTIme = endTime - startTime;
        log.info("resultTIme = {}", resultTIme);
    }

가운데에 있는 핵심 로직을 제외하고는 중복된다.


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

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


@Slf4j
public class TemplateMethodTest {

    @Test
    void templateMethodV0() {
        logic1();
        logic2();
    }

    @Test
    void templateMethodV1() {
        AbstractTemplate template1 = new SubClassLogic1();
        template1.execute();

        AbstractTemplate template2 = new SubClassLogic2();
        template2.execute();
    }
}

템플릿 메서드 패턴을 이용하면 공통 로직을 분리할 수 있다.
수정 사항이 있으면 이제 각 부분만 고치면 된다.
- SRP 단일 책임 원칙을 지켜 변경에 유리하다.


@Slf4j
public class TemplateMethodTest {
    @Test
    void templateMethodV2() {
        AbstractTemplate template1 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("비즈니스 로직1 실행");
            }
        };

        template1.execute();
    }
}

템플릿 메서드 패턴은 서브 클래스를 계속 만들어야 하는 단점이 있다.
익명 내부 클래스를 활용하면 편리하게 사용할 수 있다.

단점

템플릿 메서드 패턴은 상속을 사용하기 때문에 상속에서 오는 단점을 그대로 가진다.
자식 클래스가 부모 클래스와 컴파일 시점에 강결합된다.
- 자식 클래스 입장에서는 부모 클래스 기능을 전혀 사용하지 않는데 상속을 다 받아야 한다.
- 결국 이건 의존 관계에 대한 문제다.
- 자식 클래스에는 부모 클래스가 extends 옆에 선언되어 있으므로 부모를 사용하지 않아도 강하게 의존한다.
  - 강하게 의존한다 = 자식 클래스 코드에 부모 클래스가 명확하게 적혀있다.
  - 부모 클래스에 뭔가 추가되거나 수정되면 자식에도 영향을 준다.

전략 패턴

템플릿 메서드 패턴과 비슷한 기능을 하면서 상속의 단점을 제거할 수 있는 패턴이다.

public interface Strategy {
    void call();
}

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

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

변하지 않는 로직을 context에 두고 strategy 인터페이스에만 의존한다.
- 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.
스프링 의존 관계 주입에서 사용하는 방식이 바로 이 전략 패턴이다.


@Slf4j
public class ContextV1Test {

    @Test
    void strategyV1() {
        StrategyLogic1 strategyLogic1 = new StrategyLogic1();
        ContextV1 contextV1 = new ContextV1(strategyLogic1);
        contextV1.execute();
    }

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

        ContextV1 contextV1 = new ContextV1(strategy);
        contextV1.execute();
    }

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

    @Test
    void strategyV4() {
        ContextV1 contextV1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
        contextV1.execute();
    }
}

구현체를 정의하거나 익명 내부 클래스, 람다를 사용할 수 있다.
선조립 후실행 방식에서 유용하다.
- 조립한 이후에는 execute()만 실행하면 된다.
- 그 이후엔 조립에 대해 더 이상 고민하지 않아도 된다.
- 스프링에서 애플리케이션 로딩 시점에 의존 관계 주입을 모두 마쳐둔 다음 실제 요청을 처리하는 것과 같은 원리다.

단점

조립한 이후에는 전략을 변경하기가 번거롭다.
Context를 싱글톤으로 사용한다면 동시성 이슈가 있어 고려할 게 많아진다.
전략을 실시간으로 변경해야 하면 차라리 다른 Context 하나를 생성하는 게 낫다.

// 파라미터에 전략을 보관하는 방식
@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);
    }
}

@Slf4j
public class ContextV2Test {

    @Test
    void strategyV1() {
        ContextV2 context = new ContextV2();
        context.execute(new StrategyLogic1());
    }

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

그때그때 파라미터로 인수를 전달해서 유연하게 실행할 수도 있다.
하지만 역시 실행할 때마다 전략을 지정해줘야 한다.

템플릿 콜백 패턴

앞서 배운 내용에서 컨텍스트는 변하지 않는 템플릿 역할을, 변하는 부분은 파라미터로 넘어온 전략의 코드를 실행해서 처리한다.
이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백이라고 한다.
스프링에서는 ContextV2 같은 방식의 전략 패턴을 템플릿 콜백 패턴이라고 한다.
- GoF 패턴은 아니고, 스프링 내부에서 이런 방식을 자주 사용하기 때문에 스프링 안에서만 이렇게 부른다.
- 스프링에 Template이 붙은 클래스가 있다면 템플릿 콜백 패턴으로 만들어져 있다고 생각하면 된다.

Previous스레드 로컬 Next프록시 패턴과 데코레이터 패턴

Last updated 3 months ago

Was this helpful?