스프링 핵심 원리 - 고급편 - (8) - 템플릿 메서드 패턴 2
인프런 스프링 핵심 원리 - 고급편을 학습하고 정리한 내용 입니다.
지난 시간 템플릿 메서드 패턴의 예제들을 만들어 보면서 감을 익혔다. 오늘은 적용해보자.
템플릿 메서드 패턴 - 적용1
로그 추적기 로직에 템플릿 메서드 패턴을 적용해보자.

해당 템플릿 패키지에 AbstractTemplate 추상 클래스를 만들었다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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를 전달 받는다. - 로그에 출력할
message를 외부에서 파라미터로 전달 받는다. - 템플릿 코드 중간에
call()메서드를 통해서 변하는 부분을 처리한다. abstract T call()은 변하는 부분을 처리하는 메서드이다. 이 부분은 상속으로 구현해야 한다.
v3 → v4 복사
먼저 기존 프로젝트 코드를 유지하기 위해 v4 애플리케이션을 복사해서 만들자.

이름을 인텔리제이 리펙토링 기능을 이용해서 바꿔주자.
이제 템플릿 메서드 패턴을 적용하는데, 익명 메서드로 구현 할 것이고, 컨트롤러, 서비스, 리포지토리 별로 알아보자.
컨트롤러
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@RestController
@RequiredArgsConstructor
public class OrderControllerV4 {
private final OrderServiceV4 orderService;
private final LogTrace trace;
@GetMapping("/v4/request")
public String request(@RequestParam("itemId") String itemId) {
AbstractTemplate<String> template = new AbstractTemplate<>(trace) {
@Override
protected String call() {
orderService.orderItem(itemId);
return "ok";
}
};
return template.execute("OrderControllerV4.request()");
}
}
AbstractTemplate<String>- 제네릭을
String으로 설정했다. 따라서AbstractTemplate의 반환 타입은String이 된다.
- 제네릭을
- 익명 내부 클래스
- 익명 내부 클래스를 사용한다. 객체를 생성하면서
AbstractTemplate를 상속 받은 자식 클래스를 정의했다.call()메서드를 구현한다.
- 익명 내부 클래스를 사용한다. 객체를 생성하면서
template.execute("OrderControllerV4.request()")- 템플릿을 실행 하면서 로그로 남길
message를 전달한다.
- 템플릿을 실행 하면서 로그로 남길

이런 패턴(?) 틀에 맞게 코드를 짤 수 있는 것이다.
서비스
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@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("OrderServiceV4.request()");
}
}
AbstractTemplate<Void>- 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면
Void타입을 사용하고null을 반환하면 된다. - 참고로 제네릭은 기본 타입인
void,int,double등을 선언할 수 없다.
- 제네릭에서 반환 타입이 필요한데, 반환할 내용이 없으면
리포지토리
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
@Repository
@RequiredArgsConstructor
public class OrderRepositoryV4 {
private final LogTrace trace;
public void save(String itemId) {
AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
@Override
protected Void call() {
if (itemId.equals("ex")) {
throw new IllegalStateException("예외 발생!");
}
sleep(1000);
return null;
}
};
template.execute("OrderRepositoryV4.request()");
}
private void sleep(long millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
1
2
3
4
if (itemId.equals("ex")) {
throw new IllegalStateException("예외 발생!");
}
sleep(1000);
이게 핵심 로직이라 가정했기 때문에 이 코드를 call()메서드로 구현한다.
결과

V3와 같은 결과를 출력한다.
템플릿 메서드 패턴 - 적용2
템플릿 메서드 패턴 덕분에 변하는 코드와 변하지 않는 코드를 명확하게 분리했다.
로그를 출력하는 템플릿 역할을 하는 변하지 않는 코드는 모두 AbstractTemplate 에 담아두고, 변하는 코드는 자식 클래스를 만들어서 분리했다.
지금까지 작성한 코드를 비교해보자.
OrderServiceV0

OrderServiceV3

OrderServiceV4

OrderServiceV0: 핵심 기능만 있다.OrderServiceV3: 핵심 기능과 부가 기능이 함께 섞여 있다.OrderServiceV4: 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다.
V4는 템플릿 메서드 패턴을 사용한 덕분에 핵심 기능에 좀 더 집중할 수 있게 되었다.
좋은 설계란?
좋은 설계라는 것은 무엇일까? 수 많은 멋진 정의가 있겠지만, 진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자.
단순히 AbstractTemplate코드만 변경하면 된다.
템플릿이 없는 V3상태에서 로그를 남기는 로직을 변경해야 한다고 생각해 보자.
이 경우 모든 클래스를 다 찾아서 고쳐야 한다. 클래스가 수백 개라면 생각만 해도 끔찍하다.
단일 책임 원칙(SRP)
v4는 단순히 템플릿 메서드 패턴을 적용해서 소스코드 몇 줄을 줄인 것이 전부가 아니다.
로그를 남기는 부분에 단일 책임 원칙(SRP)를 지킨 것이다.
변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.
템플릿 메서드 패턴 - 정의
GOF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의했다.
템플릿 메서드 디자인 패턴의 목적은 다음과 같습니다.
“작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재 정의할 수 있습니다.” - GOF
GOF 템플릿 메서드 패턴 정의

풀어서 설명하면 다음과 같다.
부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다.
이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의 할 수 있다.
결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.
하지만…
템플릿 메서드 패턴은 상속을 사용한다. 따라서 상속에서 오는 단점들을 그대로 안고간다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다.
이것은 의존 관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
이번 장에서 지금까지 작성했던 코드를 떠올려보자. 자식 클래스를 작성할 때 부모 클래스의 기능을 사용한 것이 있던가?
그럼에도 불구하고 템플릿 메서드 패턴을 위해 자식 클래스는 부모 클래스를 상속 받고 있다.
상속을 받는 다는 것은 특정 부모 클래스를 의존하고 있다는 것이다. 자식 클래스의 extends 다음에 바로 부모 클래스가 코드 상에 지정되어 있다.
따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다.
여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻이다.
UML(사진 속 다이어그램)에서 상속을 받으면 삼각형 화살표가 자식 → 부모를 향하고 있는 것은 이런 의존 관계를 반영하는 것이다.
자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야 한다.
이것은 좋은 설계가 아니다. 그리고 이런 잘못된 의존 관계 때문에 부모 클래스를 수정하면, 자식 클래스 에도 영향을 줄 수 있다.
추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다.
지금까지 설명한 이런 부분들을 더 깔끔하게 해결하기 위해서 사용하는 방식이 있을까?
템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 해결할 수 있는 디자인 패턴이 바로 전략 패턴(Strategy Pattern)이다.
댓글남기기