[디자인 패턴] 템플릿 메서드 패턴 (feat. Spring)

템플릿 메서드란?

템플릿 메서드 패턴에 대한 나만의 한줄 요약을 이렇다.

 

변하는 부분과 변하지 않는 부분을 분리하기 위한 패턴.

 

변하는 부분을 자유롭게 구현할 수 있도록 추상 클래스 내에 추상 메서드를 만들어 줌으로 써 이를 구현한다.

변하지 않는 부분은 실제 동작할 클래스에 작성한다.

 

이를 간단히 Spring 내에 구현한 코드로 보면 다음과 같다.

public abstract class TemplateMethodPattern() {
	public void runTemplate() {
    	long startTime = System.currentTimeMillis(); // 변하지 않는 부분
        
        // 비즈니스 로직 실행 (변하는 부분 분리)
        call(); // 상속받은 메서드 실행
        // 비즈니스 로직 종료
        
        long endTime = System.currentTimeMillis(); // 이하 변하지 않는 부분
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
    // 해당 클래스를 상속한 모든 클래스에서 override해 구현할 수 있도록 강제한다.
    protected abstract void call();
}

 

이를 실제로 상속하는 클래스는 다음과 같이 구현된다.

public class LogicImpl1 extends TemplateMethodPattern {
    @Override
    protected void call() {
        log.info("비즈니스 로직 1 실행"); // 변하는 로직
    }
}

public class LogicImpl2 extends TemplateMethodPattern {
    @Override
    protected void call() {
        log.info("비즈니스 로직 2 실행"); // 변하는 로직
    }
}

 

// 실제 실행 예시
void templateMethodImpl() {
    TemplateMethodPattern template1 = new LogicImpl1();
    template1.runTemplate();

    TemplateMethodPattern template2 = new LogicImpl2();
    template2.runTemplate();
}

 

runTemplate 메서드 내의 call 부분을 제외하고는 모든 곳에서 동일한 로직을 실행할 수 있게 되었다.

각각 자신만의 call 메소드를 커스텀해 별도의 변하는 로직을 작성할 수 있게 되었다.

템플릿 메서드 패턴은 이와 같은 장점을 가지고 있는 디자인 패턴이다.

 

템플릿 메서드 패턴의 한계

그렇다면 템플릿 메서드 패턴의 한계점은 무엇일까?

 

템플릿 메서드 패턴은 기본적으로 상속을 사용한다.

따라서 상속에서 오는 단점이 그대로 딸려온다.

 

상단의 코드에서 자식클래스는 오직 패턴 구현을 위해 부모클래스를 상속받고있다.

자식클래스에서 직접적으로 부모클래스의 기능을 사용하는 코드는 없다.

해당 예시는 설명용으로 아주 간결한 코드이지만 코드가 길어지면 이는 효율성에서 문제가 될 수 있다.

 

그렇다면?

이에 대한 대안이 전략 패턴이라고 한다.

전략 패턴은 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이다.

이 패턴은 다음글에서 다뤄보도록 하겠다.