3. 템플릿 메서드 패턴과 콜백 패턴
템플릿 메서드 패턴
템플릿 메서드 패턴 - 시작
로그 추적기를 막상 프로젝트에 도입하려고 하니 개발자들의 반대의 목소리가 높다.
핵심 기능 vs 부가 기능
핵심 기능은 해당 객체가 제공하는 고유의 기능이다.
예를 들어서 orderService 의 핵심 기능은 주문 로직이다. 메서드 단위로 보면 orderService.orderItem() 의 핵심 기능은 주문 데이터를 저장하기 위해 리포지토리를 호출하는 orderRepository.save(itemId) 코드가 핵심 기능이다.
부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다.
예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 부가 기능은 단독으로 사용되지는 않고, 핵심 기능과 함께 사용된다. 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용한다. 그러니까 핵심 기능을 보조하기 위해 존재한다.
V3를 보면 로그 추적기의 도입으로 핵심 기능 코드보다 부가 기능을 처리하기 위한 코드가 더 많아졌다.
Controller , Service , Repository 의 코드를 잘 보면, 로그 추적기를 사용하는 구조는 모두 동일하다. 중간에 핵심 기능을 사용하는 코드만 다를 뿐이다.
부가 기능 관련 코드가 중복이니 중복을 별도의 메서드로 뽑아내면 될 것 같지만, try ~ catch 는 물론이고, 핵심 기능 부분이 중간에 있어서 단순하게 메서드로 추출하는 것은 어렵다.
변하는 것과 변하지 않는 것을 분리
좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이다.
- 변하는 부분: 핵심 기능
- 변하지 않는 부분: 로그 추적기를 사용하는 부분
이 둘을 분리해서 모듈화해야 한다.
=> 템플릿 메서드 패턴(Template Method Pattern)은 이런 문제를 해결하는 디자인 패턴이다.
템플릿 메서드 패턴 - 예제1
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);
}
- 변하는 부분: 비즈니스 로직
- 변하지 않는 부분: 시간 측정
템플릿 메서드 패턴 - 예제2
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();
}AbstractTemplate(추상 클래스)
execute() 에 변하지 않는 부분을 몰아넣고 변하는 부분( call() ) 을 별도로 호출
자식 클래스에서 call() (추상 메서드)를 오버라이드 하고 execute() 을 호출
AbstractTemplate 을 상속받은 자식 클래스
@Slf4j
public class SubClassLogic1 extends AbstractTemplate{
@Override
protected void call() {
log.info("비지니스 로직1 실행");
}
}@Slf4j
public class SubClassLogic2 extends AbstractTemplate{
@Override
protected void call() {
log.info("비지니스 로직2 실행");
}
}
템플릿 메서드 패턴 테스트
@Test
void templateMethodV1(){
AbstractTemplate template1 = new SubClassLogic1();
template1.execute();
AbstractTemplate template2 = new SubClassLogic2();
template2.execute();
}
비즈니스 로직1 실행
resultTime=0
비즈니스 로직2 실행
resultTime=1
AbstractTemplate template1 = new SubClassLogic1();
template1.execute() 를 호출하면 템플릿 로직인 AbstractTemplate.execute() 를 실행한다. 여기서 중간에 call() 메서드를 호출하는데, 이 부분이 오버라이딩 되어있다. 따라서 실제 인스턴스인 SubClassLogic1 의 call() 메서드가 호출된다.
템플릿 메서드 패턴은 이렇게 다형성을 사용해서 변하는 부분과 변하지 않는 부분을 분리하는 방법이다.
템플릿 메서드 패턴 - 예제3
익명 내부 클래스(Anonymous Inner Class) 사용하기
템플릿 메서드 패턴은 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();
}
자바가 임의로 만들어주는 익명 내부 클래스 이름은 TemplateMethodTest$1 , TemplateMethodTest$2 인 것을 확인할 수 있다. 일반적으로 클래스 정보에서 $는 이너 클래스를 의미한다.
참고: 추상 클래스( abstract class )는 일반적으로 객체를 생성할 수 없지만, 익명 클래스( anonymous class )처럼 생성과 동시에 추상 메서드를 오버라이딩 한다면 객체를 생성할 수 있다.
템플릿 메서드 패턴 - 적용1
로그 추적기 용 템플릿 클래스
public abstract class AbstractTemplate<T> {
private final LogTrace trace;
public AbstractTemplate(LogTrace trace) {
this.trace = trace;
}
//반환 타입 정의를 객체 생성 시점으로 미룸
public T execute(String message){
TraceStatus status = null;
try{
status = trace.begin(message);
//로직 호출
T result = call();
trace.end(status);
return result;
} catch (Exception e){
trace.exception(status, e);
throw e;
}
}
protected abstract T call();
}
- AbstractTemplate 은 템플릿 메서드 패턴에서 부모 클래스이고, 템플릿 역할을 한다.
- 컨트롤러, 서비스, 리포지토리에서 핵심 로직의 반환 값이 다르므로 메서드의 반환 타입으로 <T> 제네릭을 사용했다.
- 객체를 생성할 때 내부에서 사용할 LogTrace trace 를 컴포넌트(D.I)로부터 전달 받는다.
- 로그에 출력할 message 를 외부에서 파라미터로 전달받는다.
- 템플릿 코드 중간에 call() 메서드를 통해서 변하는 부분을 처리한다.
- abstract T call() 은 상속으로 구현해야 한다.
템플릿 메서드 패턴 적용 (컨트롤러)
@RestController
@RequiredArgsConstructor
public class OrderControllerV4 {
private final OrderServiceV4 orderService;
private final LogTrace trace;
@GetMapping("/v4/request")
public String request(String itemId){
AbstractTemplate<String> template = new AbstractTemplate<>(trace){
@Override
protected String call() {
orderService.orderItem(itemId);
return "ok";
}
};
return template.execute("OrderController.request()");
}
}
- AbstractTemplate<String>: AbstractTemplate 의 반환 타입 String 이 된다.
- 익명 내부 클래스: 객체를 생성하면서 AbstractTemplate 를 상속받은 자식 클래스를 정의했다.
- template.execute("OrderController.request()") : 템플릿을 실행하면서 로그로 남길 message 를 전달한다.
템플릿 메서드 패턴 적용 (서비스)
@Service
@RequiredArgsConstructor
public class OrderServiceV4 {
private final OrderRepositoryV4 orderRepository;
private final LogTrace trace;
public void orderItem(String itemId){
AbstractTemplate<Void> template = new AbstractTemplate<>(trace){
@Override
protected Void call() {
orderRepository.save(itemId);
return null;
}
};
template.execute("OrderRepository.orderItem()");
}
}
- AbstractTemplate<Void> : 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면 Void 타입을 사용하고 null 을 반환한다. 참고로 제네릭은 기본 타입인 void , int 등을 선언할 수 없다.
템플릿 메서드 패턴 - 적용2
OrderServiceV0 : 핵심 기능만 있다.
OrderServiceV3 : 핵심 기능과 부가 기능이 함께 섞여 있다.
OrderServiceV4 : 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다.
V4는 템플릿 메서드 패턴을 사용한 덕분에 핵심 기능에 좀 더 집중할 수 있게 되었다.
좋은 설계란?
진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자. 단순히 AbstractTemplate 코드만 변경하면 된다. 템플릿이 없는 V3 상태에서 로그를 남기는 로직을 변경해야 할 경우, 모든 클래스를 다 찾아서 고쳐야 한다.
단일 책임 원칙(SRP)
V4 는 단순히 템플릿 메서드 패턴을 적용해서 소스코드 몇 줄을 줄인 것이 전부가 아니다.
로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다. 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만들었다.
템플릿 메서드 패턴 - 정의
GoF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의했다.
작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기한다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있다.
부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다. 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.
하지만 템플릿 메서드 패턴은 상속을 사용한다.
따라서 상속에서 오는 단점들을 그대로 안고간다.
특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않음에도 템플릿 메서드 패턴을 위해 부모 클래스를 의존하고 있다.
(오히려 부모 클래스는 자식 클래스를 모르지만 이후 오버라이드 될 call() 을 호출함으로서 자식 클래스의 기능을 사용하고 있다. 이것은 다형성에 의해 가능한 일)
자식 클래스의 extends 다음에 바로 부모 클래스가 코드상에 지정되어 있다. 따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻이다. UML에서 상속을 받으면 삼각형 화살표가 자식 -> 부모 를 향하고 있는 것은 이런 의존관계를 반영하는 것이다.
이것은 좋은 설계가 아니다. 잘못된 의존관계 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향을 줄 수 있다.
추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다.
템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴(Strategy Pattern)이다.
전략 패턴
전략 패턴 - 예제1
탬플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결했다.
전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다. 상속이 아니라 위임으로 문제를 해결하는 것이다.
전략 패턴에서 Context 는 변하지 않는 템플릿 역할을 하고, Strategy 는 변하는 알고리즘 역할을 한다.
GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.
알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.
ContextV1 클래스
/**
* 필드에 전략을 보관하는 방식
*/
@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);
}
}ContextV1 은 템플릿 역할을 하는 코드이다. 전략 패턴에서는 이것을 컨텍스트(문맥)이라 한다. 크게 변하지 않는 문맥 속에서 strategy 를 통해 일부 전략이 변경된다.
Context 는 내부에 Strategy strategy 필드를 가지고 있다. 이 필드에 변하는 부분인 Strategy 의 구현체를 주입한다.
전략 패턴의 핵심은 Context 는 Strategy 인터페이스에만 의존한다는 점이다. 따라서 Strategy 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.
스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴이다.
Strategy 인터페이스
public interface Strategy {
void call();
}
Strategy 구현체 1
@Slf4j
public class StrategyLogic1 implements Strategy{
@Override
public void call() {
log.info("비지니스 로직1 실행");
}
}
Strategy 구현체 2
@Slf4j
public class StrategyLogic2 implements Strategy{
@Override
public void call() {
log.info("비지니스 로직2 실행");
}
}
전략 패턴 테스트 코드
@Test
void strategyV1(){
StrategyLogic1 strategyLogic1 = new StrategyLogic1();
ContextV1 context1 = new ContextV1(strategyLogic1);
context1.execute();
StrategyLogic2 strategyLogic2 = new StrategyLogic2();
ContextV1 context2 = new ContextV1(strategyLogic2);
context2.execute();
}
원하는 Strategy 구현체를 Context에 주입하고 context1.execute() 를 호출하여 context 를 실행한다.
