[20230219] 템플릿 메서드 패턴

[cme10575]

[20230219]

템플릿 메서드 패턴

: 변하는 것과 변하지 않는 것을 분리

• 부모클래스에 변하지 않는 골격을 정의해두고 자식클래스에 변하는 로직을 정의해둠
• 단일책임원칙 만족 (단일책임원칙은 변경이 필요할 때 준수되었는지 드러남)

한계

• 자식과 부모가 강결합됨
• 상속에서 오는 단점을 그대로 가져감
• 자식 입장에서 부모 로직 사용안하는데, 부모클래스 기능을 모두 가지고 있는 형태 --> 전략 패턴으로 해소 가능

참고) 리턴값 설정 제네릭을 통해서 해결가능함

• AbstractTemplate 로 만들어두면, 클래스를 만들 때 type을 넣어줄 수 있음
• 메서드의 반환값을 T로 두면 반환값 세팅 가능
• void의 객체타입은 "Void"

참고) 익명 내부클래스

• 익명 내부클래스로 만들면 매번 클래스 파일을 따로 분리해서 작성할 필요 없음

질문

타입 설정은 클래스단위인데, execute 리턴은 메서드 단위임 두 개 이상의 메서드가 있고 각각 다른 타입을 리턴하고 싶으면 어떡하는지? AbstractTemplate<T, A> 이렇게 받아 메서드마다 설정하기엔 직관적이지 않은 듯... 실제로 쓰이는지?

UML 잘 모르는데 메서드 앞 +, # 어떤 의미인지?

[20230226]

되돌아보는 우리의 목적

• 공통 로직을 여러 메서드에 추가
• 공통 로직을 추가할 때 기존 로직을 최대한 수정하지 않도록 함
• 공통 로직이 중복되지 않게 함
• 공통 로직과 비즈니스 로직이 섞이지 않게 함

전략 패턴

• 변하지 않는 부분(공통로직)은 context, 변하는 부분(비즈니스 로직)은 strategy 인터페이스를 만들고 해당 인터페이스를 구현해서 위임
• Context 안에서 strategy를 사용하고 호출부는 Context 사용
• 스프링에서 기본으로 채택하고 있는 패턴
• 클라이언트와 독립적으로 알고리즘 변경 가능

한계

• strategy를 필드로 가지는 Context 조립 끝낸 이후에, 전략을 변경하기 번거로움
• 세터주입으로 변경할 수 있겠지만, 만약 Context를 싱글톤으로 사용하면 동시성 이슈가 생길 수 있어, 새로 Context를 만드는 게 나을 것임
• 더 유연하게 전략 바꿀 수는 없을까? -> 실행하는 시점에 전략을 파라미터로 전달하기

템플릿 콜백 패턴

템플릿

• 변하는 코드와 변하지 않는 코드를 구분하는 것

콜백

• 다른 코드의 인수로 넘겨주는 실행 가능한 코드 (예시: 위의 strategy)
• call되는데, 넘겨준 코드의 뒤쪽(back)에서 실행된다

템플릿 콜백 패턴

• 스프링에서 비즈니스 로직 클래스를 함수 파라미터로 받아 실행하는 패턴 (GoF의 패턴은 아니고, 스프링에서 이 방식을 자주 사용해 스프링에서 이렇게 부름)
• 전략패턴에서 템플릿과 콜백이 강조된 패턴
• 스프링의 xxxTemplate으로 네이밍된 클래스는 이 템플릿 콜백 패턴이 적용됨
• 디자인 패턴은 의도가 중요, 필드로 인수를 가지든지(전략) 파라미터로 받든지(템플릿 콜백)는 선택. 의도를 만족하면 됨.

한계

• 기존 로직에 손을 안 댈 수는 없음
• 본질적으로 코드를 수정해야 하는 것은 마찬가지 -> 프록시를 이용해 원본코드를 수정하지 않는 방법이 있다! to be continued..

기타

단축키

인라인

• command option v

실행

• ctrl shift R

[jin-ryu]

핵심 기능 vs. 부가 기능

• 핵심 기능: 해당 객제가 제공하는 고유의 기능
• 부가 기능: 핵심 기능을 보조하기 위해 제공되는 기능 (ex. 로그 추적 로직, 트렌젝션 기능 등)
  • 부가 기능은 단독으로 사용되지는 않고 핵심 기능과 함께 사용된다.

변하는 것과 변하지 않는 것을 분리

• 좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것
• 여기서 핵심 기능 부분은 변하고, 로그 추적기를 사용하는 부분은 변하지 않는 부분이다 → 이 둘을 분리해서 모듈화 해야 한다.
• 템플릿 메서드 패턴(Template Method Pattern)은 이런 문제를 해결하는 디자인 패턴이다.

템플릿 메서드 패턴 구조 그림

• 템플릿 메서드 패턴은 이름 그대로 템플릿응 사용하는 방식이다. 템플릿은 기준이 되는 거대한 틀이다. 템플릿이라는 틀에 변하지 않은 부분을 몰아둔다. 그리고 일부 변하는 부분은 별도로 호출해서 해결한다.
• 템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿 코드를 둔다. 그리고 변하는 부분은 자식 클래스에 두고 상속과 오버라이딩을 사용해서 처리한다.

템플릿 메서드 패턴 인스턴스 호출 그림

• AbstractTemplate 클래스의 call() 메서드는 SubClassLogic1 클래스에 오버라이딩 되어 있다. 따라서 오버라이딩 된 call() 메서드가 호출된다.
• 변하지 않는 부분을 AbstractTemplate에 몰아두었기 때문에, 이 부분이 변경되었을 때 수정 포인트가 줄어든다! → 변하지 않는 부분과 변하는 부분을 분리해야 하는 이유

익명 내부 클래스 사용하기

• 템플릿 메서드 패턴을 클래스를 계속 만들어야 하는 단점이 있다. 익명 내부 클래스를 사용하면 이런 단점을 보완할 수 있다.
• 익명 내부 클래스를 사용하면 객체 인스턴스를 생성하면서 동시에 생성할 클래스를 상속 받은 자식 클래스를 정의할 수 있다. 이 클래스는 직접 지정하는 이름이 없고, 클래스 내부에서 선언되는 클래스여서 익명 내부 클래스라 한다.

@Test
    void templateMethodV2(){
        AbstractTemplate template1 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("비즈니스 로직 1 실행");
            }
        };
        log.info("클래스 이름1={}", template1.getClass());
        template1.execute();

        AbstractTemplate template2 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("비즈니스 로직 2 실행");
            }
        };
        log.info("클래스 이름2={}", template2.getClass());
        template2.execute();
    }

• 익명 내부 클래스 이름은 TemplateMethodTest$1, TemplateMethodTest$2 이런 식으로 자바에서 임의로 만들어준다.

템플릿 메서드 패턴 적용

• AbstractTemplate 은 템플릿 메서드 패턴에서 부모 클래스이고, 템플릿 역할을 한다.
• <T> 제네릭을 사용했다. 반환 타입을 정의한다.
• 객체를 생성할 때 내부에서 사용할 LogTrace trace 를 전달 받는다.
• 로그에 출력할 message 를 외부에서 파라미터로 전달받는다.
• 템플릿 코드 중간에 call() 메서드를 통해서 변하는 부분을 처리한다.
• abstract T call() 은 변하는 부분을 처리하는 메서드이다. 이 부분은 상속으로 구현해야 한다.
• AbstractTemplate<Void>
  • 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면 Void 타입을 사용하고 null 을 반환하면 된다. 참고로 제네릭은 기본 타입인 void , int 등을 선언할 수 없다.

좋은 설계란?

• 좋은 설계라는 것은 무엇일까? 수 많은 멋진 정의가 있겠지만, 진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
• 지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 그래서 여기서 로그 남기는 부분을 변경해야 한다면, AbstractTemplate 만 수정하면 된다.

단일 책임 원칙(SRP)

• 로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다. 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.

템플릿 메서드 패턴 - 정의

템플릿 메서드 디자인 패턴의 목적은 다음과 같습니다.

"작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다." [GOF]

• 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.
• 하지만 (- 템플릿 메서트 패턴의 단점)
• 템플릿 메서드 패턴은 상속을 사용한다. 따라서 상속에서 오는 단점들을 그대로 안고간다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합(의존 관계가 생성)되는 문제가 있다.
• 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하기 적혀 있다는 것이다.
• 이번 코드에서 자식 클래스는 부모 클래스의 기능을 하나도 사용하고 있지 않지만, 템플릿 메서드 패턴을 위해 부모 클래스를 상속받고 있다.
• 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야 한다. 이것은 좋은 설계가 아니다. 그리고 이런 잘못된 의존관계 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향을 줄 수 있다. (ex. 부모 클래스에 메서드를 하나 더 생성하면, 자식 클래스들은 전부 그 메서드를 오버라이드 해야한다.)
• 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴(Strategy Pattern)이다.

[LeeeeDain]

세션3 - 템플릿 메서드 패턴과 콜백 패턴

1. 템플릿 메서드 패턴
2. 전략 패턴
3. 템플릿 콜백 패턴

템플릿 메서드 패턴

• 핵심기능(변하는 부분)과 부가기능(변하지 않는 부분)을 분리하는 패턴

• 구현 방법

  • 추상클래스인 템플릿에 변하지 않는 로직들을 다 모아놓음
  • 변하는 부분은 자식클래스에서 오버라이드하도록 구현

• 예시

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

• 단점

  • SubClassLogic1, SubClassLogic2 처럼 추상클래스를 상속받은 클래스를 계속 만들어내야 함

  => 익명 내부 클래스를 사용하면 보완 가능

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

  • 상속. 부모 클래스의 기능을 사용하지 않아도 이 패턴을 만들기 위해 의존하게 된다. 변하지 않는 부분이 있는 부모 클래스가 바뀌면 자식 클래스에 영향이 있다.

  => 전략 패턴을 사용해 상속의 단점을 제거

• 장점

  • 템플릿으로 분리함으로써 trace 관련 로그 출력 로직이 변경되어도 템플릿 추상클래스만 고치면 된다. 단일책임원칙(SRP)를 잘 지키며 설계한 것.

전략 패턴

• 구현 방법

  • 상속이 아닌 위임으로 문제 해결
  • 변하지 않는 부분을 Context 라는 곳에 두고 변하는 부분을 Strategy 라는 인터페이스로 만들기
  • 스프링 의존관계 주입에서 사용하는 방법

• 예시

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

  public interface Strategy {
      void call();
  }

• 장점

  • 변하지 않는 부분이 있는 Context가 바뀌어도 Strategy를 상속받은 자식클래스에 영향이 없다.

• 단점

  • 생성자로 Strategy를 받으면 선조립, 후실행. Context와 Strategy를 한번 조립하고 나면 Strategy를 변경하기 어렵다. 차라리 Context를 하나 더 생성하는게 나을 수도 있다.

  => 메소드의 파라미터로 Strategy를 받으면 Context를 실행할 때마다 Strategy를 파라미터로 전달한다. 원하는 Strategy를 유연하게 변경 가능

  ​ => 단점. 실행할 때마다 전략 지정해야하는게 번거롭다. 실습예제는 이 방법이 더 적합.

템플릿 콜백 패턴

• 구현 방법

  • 변하지 않는 부분을 Template, 변하는 부분은 실행 가능한 코드 형태의 Callback을 파라미터로 넘겨주기
  • 콜백은 주로 람다로 구현
  • 스프링에서 xxxTemplate 이 있다면 템플릿 콜백 패턴으로 만들어져 있다고 생각하면 된다.

• 예시

  • public interface Callback {
    void call();
    }

  • @Slf4j
    public class TimeLogTemplate {
    
    public void execute(Callback callback) {
        long startTime = System.currentTimeMillis();
        // 비즈니스 로직 실행
        callback.call();
        // 비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
    }

  • @Test
    void callbackV1() {
    TimeLogTemplate template = new TimeLogTemplate();
    template.execute(() -> log.info("비즈니스 로직1 실행"));
    template.execute(() -> log.info("비즈니스 로직2 실행"));
    }

한계

• 패턴들을 적용하기 위해 기존 코드들을 전부 수정해야한다.

참고

• 제네릭 T
  • 타입에 대한 정보를 객체를 생성할 때 결정할 수 있도록 미룸

[kdhooon]

템플릿 메서드 패턴(V4)

v4: 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다. -> 변하는 것과 변하지 않는 것을 분리해서 모듈화 하는것이 중요 v4의 템플릿 메서드 패턴을 사용한 덕분에 핵심 기능에 좀 더 집중 할 수 있었다.

좋은 설계란?


좋은 설계라는 것은 무엇일까? 수 많은 멋진 정의가 있겠지만, 진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
 지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자. 그래서 AbstractTemplate 코드를 변경해야 한다 가정해보자. 단순히 AbstractTemplate 코드만 변경하면 된다.
템플릿이 없는 V3 상태에서 로그를 남기는 로직을 변경해야 한다고 생각해보자. 이 경우 모든 클래스를 다 찾아서 고쳐야 한다. 클래스가 수백 개라면 생각만해도 끔찍하다.

단일 책임 원칙(SRP)


V4 는 단순히 템플릿 메서드 패턴을 적용해서 소스코드 몇줄을 줄인 것이 전부가 아니다. 
로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다. 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.

템플릿 메서드 패턴

• 작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기한다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있다.
• 상속을 사용 즉, 상속에서 오는 단점들을 그대로 안고 간다. -> 자식 클래스가 부모 클래스와 컴파일 시점에강하게 결합돼 자식 클래스 입장에서는 부모 클래스 기능을 전혀 사용하지 않는다.
• 자식클래스가 부모클래스의 기능을 사용하지 않아도 부모클래스를 상속받아야함
• 부모클래스의 기능을 사용하지 않는데 강하게 상속돼 있는것은 좋은 설계가 아니다.
• 상속 구조를 사용하기 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향을 줄 수 있다.