서비스 중인 어플리케이션에서 병목현상이 발생하여 각 메서드를 추적하기 위한 로그 추적기를 추가하기로 하였다. 로그 추적기는 메서드가 시작하는 시간과 끝나는 시간을 측정하여 각 메서드를 처리하는데 걸리는 시간이 얼마나 되는지 확인하는 기능을 한다.
아래 코드는 로그 추적기를 어플리케이션에 적용한 코드의 일부분이다.
- 컨트롤러
@GetMapping("/v3/request")
public String request(String itemId) {
// 로그 추적기 관련 코드
TraceStatus status = null;
try {
status = trace.begin("OrderController.request()");
// 핵심 로직
orderService.orderItem(itemId);
trace.end(status);
return "ok";
} catch (Exception e) {
trace.exception(status, e);
//예외를 꼭 다시 던져줘야 한다.
//로그는 어플리케이션 흐름에 영향을 줘선 안된다.
throw e;
}
}- 서비스
public void orderItem(String itemId) {
// 로그 추적기 관련 코드
TraceStatus status = null;
try {
status = trace.begin("OrderService.orderItem()");
// 핵심 로직
orderRepository.save(itemId);
trace.end(status);
} catch (Exception e) {
trace.exception(status, e);
throw e;
}
}코드를 보자.
실제 기능을 위해 필요한 로직은 단 한줄에 불과한데,
로그 추적기를 위한 코드를 추가하자 반복되는 코드가 훨씬 많은 것을 확인할 수 있다.
- 변하는 것과 변하지 않는 것을 분리
좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이라고 한다.
여기서 핵심 로직은 변하고, 로그 추적기 관련 로직은 변하지 않는다.
따라서 이 둘을 분리해서 모듈화 해야 한다.
템플릿 메서드 패턴은 이런 문제를 해결할 수 있는 디자인 패턴이다.
템플릿 메서드 패턴에 대해 알아보기 전에 디자인 패턴에 대해 간단하게 알아보고 넘어가자.
디자인 패턴
소프트웨어를 설계할 때 특정 맥락에서 반복적으로 발생하는 문제가 발생했을 때 재사용할 수 있는 해결책을 말한다. 즉, 효율적인 코드를 만들기 위한 방법론이다.
디자인 패턴은 크게 3가지 측면으로 분류할 수 있다.
-
생성 패턴(Creation Patterns)
객체 생성에 관련된 패턴을 말한다.
객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다. -
구조 패턴(Structural Patterns)
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴이다.
예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다. -
행위 패턴(Behavioral Patterns)
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴으로, 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화 하는 것에 중점을 둔다.
각 패턴의 종류와 자세한 사항은 아래의 링크를 참고하자.
개념을 봐도 어렵다ㅜㅜ 실무에서 경험해 보면서 체득해야 할 부분인 것 같다.
디자인 패턴 - devkuma
디자인 패턴 - REFACTORING GURU
1. 템플릿 메서드 패턴 적용
그럼 템플릿 메서드 패턴을 직접 적용하며 확인해보자.
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();
}-
제네릭을 활용해 반환 타입을 정의하자.
-
객체를 사용할 때 내부에서 사용할 LogTrace와
로그에 출력할 message를 파라미터로 전달 받는다. -
추상 메서드 call()을 통해서 변하는 부분을 처리한다.
- abstract 키워드를 이용해 상속으로 구현하도록 정의하자.
2. 컨트롤러 적용
@RestController
@RequiredArgsConstructor
public class OrderControllerV4 {
// f2 누르면 에러 발생 장소로 커서 이동
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()");
}
}- 익명 내부 클래스를 활용하자
- 익명 내부 클래스란?
객체 인스턴스를 생성하면서 동시에 상속받은 자식 클래스를 정의한다.
'class Subclass extends SuperClass'와 같이 직접 지정하는 이름이 없고
클래스 내부에 선언되는 클래스라 익명 내부 클래스라고 한다. - getClass()메서드로 클래스 이름을 출력해보면, 위의 컨트롤러의 경우
'OrderControllerV4$1'과 같은 임의로 부여된 이름이 출력된다. - 물론 상속 클래스를 새로 생성해서 사용해도 된다.
- 익명 내부 클래스란?
3. 서비스 적용
@Service
@RequiredArgsConstructor
public class OrderServiceV4 {
private final OrderRepositoryV4 orderRepository;
private final LogTrace trace;
public void orderItem(String itemId) {
// 리턴 타입이 void이므로 제네릭도 Void로 변경
AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
@Override
protected Void call() {
orderRepository.save(itemId);
return null;
}
};
template.execute("OrderService.orderItem()");
}
}- 제네릭은 기본타입을 선언할 수 없으므로, void대신 Void를 선언하자.
4. 리포지토리 적용
@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 IllegalArgumentException("예외 발생!");
}
sleep(1000);
return null;
}
};
template.execute("OrderRepository.save()");
}
// 1초 지연
private void sleep(int millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
}5.코드의 비교
그럼 핵심 기능만 구현했을때와 부가 기능(로그 추적기)을 추가했을 때, 템플릿 메서드 패턴을 도입했을 때 코드의 변화는 어떻게 될까?
// 1. 핵심 기능만 구혐
@GetMapping("/v0/request")
public String request(String itemId) {
orderService.orderItem(itemId);
return "ok";
}
// 2. 부가 기능 추가
@GetMapping("/v3/request")
public String request(String itemId) {
TraceStatus status = null;
try {
status = trace.begin("OrderController.request()");
orderService.orderItem(itemId);
trace.end(status);
return "ok";
} catch (Exception e) {
trace.exception(status, e);
//예외를 꼭 다시 던져줘야 한다.
//로그는 어플리케이션 흐름에 영향을 줘선 안된다.
throw e;
}
}
// 3. 템플릿 메서드 패턴 도입
@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라는 추상 클래스에 정의해두고,
변하는 코드, 즉, 핵심 기능을 추상 메서드로 선언하여 상속 클래스에서 정의하도록 설계하였다.
덕분에 변경이 필요할 때 AbstractTemplate만 수정하면 다른 코드에 영향을 미치지 않고 동일한 코드를 유지할 수 있게 되었다.
만약 2번째 경우처럼 핵심 기능과 부가 기능이 한군데 섞여 있을 경우 부가 기능에 변경 사항이 생길 경우 부가 기능을 사용하는 모든 코드를 수정해줘야 한다.
좋은 설계란?
좋은 설계는 수 많은 멋진 정의가 있겠지만, 진정한 좋은 설계는 변경이 일어날 때 드러난다.
이번 포스팅에서 로그를 남기는 부분(부가 기능)을 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다. 만약 로그를 남기는 로직을 변경한다고 가정해보자. 그럼 AbstractTemplate만 수정하면 된다.
반면 템플릿이 없는 상태에서 로그를 남기는 로직을 변경해야 한다고 가정해보자. 이 경우 부가 기능을 사용하는 모든 클래스를 수정해야 한다.
- 단일 책임 원칙(SRP)
3번째 코드는 단순히 템플릿 메서드 패턴을 적용해서 코드 몇주을 줄인 것이 전부가 아니다.
로그를 남기는 부분에서 단일 책임 원칙을 지킨 것이다. 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.
6. 템플릿 메서드 패턴 정의와 단점
GOF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의하고 있다.
템플릿 메서드 디자인 패턴의 목적은 다음과 같습니다.
"작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면
하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다." [GOF]
즉, 부모 클래스(AbstractTemplate)에서 골격인 Template을 정의하고, 일부 변경되는 로직을 자식 클래스에서 정의하는 것이다. 이를 통해 알고리즘 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다.
결국 상속과 오버라이딩을 통해 다형성으로 문제를 해결하는 것이다.
하지만 이로 인해 템플릿 메서드 패턴은 상속에서 오는 단점을 그대로 가지게 된다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결함되는 문제가 있다. 자식 클래스에서 부모 클래스의 기능을 전혀 사용하지 않음에도 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀있다는 뜻이다.
아래 코드를 확인해보자.
- 부모 클래스
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();
}- 자식 클래스
@Slf4j
public class SubClassLogic1 extends AbstractTemplate{
@Override
protected void call() {
log.info("비즈니스 로직1 실행");
}
}자식 클래스에서 부모 클래스의 어떠한 기능도 사용하지 않음에도 불구하고,
'extends AbstractTemplate'처럼 부모 클래스의 코드가 명확하게 적혀있다.
여기서 드러나는 단점
- 자식 클래스 임장에서는 부모 클래스의 기능을 전혀 사용하지 않음에도 부모 클래스를 알아야 한다.
- 이것은 좋은 설계가 아니다.
- 이런 잘못된 의존관계 때문에 부모 클래스를 수정하면 자식 클래스에도 영향을 줄 수 있다.
- 템플릿 메서드 패턴은 상속을 이용하기 때문에 별도의 클래스나 익명 내부 클래스를 만들어야 한다.
이런 문제를 개선하려면 어떻게 해야할까?
템플릿 메서드와 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 전략 패턴이다. 다음 포스팅에서는 전략 패턴에 대해 알아보자.
