검색결과 리스트
글
스프링 핵심 원리 - 고급편 5
인프런 강의 64일차.
- 스프링 핵심 원리 - 고급편 (김영한 강사님)
- 반드시 한번은 정복해야할 쉽지 않은 내용들
- 크게 3가지 고급 개념을 학습
1. 스프링 핵심 디자인 패턴
> 템플릿 메소드 패턴
> 전략 패턴
> 템플릿 콜백 패턴
> 프록시 패턴
> 데코레이터 패턴
2. 동시성 문제와 쓰레드 로컬
> 웹 애플리케이션
> 멀티쓰레드
> 동시성 문제
3. 스프링 AOP
> 개념, 용어정리
> 프록시 - JDK 동적 프록시, CGLIB
> 동작 원리
> 실전 예제
> 실무 주의 사항
- 기타
> 스프링 컨테이너의 확장 포인트 - 빈 후처리기
> 스프링 애플리케이션을 개발하는 다양한 실무 팁
- 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등
3. 템플릿 메서드 패턴과 콜백 패턴
3.6. 템플릿 메서드 패턴 - 적용2
- 템플릿 메서드 패턴 덕분에 변하는 코드와 변하지 않는 코드를 명확하게 분리했다.
- 로그를 출력하는 템플릿 역할을 하는 변하지 않는 코드는 모두 AbstractTemplate 에 담아두고, 변하는 코드는 자식 클래스를 만들어서 분리했다.
//OrderServiceV0 코드
public void orderItem(String itemId) {
orderRepository.save(itemId);
}
//OrderServiceV3 코드
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;
}
}
//OrderServiceV4 코드
AbstractTemplate<Void> template = new AbstractTemplate<>(trace) {
@Override
protected Void call() {
orderRepository.save(itemId);
return null;
}
};
template.execute("OrderService.orderItem()");- OrderServiceV0 : 핵심 기능만 있다.
- OrderServiceV3 : 핵심 기능과 부가 기능이 함께 섞여 있다.
- OrderServiceV4 : 핵심 기능과 템플릿을 호출하는 코드가 섞여 있다.
* 좋은 설계란?
- 진정한 좋은 설계는 바로 변경이 일어날 때 자연스럽게 드러난다.
- 지금까지 로그를 남기는 부분을 모아서 하나로 모듈화하고, 비즈니스 로직 부분을 분리했다.
- 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자.
- 그래서 AbstractTemplate 코드를 변경해야 한다 가정해보자. 단순히 AbstractTemplate 코드만 변경하면 된다.
- 템플릿이 없는 V3 상태에서 로그를 남기는 로직을 변경해야 한다고 생각해보자.
- 이 경우 모든 클래스를 다 찾아서 고쳐야 한다. 클래스가 수백 개라면 생각만해도 끔찍하다.
* 단일 책임 원칙(SRP)
- V4 는 단순히 템플릿 메서드 패턴을 적용해서 소스코드 몇줄을 줄인 것이 전부가 아니다.
- 로그를 남기는 부분에 단일 책임 원칙(SRP)을 지킨 것이다.
- 변경 지점을 하나로 모아서 변경에 쉽게 대처할 수 있는 구조를 만든 것이다.
3.7. 템플릿 메서드 패턴 - 정의
- GOF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의했다
> 템플릿 메서드 디자인 패턴의 목적은 다음과 같습니다.
> "작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다." [GOF]
- 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다.
- 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다.
> 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.
- 템플릿 메서드 패턴은 상속을 사용기때문에 상속에서 오는 단점들을 그대로 안고간다.
- 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다.
- 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다. 이번 장에서 지금까지 작성했던 코드를 떠올려보자. 자식 클래스를 작성할 때 부모 클래스의 기능을 사용한 것이 있었던가? 그럼에도 불구하고 템플릿 메서드 패턴을 위해 자식 클래스는 부모 클래스를 상속 받고 있다
- 상속을 받는 다는 것은 특정 부모 클래스를 의존하고 있다는 것이다. 자식 클래스의 extends 다음에 바로 부모 클래스가 코드상에 지정되어 있다. 따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻이다. UML에서 상속을 받으면 삼각형 화살표가 자식 -> 부모 를 향하고 있는 것은 이런 의존관계를 반영하는 것이다.
- 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야한다. 이것은 좋은 설계가 아니다. 그리고 이런 잘못된 의존관계 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향을 줄 수 있다.
- 추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다. 지금까지 설명한 이런 부분들을 더 깔끔하게 개선하려면 어떻게 해야할까?
- 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 전략 패턴 (Strategy Pattern)이다
3.8. 전략 패턴 - 예제1
- 템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결했다.
- 전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다.
- 상속이 아니라 위임으로 문제를 해결하는 것이다. 전략 패턴에서 Context 는 변하지 않는 템플릿 역할을 하고, Strategy 는 변하는 알고리즘 역할을 한다 (중간에 전략을 두는 것)
- GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.
> 알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다
package hello.advanced.trace.strategy.code.strategy;
public interface Strategy {
void call();
}
- hello.advanced.trace.strategy.code.strategy.Strategy.java
- Strategy 인터페이스는 변하는 알고리즘 역할을 한다
package hello.advanced.trace.strategy.code.strategy;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class StrategyLogic1 implements Strategy {
@Override
public void call() {
log.info("비즈니스 로직1 실행");
}
}
- hello.advanced.trace.strategy.code.strategy.StrategyLogic1.java
- 변하는 알고리즘은 Strategy 인터페이스를 구현하면 된다. 여기서는 비즈니스 로직1을 구현했다
package hello.advanced.trace.strategy.code.strategy;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class StrategyLogic2 implements Strategy {
@Override
public void call() {
log.info("비즈니스 로직2 실행");
}
}
- hello.advanced.trace.strategy.code.strategy.StrategyLogic2.java
- 비즈니스 로직 2를 구현했다.
package hello.advanced.trace.strategy.code.strategy;
import lombok.extern.slf4j.Slf4j;
/**
* 필드에 전략을 보관하는 방식
*/
@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);
}
}
- hello.advanced.trace.strategy.code.strategy.ContextV1.java
- ContextV1 은 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다.
> 전략 패턴에서는 이것을 컨텍스트라 한다.
> 쉽게 이야기해서 컨텍스트는 크게 변하지 않지만, 그 문맥 속에서 strategy 를 통해 일부 전략이 변경된다 생각하면 된다.
- Context 는 내부에 Strategy strategy 필드를 가지고 있다. 이 필드에 변하는 부분인 Strategy 의 구현체를 주입하면 된다. 전략 패턴의 핵심은 Context 는 Strategy 인터페이스에만 의존한다는 점이다.
> 덕분에 Strategy 의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.
- 바로 스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴이다!
/**
* 전략 패턴 사용
*/
@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();
}- hello.advanced.trace.strategy.ContextV1Test.java
- 코드를 보면 의존관계 주입을 통해 ContextV1 에 Strategy 의 구현체인 strategyLogic1 를 주입하는 것을 확인할 수 있다.
- Context 안에 원하는 전략을 주입한 뒤 context1.execute() 를 호출해서 context 를 실행한다.
- 1. Context 에 원하는 Strategy 구현체를 주입한다.
- 2. 클라이언트는 context 를 실행한다.
- 3. context 는 context 로직을 시작한다.
- 4. context 로직 중간에 strategy.call() 을 호출해서 주입 받은 strategy 로직을 실행한다.
- 5. context 는 나머지 로직을 실행한다
3.9. 전략 패턴 - 예제2
- 전략 패턴도 익명 내부 클래스를 사용할 수 있다.
public class ContextV1Test {
...
/**
* 전략 패턴 사용
*/
@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();
}
/**
* 전략 패턴 내부 익명클래스 사용1
*/
@Test
void strategyV2() {
Strategy strategyLogic1 = new Strategy() {
@Override
public void call() {
log.info("비즈니스 로직1 실행");
}
};
ContextV1 context1 = new ContextV1(strategyLogic1);
log.info("strategyLogic1={}", strategyLogic1.getClass());
context1.execute();
Strategy strategyLogic2 = new Strategy() {
@Override
public void call() {
log.info("비즈니스 로직2 실행");
}
};
ContextV1 context2 = new ContextV1(strategyLogic2);
log.info("strategyLogic2={}", strategyLogic2.getClass());
context2.execute();
}
/**
* 전략 패턴 내부 익명클래스 사용2
*/
@Test
void strategyV3() {
//변수였던 strategyLogic1, 2를 생성할 때 세팅
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();
}
}- hello.advanced.trace.strategy.ContextV1Test.java
- strategyV2() : 내부 익명 클래스를 변수 선언해서 사용
- strategyV3() : 내부 익명 클래스를 생성자에 넣어서 사용
- strategyV4() : 람다를 사용해서 사용
* 정리
- 지금까지 일반적으로 이야기하는 전략 패턴에 대해서 알아보았다. 변하지 않는 부분을 Context 에 두고 변하는 부분을 Strategy 를 구현해서 만든다. 그리고 Context 의 내부 필드에 Strategy 를 주입해서 사용했다
* 선 조립, 후 실행
- 여기서 이야기하고 싶은 부분은 Context 의 내부 필드에 Strategy 를 두고 사용하는 부분이다. 이 방식은 Context 와 Strategy 를 실행 전에 원하는 모양으로 조립해두고, 그 다음에 Context 를 실행하는 선 조립, 후 실행 방식에서 매우 유용하다. Context 와 Strategy 를 한번 조립하고 나면 이후로는 Context 를 실행하기만 하면 된다.
- 우리가 스프링으로 애플리케이션을 개발할 때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것 과 같은 원리이다.
- 이 방식의 단점은 Context 와 Strategy 를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다. 물론 Context 에 setter 를 제공해서 Strategy 를 넘겨 받아 변경하면 되지만, Context 를 싱글톤으로 사용할 때는 동시성 이슈 등 고려할 점이 많다. 그래서 전략을 실시간으로 변경해야 하면 차라리 이전에 개발한 테스트 코드 처럼 Context 를 하나더 생성하고 그곳에 다른 Strategy 를 주입하는 것이 더 나은 선택일 수 있다.
3.9. 전략 패턴 - 예제3
- 전략 패턴을 조금 다르게 사용해보자. 이전에는 Context 의 필드에 Strategy 를 주입해서 사용했다.
- 이번에는 전략을 실행할 때 직접 파라미터로 전달해서 사용해보자
package hello.advanced.trace.strategy;
import hello.advanced.trace.strategy.code.strategy.*;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
@Slf4j
public class ContextV2Test {
/**
* 전략 패턴 적용
*/
@Test
void strategyV1() {
ContextV2 context = new ContextV2();
context.execute(new StrategyLogic1());
context.execute(new StrategyLogic2());
}
/**
* 전략 패턴 내부 익명클래스 사용
*/
@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 실행");
}
});
}
/**
* 전략 패턴 내부 익명클래스2, 람다 사용
*/
@Test
void strategyV3() {
ContextV2 context = new ContextV2();
context.execute(() -> log.info("비즈니스 로직1 실행"));
context.execute(() -> log.info("비즈니스 로직2 실행"));
}
}
- hello.advanced.trace.strategy.ContextV2Test.java
- Context 와 Strategy 를 '선 조립 후 실행'하는 방식이 아니라 Context 를 실행할 때 마다 전략을 인수로 전달한다.
- 클라이언트는 Context 를 실행하는 시점에 원하는 Strategy 를 전달할 수 있다. 따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연하게 변경할 수 있다.
- 테스트 코드를 보면 하나의 Context 만 생성한다. 그리고 하나의 Context 에 실행 시점에 여러 전략을 인수로 전달해서 유연하게 실행하는 것을 확인할 수 있다. (전략패턴을 변경 가능)
- strategyV1() : Context 선언 -> 전략 execute
- strategyV2() : 내부 익명 클래스에서 실행될 때 마다 전략을 파라미터로 받아서 사용
- strategyV3() : 람다를 사용해서 사용
- 1. 클라이언트는 Context 를 실행하면서 인수로 Strategy 를 전달한다.
- 2. Context 는 execute() 로직을 실행한다.
- 3. Context 는 파라미터로 넘어온 strategy.call() 로직을 실행한다.
- 4. Context 의 execute() 로직이 종료된다.
* 정리
- ContextV1 은 필드에 Strategy 를 저장하는 방식으로 전략 패턴을 구사했다.
> 선 조립, 후 실행 방법에 적합하다.
> Context 를 실행하는 시점에는 이미 조립이 끝났기 때문에 전략을 신경쓰지 않고 단순히 실행만 하면 된다.
- ContextV2 는 파라미터에 Strategy 를 전달받는 방식으로 전략 패턴을 구사했다.
> 실행할 때 마다 전략을 유연하게 변경할 수 있다.
> 단점 역시 실행할 때 마다 전략을 계속 지정해주어야 한다는 점이다.
* 템플릿
- 지금 우리가 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것이다. 변하지 않는 부분을 템플릿이라고 하고, 그 템플릿 안에서 변하는 부분에 약간 다른 코드 조각을 넘겨서 실행하는 것이 목적이다.
- ContextV1 , ContextV2 두 가지 방식 다 문제를 해결할 수 있지만, 어떤 방식이 조금 더 나아 보이는가?
- 지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것 처럼 선 조립, 후 실행이 아니다. 단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐이다. 따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2 가 더 적합하다.
'Spring 정리' 카테고리의 다른 글
| 스프링 핵심 원리 - 고급편 7 (0) | 2023.04.30 |
|---|---|
| 스프링 핵심 원리 - 고급편 6 (0) | 2023.01.25 |
| 스프링 핵심 원리 - 고급편 4 (0) | 2023.01.16 |
| 스프링 핵심 원리 - 고급편 3 (0) | 2022.10.29 |
| 스프링 핵심 원리 - 고급편 2 (1) | 2022.10.29 |
