내가 공부한것을 올리며, 중요한 단원은 저 자신도 곱씹어 볼겸 상세히 기록하고 얕은부분들은 가겹게 포스팅 하겠습니다.
1. 전략 패턴 - 예제1
우선 다음과 같은 코드가 있다고 해보자.
@Slf4j
public class ContextV1Test {
@Test
void strategyV0() {
logic1();
logic2();
}
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);
}
}
위 코드를 전략패턴을 통해 개선해 나가보자!
전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다.
상속이 아니라 위임으로 문제를 해결하는 것이다.
알고리즘군 중에 원하는 알고리즘을 주입받는다 생각하면 편하다.
알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자.
전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다. [GoF]
알고리즘 역할을 하는 인터페이스를 하나 만들어보자!
public interface Strategy {
void call();
}
이에 대한 구현체는 다음과 같다.
@Slf4j
public class StrategyLogic1 implements Strategy {
@Override
public void call() {
log.info("비즈니스 로직1 실행");
}
}
@Slf4j
public class StrategyLogic2 implements Strategy {
@Override
public void call() {
log.info("비즈니스 로직2 실행");
}
}
각각 로직1, 로직2에 해당된다.
해당 알고리즘군을 사용한 context의 코드는 다음과 같다.
@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);
}
}
컨텍스트(문맥)는 크게 변하지 않지만, 그 문맥 속에서 strategy 를 통해 일부 전략이 변경된다 생각하면 된다.
전략 패턴의 핵심은 Context 는 Strategy 인터페이스에만 의존한다는 점이다.
덕분에 Strategy 의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.
이는 Spring에서 의존성 주입과 동일한 방식이다. Spring도 전략패턴을 통해 DI를 사용한다.
이를 실행하는 Test 코드는 다음과 같다.
@Test
void strategyV1() {
Strategy strategyLogic1 = new StrategyLogic1();
ContextV1 context1 = new ContextV1(strategyLogic1);
context1.execute();
Strategy strategyLogic2 = new StrategyLogic2();
ContextV1 context2 = new ContextV1(strategyLogic2);
context2.execute();
}
실행 결과는 다음과 같다.
이를 그림으로 확인하면 다음과 같다.
1. Context 에 원하는 Strategy 구현체를 주입한다.
2. 클라이언트는 context 를 실행한다.
3. context 는 context의 틀에 해당되는 로직을 시작한다.
4. context 로직 중간에 strategy.call() 을 호출해서 주입 받은 strategy 로직을 실행한다.
5. context 는 나머지 로직을 실행한다.
2. 전략 패턴 - 예제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();
}
알고리즘에 해당되는 Strategy를 익명 클래스를 통해 생성하였다.
실행결과는 직전과 동일하다.
또한 익명클래스의 생성물을 변수에 담는 것 이 아니라, 바로 ContextV1의 생성자에 전달해도 된다.
@Test
void strategyV3() {
ContextV1 context1 = new ContextV1(new Strategy() {
@Override
public void call() { log.info("비즈니스 로직1 실행");
}
});
context1.execute();
ContextV1 context2 = new ContextV1(new Strategy() {
@Override
public void call() { log.info("비즈니스 로직2 실행");
}
});
context2.execute();
}
그 다음으로는 가장 깔끔하게 람다를 사용하는 방식이 있다.
@Test
void strategyV4() {
ContextV1 context1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
context1.execute();
ContextV1 context2 = new ContextV1(() -> log.info("비즈니스 로직2 실행"));
context2.execute();
}
▶ 선 조립, 후 실행
위에서 사용한 방식은 Context 와 Strategy 를 실행 전에 원하는 모양으로 조립해두고 그 다음에 실행하는, 선 조립 후 실행 방식에서 매우 유용하다.
이는 우리가 Spring으로 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것 과 같은 원리이다.
하지만 단점도 있다.
Context 와 Strategy 를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다.
물론 Context 에 setter 를 제공해서 Strategy 를 넘겨 받아 변경하면 되지만, Context 를 싱글톤으로 사용할 때는 동시성 이슈 등 고려할 점이 많다.
그래서 전략을 실시간으로 변경해야 하면 차라리 이전에 개발한 테스트 코드 처럼 Context 를 하나더 생성하고 그곳에 다른 Strategy 를 주입하는 것이 더 나은 선택일 수 있다.
이를 해결하는 방법을 다음 단락에서 알아보자!
3. 전략 패턴 - 예제3
이전에는 Context 의 필드에 Strategy 를 주입해서 사용했다. 이번에는 전략을 실행할 때 직접 파라미터로 전달해서 사용해보자.
새롭게 생성된 ContextV2는 다음과 같다.
/**
* 전략을 파라미터로 전달받는 방식
*/
@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);
}
}
전략을 인자로 전달받아서 사용하고있다.
사용하는 테스트 코드는 다음과 같다.
@Slf4j
public class ContextV2Test {
/**
*전략 패턴 적용
*/
@Test
void strategyV1() {
ContextV2 context = new ContextV2();
context.execute(new StrategyLogic1());
context.execute(new StrategyLogic2());
}
}
execute를 실행할때 마다 인자로 strategy를 전달해줘야 한다.
클라이언트는 Context 를 실행하는 시점에 원하는 Strategy 를 전달할 수 있다.
따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연하게 변경할 수 있다.
테스트 코드를 보면 하나의 Context 만 생성한다.
그리고 하나의 Context 에 실행 시점에 여러 전략을 인수로 전달해서 유연하게 실행하는 것을 확인할 수 있다.
1. 클라이언트는 Context 를 실행하면서 인수로 Strategy 를 전달한다.
2. Context 는 execute() 로직을 실행한다.
3. Context 는 파라미터로 넘어온 strategy.call() 로직을 실행한다.
4. Context 의 execute() 로직이 종료된다.
또한 이전과 같이 익명 클래스, 람다를 활용할수도 있다.
우리의 로거는 그럼 두방식중 어떤방식이 더 적합할까?
지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립, 후 실행이 아니다.
단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐이다.
따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2 가 더 적합하다.
'BackEnd > Spring' 카테고리의 다른 글
[Spring] 프록시 패턴과 데코레이터 패턴 예제 (0) | 2022.08.09 |
---|---|
[Spring] 템플릿 콜백 패턴 (0) | 2022.08.07 |
[Spring] 템플릿 메서드 패턴 (0) | 2022.08.06 |
[Spring] 쓰레드 로컬 - ThreadLocal - 2 (0) | 2022.08.05 |
[Spring] 쓰레드 로컬 - ThreadLocal - 1 (0) | 2022.08.04 |
댓글