전략 패턴 - 예제2
전략 패턴도 익명 내부 클래스를 사용할 수 있다.
익명 내부 클래스 사용
@Test
void strategyV2(){
Strategy strategyLogic1 = new Strategy(){
@Override
public void call() {
log.info("비지니스 로직1 실행");
}
};
ContextV1 context1 = new ContextV1(strategyLogic1);
context1.execute();
Strategy strategyLogic2 = new Strategy(){
@Override
public void call() {
log.info("비지니스 로직2 실행");
}
};
ContextV1 context2 = new ContextV1(strategyLogic2);
context2.execute();
}
람다 사용
@Test
void strategyV4(){
ContextV1 context1 = new ContextV1(new Strategy(){
@Override
public void call() {
log.info("비지니스 로직1 실행");
}
});
context1.execute();
//람다 사용
ContextV1 context2 = new ContextV1(() -> log.info("비지니스 로직2 실행"));
context2.execute();
}
익명 내부 클래스를 자바8부터 제공하는 람다로 변경할 수 있다. 인터페이스에 직접 구현해야 할 메서드가 1개만 있다면 람다로 변경할 수 있다. 우리가 구현한 Strategy 인터페이스는 메서드가 1개만 있으므로 람다로 사용할 수 있다.
전략 패턴 - 중간 정리
전략 패턴에서는 변하지 않는 부분을 Context 에 두고 변하는 부분을 Strategy 를 구현해서 만든다. 그리고 Context 의 내부 필드에 Strategy 를 주입해서 사용했다.
선 조립, 후 실행 : Context 의 내부 필드에 Strategy 를 두고 사용
이 방식은 Context 와 Strategy 를 실행 전에 원하는 모양으로 조립해두고, 그 다음에 Context 를 실행하는 선 조립, 후 실행 방식에서 매우 유용하다. Context 와 Strategy 를 한번 조립하고 나면 이후로는 Context 를 실행하기만 하면 된다.
스프링으로 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것 과 같은 원리이다.
이 방식의 단점은 Context 와 Strategy 를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다. 물론 Context 에 setter 를 제공해서 Strategy 를 넘겨 받아 변경하면 되지만, Context 를 싱글톤으로 사용할 때는 동시성 이슈 등 고려할 점이 많다. 그래서 전략을 실시간으로 변경해야 하면 차라리 이전에 개발한 테스트 코드 처럼 Context 를 하나 더 생성하고 그곳에 다른 Strategy 를 주입하는 것이 더 나은 선택일 수 있다. (다른 객체 = 완전히 독립적으로 실행)
전략 패턴 - 예제3
Context 생성 시점에 필드에 Strategy 를 미리 주입해서 사용하는 것이 아니고,
전략을 실행하는 시점에 직접 파라미터로 전달하여 사용하기
Context.execute(Strategy)
전략을 파라미터로 전달 받는 방식
@Slf4j
public class ContextV2 {
public void execute(Strategy strategy){
long startTime = System.currentTimeMillis();
//비지니스 로직 실행
strategy.call(); //위임
//비지니스 로직 실행 종료
long endTime = System.currentTimeMillis();
long resultTime = endTime - startTime;
log.info("resultTime={}", resultTime);
}
}/**
* 전략 패턴 적용
*/
@Test
void strategyV1(){
ContextV2 context = new ContextV2();
context.execute(new StrategyLogic1());
context.execute(new StrategyLogic2());
}
클라이언트는 Context 를 실행하는 시점에 원하는 Strategy 를 전달할 수 있다. 따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연하게 변경할 수 있다.
테스트 코드를 보면 하나의 Context 만 생성하고 여러 전략을 인수로 전달해서 유연하게 실행하는 것을 확인할 수 있다.
익명 내부 클래스 사용
@Test
void strategyV2(){
ContextV2 context = new ContextV2();
context.execute(new Strategy() {
@Override
public void call() {
log.info("비지니스 로직1 실행");
}
});
context.execute(new Strategy() {
@Override
public void call() {
log.info("비지니스 로직2 실행");
}
});
}물론 익명 내부 클래스를 사용할 수 있다. 코드 조각을 파라미터로 넘긴다고 생각하면 더 자연스럽다.
람다 사용
@Test
void strategyV3(){
ContextV2 context = new ContextV2();
context.execute(() -> log.info("비지니스 로직1 실행"));
context.execute(() -> log.info("비지니스 로직2 실행"));
}
정리
ContextV1 은 필드에 Strategy 를 저장하는 방식으로 전략 패턴을 구사했다.
선 조립, 후 실행 방법에 적합하다. Context 를 실행하는 시점에는 이미 조립이 끝났기 때문에 전략을 신경쓰지 않고 단순히 실행만 하면 된다.
ContextV2 는 파라미터에 Strategy 를 전달받는 방식으로 전략 패턴을 구사했다. 실행할 때 마다 전략을 유연하게 변경할 수 있다. 단점 역시 실행할 때 마다 전략을 계속 지정해주어야 한다는 점이다.
문제 해결: 전략 패턴을 어떤 식으로 구현할지
우리가 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것이다.
변하지 않는 부분을 템플릿이라고 하고, 그 템플릿 안에서 변하는 부분에 코드 조각을 넘겨서 실행하는 것이 목적이다. ContextV1 , ContextV2 두 가지 방식 다 문제를 해결할 수 있지만, 어떤 방식이 조금 더 나아 보이는가?
지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립, 후 실행이 아니다.
단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐이다.
따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2 가 더 적합하다.
템플릿 콜백 패턴
ContextV2 는 변하지 않는 템플릿 역할을 한다. 그리고 변하는 부분은 파라미터로 넘어온 Strategy 의 코드를 실행해서 처리한다. 이렇게 다른 코드의 파라미터로 넘겨주는 실행 가능한 코드를 콜백(callback)이라 한다.
콜백이란?
프로그래밍에서 콜백(callback) 또는 콜애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다.
호출( call )은 되는데 코드를 넘겨준 곳의 뒤( back )에서 실행된다.
여기에서는 클라이언트에서 직접 Strategy 를 실행하는 것이 아니라, 클라이언트가 ContextV2.execute(..) 를 실행할 때 Strategy 를 넘겨주고, ContextV2 뒤에서 Strategy 가 실행된다.
자바 언어에서 콜백
자바 언어에서 실행 가능한 코드를 인수로 넘기려면 객체가 필요하다. 자바8부터는 람다를 사용할 수 있다.
자바 8 이전에는 보통 하나의 메서드를 가진 인터페이스를 구현하고, 주로 익명 내부 클래스를 사용했다.
최근에는 주로 람다를 사용한다.
템플릿 콜백 패턴
- 스프링에서는 ContextV2 와 같은 방식의 전략 패턴을 템플릿 콜백 패턴이라 한다. 전략 패턴에서 Context 가 템플릿 역할을 하고, Strategy 부분이 콜백으로 넘어온다 생각하면 된다.
- 참고로 템플릿 콜백 패턴은 GOF 패턴은 아니고, 스프링 내부에서 이런 방식을 자주 사용하기 때문에, 스프링 안에서만 이렇게 부른다. 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이라 생각하면 된다.
- 스프링에서는 JdbcTemplate , RestTemplate , TransactionTemplate , RedisTemplate 처럼 다양한 템플릿 콜백 패턴이 사용된다. 스프링에서 이름에 XxxTemplate 가 있다면 템플릿 콜백 패턴으로 만들어져 있다 생각하면 된다.
템플릿 콜백 패턴 - 예제
ContextV2 와 내용이 같고 이름만 달라진다.
Context -> Template
Strategy -> Callback
별도의 클래스를 만들어서 전달해도 되지만, 콜백을 사용할 경우 익명 내부 클래스나 람다를 사용하는 것이 편리하다.
물론 여러곳에서 함께 사용되는 경우 재사용을 위해 콜백을 별도의 클래스로 만들어도 된다.
템플릿 콜백 패턴 - 적용
TraceCallback 인터페이스
public interface TraceCallback<T> {
T call();
}
콜백을 전달하는 인터페이스
제네릭 사용 -> 콜백의 반환 타입 정의
TraceTemplate 클래스
public <T> T execute(String message, TraceCallback<T> callback){
TraceStatus status = null;
try{
status = trace.begin(message);
//로직 호출
T result = callback.call();
trace.end(status);
return result;
} catch (Exception e){
trace.exception(status, e);
throw e;
}
}
execute(..) 를 보면 message 데이터와 콜백인 TraceCallback callback 을 전달 받는다.
제네릭 사용 -> 반환 타입 정의
LogTrace: 로그 추적기 인터페이스 (begin, end, exception)
ThreadLocalLogTrace: 로그 추적기 구현체 (쓰레드 로컬 사용)
TraceTemplate: 템플릿(변하지 않는 부분)에서 콜백 클래스를 파라미터로 받아서 호출. LocalTrace 사용
TraceCallback<T>: 콜백(변하는 부분) 인터페이스 (call)
클라이언트(컨트롤러, 서비스, 리포지토리): 템플릿 생성하여 execute() 파라미터로 메세지와 코드 조각(Callback)을 넘김
OrderControllerV5 클래스
@RestController
public class OrderControllerV5 {
private final OrderServiceV5 orderService;
private final TraceTemplate template;
public OrderControllerV5(OrderServiceV5 orderService, LogTrace trace) {
this.orderService = orderService;
this.template = new TraceTemplate(trace);
}
@GetMapping("/v5/request")
public String request(String itemId){
return template.execute("OrderController.request()", new TraceCallback<>() {
@Override
public String call() {
orderService.orderItem(itemId);
return "ok";
}
});
}
}
- this.template = new TraceTemplate(trace) : trace 의존관계 주입을 받으면서 필요한 TraceTemplate 템플릿을 생성한다. 컨트롤러 클래스는 스프링 빈으로 등록되어 싱글톤이기 때문에, 생성자가 한 번만 호출되어 템플릿도 한 번만 생성된다. 컨트롤러에서 직접 템플릿을 생성하면 컨트롤러가 호출될 때마다 템플릿이 생성되기 때문에 비효율적이다. 참고로 TraceTemplate 를 처음부터 스프링 빈으로 등록하고 주입받아도 된다. 이렇게 하면 테스트에 용이하다.
- template.execute(.., new TraceCallback(){..}) : 템플릿을 실행하면서 콜백을 전달한다. 여기서는 콜백으로 익명 내부 클래스를 사용했다.
정리
변하는 코드와 변하지 않는 코드를 분리하고, 더 적은 코드로 로그 추적기를 적용하기 위해 템플릿 메서드 패턴, 전략 패턴, 그리고 템플릿 콜백 패턴까지 진행하였다.
그리고 최종적으로 템플릿 콜백 패턴을 적용하고 콜백으로 람다를 사용해서 코드 사용도 최소화 할 수 있었다.
한계
아무리 최적화를 해도 결국 로그 추적기를 적용하기 위해서 원본 코드를 수정해야 한다. 클래스가 수백개이면 수백개를 더 힘들게 수정하는가 조금 덜 힘들게 수정하는가의 차이가 있을 뿐, 본질적으로 코드를 다 수정해야 하는 것은 마찬가지이다. 지금부터 원본 코드를 손대지 않고 로그 추적기를 적용할 수 있는 방법을 알아보자.
그러기 위해서 프록시 개념을 먼저 이해해야 한다.
참고: 지금까지 설명한 방식은 실제 스프링 안에서 많이 사용되는 방식이다. XxxTemplate 를 만나면 이번에 학습한 내용을 떠올려보면 어떻게 돌아가는지 쉽게 이해할 수 있을 것이다
