본문 바로가기
Theory/Design Pattern

Strategy Pattern

by y.j 2022. 5. 22.
728x90

Strategy Pattern

알고리즘의 family를 정의하고 캡슐화한다. 또한 서로 상호교환도 가능하다. Strategy Pattern은 알고리즘을 독립적으로 다양하게 사용 할 수 있게 한다.

어떻게 알고리즘을 직접 구현하는 대신에 run-time에 환경설정을 할 수 있을까?
어떻게 알고리즘을 run-time에 교환하거나 선택할 수 있을까?

Context내에 알고리즘을 switch나 if-else문으로 작성한다면 나중에 독립적으로 수정하기가 어렵다. 또한, 클래스가 복잡해지고 재사용성이 어려워진다. 알고리즘을 개발기간동안 확장되어지고 최적화되며 대체되기도 하기 때문에 결합을 약하게 해야만 한다. 

 

Solution

이 패턴의 목적은 상속을 통해 독립적으로 알고리즘을 구현하는데 있다.

 

Strategy object를 분리한다. Strategy interface를 만들고 algorithm함수를 상속받아 정의한다.

public class Strategy1 implements Strategy {
    @Override
    public int algorithm() {
        return 1;
    }
}

Context에 Strategy를 받아 사용 할수 있도록 한다.

public class Context {
    private Strategy strategy;

    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public String operation() {
        return "Context: Delegating an algorithm to a strategy: Result = "
                 + strategy.algorithm();
    }

    public void setStrategy(Strategy strategy) {
        this.strategy = strategy;
    }
}

 

Advantages

•Compile-time 구현 의존을 피할 수 있다.

 - Client는 interface를 참조하고 구현에는 독립적이다.
•Subclassing에 유동적 대안책을 제공한다.

 - Subclassing은 알고리즘은 compile-time에 고정되기 때문에 life-time동안 변경 할 수 없다.

•알고리즘 사이에서 교환하는데 조건문을 회피한다.


Disadvantages

• Strategy interface가 복잡해질 수 있다.

 - 알고리즘에 필요한 데이터를 불러와야 하기 때문에 복잡해질 수 있다.

• Client가 strategy가 어떻게 다른지 이해하는 것이 필요하다.

•추가적인 level이 필요하다

 - Client는 Strategy object에 의존하고 있기 때문에 연결해주는 추가적인 level이 필요하다.

 - 그래서 복잡해지게 될 수 있고 결과적으로 성능과 비용에 좋지 않은 영향이 미친다. 따라서 유동성이 실제로 필요한 시스템에 적용해야한다.

 

[전체코드]

https://github.com/jKyounju/adapterPatterns/tree/master/src/BehavioralPattern/StrategyPattern

https://github.com/jKyounju/adapterPatterns/blob/master/test/BehavioralPattern/StrategyPatternTest.java

728x90

'Theory > Design Pattern' 카테고리의 다른 글

Visitor Pattern  (0) 2022.05.22
Template Method Pattern  (0) 2022.05.22
State Pattern  (0) 2022.05.21
Observer Pattern  (0) 2022.05.21
Memento Pattern  (0) 2022.05.21

댓글