자바 템플릿 메소드 패턴

뤼튼의 검색 결과를 통해 얻은 코드 예시

 

```java

// 추상 클래스: PizzaMaker
abstract class PizzaMaker {
    // 템플릿 메서드: makePizza
    public final void makePizza() {
        prepareDough();
        addToppings();
        bakePizza();
    }

    // 도우 준비 단계
    protected void prepareDough() {
        System.out.println("도우를 준비합니다.");
    }

    // 토핑 추가 단계 (추상 메서드)
    protected abstract void addToppings();

    // 피자 굽기 단계
    protected void bakePizza() {
        System.out.println("피자를 굽습니다.");
    }
}

// 서브클래스: CheesePizzaMaker
class CheesePizzaMaker extends PizzaMaker {
    // 오버라이딩된 토핑 추가 단계
    @Override
    protected void addToppings() {
        System.out.println("치즈를 추가합니다.");
    }
}

// 서브클래스: PepperoniPizzaMaker
class PepperoniPizzaMaker extends PizzaMaker {
    // 오버라이딩된 토핑 추가 단계
    @Override
    protected void addToppings() {
        System.out.println("페퍼로니를 추가합니다.");
    }
}

// 메인 클래스
public class Main {
    public static void main(String[] args) {
        // 치즈 피자 생성 및 제작
        PizzaMaker cheesePizzaMaker = new CheesePizzaMaker();
        cheesePizzaMaker.makePizza();

        System.out.println();

        // 페퍼로니 피자 생성 및 제작
        PizzaMaker pepperoniPizzaMaker = new PepperoniPizzaMaker();
        pepperoniPizzaMaker.makePizza();
    }
}

```

 

이 패턴의 장점은

 

if. 알고리즘 구성의 내부 로직을 변경해야 하는 일이 생김

=> 알고리즘의 단계 중 일부를 변경 가능하도록 구성해 전체 구성을 유지하며 보수할수 있음. OCL을 아주 잘 지킴

=> 이번에 작업한 TC도 단일하게 특정 단계들을 거치며 돌아가는 프로세스라 위 패턴을 도입하는 것도 가능할것 같음

=> 아닌가..? 단계는 동일하지만 내부 구현 로직이 다 다르니까 사실상 의미가 없나.. 싶기도 하다. 굳이 depth만 늘리는 느낌.