GoF 디자인패턴) Template Method Pattern

HG Choi·2021년 10월 10일
0

GoF 디자인패턴

목록 보기
4/5

의도

  • 객체의 연산에는 알고리즘의 뼈대만을 정의하고, 각 단계에서 수행할 구체적인 처리는 서브 클래스 쪽으로 미룬다.

  • 팩토리 메소드 패턴과 매우 유사하다.

팩토리 메소드 패턴

동기

  • 팩토리 메소드와 동일한 예제인 Document와 Application 추상 클래스를 예시로 든다.
  • 필수 처리 절차를 정의한 OpenDocument()를 가리켜 템플릿 메서드라고 지칭
  • OpenDocument() 안에 있는 실제 실행하는 연산들에 대한 구현은, Application 클래스를 상속하는 서브클래스가 담당한다.

활용성

  • 알고리즘을 이루는 부분 중 변하지않는 부분을 한번 정의해놓고 다양해질 수 있는 부분은 서브 클래스에서 정의 할 수 있도록 남겨두고자 할 때
  • 서브 클래스 사이의 공통적인 행동을 추출하여 하나의 공통 클래스에 몰아 놓아서 코드 중복을 피하고자 할 때
  • 서브 클래스의 확장을 제어할 수 있음. (제약을 둘 수 있음)

구조

참여자

  • AbstractClass(Application)
    • 서브 클래스들이 재정의를 통해 구해해야하는 알고리즘 처리 단계 내의 기본연산을 정의 + 알고리즘의 뼈대에 해당하는 템플릿 메서드 정의
  • ConcreteClass(MyApplication)
    • 서브 클래스마다 달라진 알고리즘 처리 단계를 수행하기 위한 기본 연산을 구현

협력방법

ConcreteClass는 AbstractClass를 통하여 알고리즘의 변하지 않는 처리 단계를 구현한다.

결과

  • 코드 재사용을 위한 기본 기술. 특히, 클래스 라이버리 구현 시 중요한 기술이다. 라이브러리에 정의할 클래스들의 공통 부분을 분리하는 수단
  • 부모가 자식을 호출하지만 자식은 부모를 호출 할 수 없음
  • 템플릿 메소드는 여러 method 중 하나를 호출함
    • 구체 연산(Concrete operation)
    • Abstract 구체 연산
    • 기본 연산 (추상화 된 연산)
    • 팩토리 메소드
    • 훅 연산

구현

  • 템플렛 메서드에서 호출하는 기본 연산들은 protected로 구현
  • 템플렛 메서드는 override 하면 안됨
  • 오버라이드 해야하는 기본연산은 abstract로 구현
  • override 해야하는 기본연산들은 최소화하는게 좋음
  • 재정의가 필요한 연산들은 Do로 시작하는 method 로 이름을 정의한다.

실제 내가 해본 구현

  • 오늘도 Pizza를 예제로 만들어보았다.

  • AbstractPizzaClass 를 만들었고, 피자 제조 공정은 prepare, addTopping, add cheese,package 4가지 공정이 있다고 가정한다.

  • 그중에서 addTopping과 add Cheese 공정은 각 분점에서 알아서 하게끔 하고 싶을 때 template method Pattern에 위임한다는 점

  • AbstractPizzaClass

public abstract class AbstractPizzaClass {
    // protected 선언이 일반적
    protected abstract void doAddTopping();

    protected abstract void doAddCheese();

    private void preparePizza() {
        System.out.println("Prepare Pizza");
    }

    private void packagingPizza() {
        System.out.println("Packaging Pizza");
    }

    // Template Method. 큰 틀은 부모가 정해놓고, 세부 공정은 Concrete가 하도록 abstract class로 구현
    public void templateMethod() {
        preparePizza();

        addTopping();
        addCheese();

        packagingPizza();
    }

}
  • SeoulPizzaClass
// 구체적인 행동(addTopping, addCheese 메소드만 정의하고 나머지는 부모에게 맡김) 
public class SeoulPizzaClass extends AbstractPizzaClass {
    @Override
    protected void doAddTopping() {
        System.out.println("add Seoul Pizza Topping");
    }

    @Override
    protected void doAddCheese() {
        System.out.println("add Seoul Cheese Topping");
    }

}

총평

  • Factory Method Pattern과 매우 유사하고 많이들 사용하는 패턴인듯.
  • 다른 점은 Template Method Pattern은 행동을 ConcreteClass에 위임하지만, Factory Method Pattern은 Product의 생성을 위임한다는 점이다.
  • 사실 디자인 패턴을 모르더라도 다들 개발하다보면 알게모르게 쓰고 있었을 것이다. 엄연히 구분하는게 무슨의미냐 싶다만은, 또 바로바로 디자인 패턴을 떠올리려면 구체적인 차이점에 대해서 정확하게 이해하는게 필요한 것 같기도 하다.
profile
잘하고 싶은 백앤드 개발자

0개의 댓글

관련 채용 정보