전략 패턴

Hoo-Sung.Lee·2024년 4월 18일
0

Spring

목록 보기
7/15

배경

GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.

알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

템플릿 메소드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결하였다.

반면, 전략 패턴은 변하지 않는 부분은 Context라는 곳에 두고, 변하는 부분을 Strategy라는 인터페이스를 만들고, 해당 인터페이스를 구현하도록 해서 문제를 해결한다. 상속이 아니라 위임으로 문제를 해결하는 것이다.

전략 패턴에서 Context는 변하지 않는 템플릿 역할을 하고, Strategy는 변하는 알고리즘 역할을 한다.


public interface Strategy{
	void call();
}	

이 인터페이스는 변하는 알고리즘 역할을 한다.

public class StrategyLogic1 implements Strategy{
	@Override
    public void call(){
    	log.info("비즈니스 로직1 실행");
    }
}
public class StrategyLogic2 implements Strategy{
	@Override
    public void call(){
    	log.info("비즈니스 로직2 실행");
    }
}

Context는 변하지 않는 템플릿 역할을 한다고 했다. Context에 Strategy를 필드 주입하는 방식과, 파라미터로 전달하는 방식 두 가지가 있다.

1. ContextV1: Context의 필드에 Strategy 주입해서 사용

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);
    }
}

ContextV1는 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다. 전략 패턴에서는 이것을 컨텍스트(문맥)이라고 한다.
쉽게 이야기해서 컨텍스트는 크게 변하지 않지만, 그 문맥 속에서 strategy를 통해 일부 전략이 변경된다 생각하면 된다.

  • Context는 내부에 Strategy 필드를 가지고 있다. 이 필드에 변하는 부분인 Strategy의 구현체를 주입하면 된다.

이 처럼, 전략 패턴의 핵심은 Context는 Strategy 인터페이스에만 의존한다는 점이다.

지금까지 모르고 사용하였던, 스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴이다.!!

2. ContextV2: Strategy를 파라미터로 전달해서 사용하자.

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);
 	}
 }

이 방식은 Context와 Strategy를 '선 조립 후 실행' 하는 방식이 아니라 Context를 실행할 때마다 전략을 인수로 전달한다.
클라이언트는 Context를 실행하는 시점에 원하는 Strategy를 전달할 수 있다. 따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연학 변경할 수 있다.

ContextV1, ContextV2 두 가지 방식 다 문제를 해결할 수 있지만, 어떤 방식이 조금 나을까?
지금 우리가 원하는것은 애플리케이션 의존 관계를 설정하는 것처럼 선 조립, 후 실행이 아니다. 단순히 코드를 실행할 때 변하지 않는 템플릿이 있고, 그 템플릿 안에서 원하는 부분만 살짝 다른 코드로 바꿔 실행하고 싶을 뿐이다.
따라서 우리가 고민하고 있는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContextV2가 더 적합하다.


마무리

위의 1,2번 모두 전략 패턴이 맞고 나도 모르게 스프링의 의존관계 주입에서 전략패턴을 사용하고 있었음을 알 수 있었다.

더하여, 탬플릿 메서드 패턴의 상속 문제에서 오는 단점을 극복하기 위해 전략 패턴이 더 실용적으로 사용되겠다는 생각이 들었다.

자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있고, 이것이 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않기 때문이다.

자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야 한다. 이것은 좋은 설계가 아니다. 그리고 이런 잘못된 의존관계 때문에 부모 클래스를 수정하면, 자식 클래스에도 영향을 줄 수 있다.

상속 보다는 인터페이스를 사용해서 느슨한 결합을 유지하자. 이렇게 하면 클래스 간의 의존성을 최소화하고 유연성과 유지보수성을 향상시킬 수 있다.!!

profile
Software Engineer

0개의 댓글

관련 채용 정보