Search
Duplicate
🕙

Strategy

런타임 중에 알고리즘 전략을 선택하여 객체 동작이 변할 수 있게 해주는 행위 디자인 패턴이다.
OOP의 핵심인 것 같다. 다음과 같이 축구 선수라는 객체가 있다고 해보자.
public class FootballPlayer { public String position; public Human player; public FootballPlayer (String position, Human player) { this.position = position; this.player = player; } public void callName() { this.player.callName(); } }
Java
복사
이 객체는 player라는 Human 타입의 객체에게 callName 메소드의 구현을 위임하고 있다.
덕분에 해당 행동을 캡슐화하고 런타임 상황에 FootballPlayer의 각 전략에 맞게 생성하여 사용할 수 있게 된다.
위 그림을 봐보자. 위 그림에서 Context는 예시 코드의 FootballPlayer이며 StrategyHuman 인터페이스, ConcreateStrategyHuman의 구현체다.
위와 같이 구현했을 때, 다음과 같은 객체지향적 장점이 생긴다.
1.
ContextContextMethod는 구현 내용을 Strategy의 구현체에 위임하므로 구현 내용을 캡슐화할 수 있다.
2.
Strategy는 인터페이스일 뿐, 실제 생성 시 생성된 ConcreateStrategy를 넘겨주므로 다형성을 확보할 수 있다.
3.
ContextStrategy와 합성의 관계에 있으므로 상속보다 더 낮은 결합도를 가지며 응집성은 더 향상된다.

사용 시기

전략 알고리즘의 여러 버전 또는 변형이 필요한 경우, 클래스화를 통해 관리한다.
알고리즘의 동작이 런타임에 교체될 가능성이 있는 경우, 필요하다.

주의점

구현체가 많아질수록 관리해야할 객체의 수가 증가한다.
만일 어플리케이션 특성상, 알고리즘이 많지 않고 자주 변경되지 않는다면 애플리케이션의 복잡도만 올라가게 된다.
개발자는 프로그래밍 시 전략 선택 과정에서 전략 간의 차이점을 정확히 인식하고 있어야 한다.