[Spring] 디자인 패턴 - 템플릿 메서드 패턴

이번 글에서는 김영한님의 스프링 핵심 원리 - 고급편에서 배운 내용을 바탕으로 스프링에서 자주 사용하는 디자인패턴에 대해 정리하려고 합니다.

 

디자인 패턴이란 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것이다. 이 디자인 패턴을 사용하여 문제점을 해결하고 좋은 설계를 통해 유지보수하기 쉬운 코드를 작성할 수 있다.

 

강의에서는 좋은 설계란 변하는 것과 변하지 않는 것을 분리하는 것이라고 설명하고 있었다. 즉, 핵심 기능과 부가 기능을 따로 분리하여 모듈화 함으로써 하나의 클래스는 하나의 책임만 갖고 해당 클래스를 변경하는 이유는 오직 하나뿐이어야 한다는 단일 책임 원칙을 지키는 것을 강조하고 있었다. 이번 글에서 다룰 템플릿 메서드 패턴은 이러한 원칙을 지키기 쉽게 해주는 디자인 패턴이다.

템플릿 메서드 패턴

템플릿 메서드 패턴은 작업에서 알고리즘의 골격을 정의하고 상속을 사용하여 일부 단계를 하위 클래스로 연기하는 패턴으로 핵심 기능이 포함된 추상클래스를 생성하고 해당 추상클래스에서 핵심로직을 추상메서드로 선언한 뒤 이를 상속받아 재정의함으로써 핵심기능과 부가기능을 분리하는 디자인 패턴이다.

문제 코드

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

 

위 코드에서 logic1()과 logic2()는 아래와 같이 중복되는 코드가 존재한다. 해당 코드는 부가 기능으로 두 logic에서 동일한 기능을 수행한다. 이러한 설계는 만약 부가 기능을 사용하는 logic이 100개가 존재할 때 이 부가 기능을 수정하려면 100개의 logic을 모두 수정해주어야 하기 때문에 좋은 방법이 아니다. 만약 공통된 코드를 추출하여 하나의 클래스로 관리할 수 있다면 부가 기능을 수정할 때 해당 클래스만 수정해주면 되기 때문에 유지보수하기 쉬워진다.

 

long startTime = System.currentTimeMillis();

...

long endTime = System.currentTimeMillis();
long resultTime = endTime - startTime;
log.info("resultTime = {}", resultTime);

템플릿 메서드 패턴 적용

AbstractTemplate

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

공통 로직을 추출한 추상클래스이다. 비즈니스 로직 부분을 call()이라는 추상메서드로 선언하였다.

 

SubClassLogic

@Slf4j
public class SubClassLogic1 extends AbstractTemplate {

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

추상클래스(AbstractTemplate)을 상속받아 call() 메서드를 재정의 하였다.

 

테스트코드

@Slf4j
public class TemplateMethodTest {

    /**
     * 템플릿 메서드 패턴 적용
     */
    @Test
    void templateMethodV1() {
        AbstractTemplate template1 = new SubClassLogic1();
        template1.execute();

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

AbstractTemplate 추상클래스를 상속받는 SubClassLogic1(), SubClassLogic2() 객체 인스턴스를 생성하고 execute() 메서드를 실행하면 아래와 같이 템플릿 메서드 패턴을 적용하기 전과 동일한 결과를 확인할 수 있다.

 

 

하지만 이 방법은 비즈니스 로직을 클래스로 계속 만들어야 하는 단점이 있다. 이는 익명 내부 클래스를 사용하여 해결할 수 있다.

익명 내부 클래스란 객체 인스턴스를 생성할 때 상속 받는 자식 클래스를 정의할 수 있는 문법으로 클래스 이름을 따로 선언하지 않아도 된다.

 

@Slf4j
public class TemplateMethodTest {

    /**
     * 익명 내부 클래스
     */
    @Test
    void templateMethodV2() {
        AbstractTemplate template1 = new AbstractTemplate() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        template1.execute();

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

위와 같이 익명 내부 클래스를 사용하면 AbstractTemplate 객체를 생성할 때 call() 메서드를 재정의할 수 있어 클래스 파일을 생성해주지 않아도 된다.

 

이렇게 함으로써 이제 부가 기능을 수정할때는 AbstractTemplate 추상클래스의 execute() 메서드만 수정해주면 된다.

하지만 템플릿 디자인 패턴은 상속을 사용하기 때문에 상속이 가지고 있는 단점들을 그대로 가지고 있다. 특히 부모 클래스와 자식 클래스가 컴파일 시점에 강하게 결합되는 문제가 있다. 자식 클래스는 부모 클래스의 기능을 사용하지 않고 부모 클래스에서 비즈니스 로직인 추상 메서드만 재정의 해주면 되는데 상속을 받아 부모 클래스에 강하기 의존하고 있다. 이러한 의존 관계는 부모 클래스를 수정했을 때 자식 클래스에 영향을 미칠 수 있다. 이를 해결하기 위한 방법으로 비슷한 기능을 수행하면서 상속의 단점을 제거할 수 있는 방법으로 전략 패턴을 사용하는 방법이 있다.