•
런타임 중에 알고리즘 전략을 선택하여 객체 동작이 변할 수 있게 해주는 행위 디자인 패턴이다.
•
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이며 Strategy는 Human 인터페이스, ConcreateStrategy는 Human의 구현체다.
•
위와 같이 구현했을 때, 다음과 같은 객체지향적 장점이 생긴다.
1.
Context의 ContextMethod는 구현 내용을 Strategy의 구현체에 위임하므로 구현 내용을 캡슐화할 수 있다.
2.
Strategy는 인터페이스일 뿐, 실제 생성 시 생성된 ConcreateStrategy를 넘겨주므로 다형성을 확보할 수 있다.
3.
Context는 Strategy와 합성의 관계에 있으므로 상속보다 더 낮은 결합도를 가지며 응집성은 더 향상된다.
사용 시기
•
전략 알고리즘의 여러 버전 또는 변형이 필요한 경우, 클래스화를 통해 관리한다.
•
알고리즘의 동작이 런타임에 교체될 가능성이 있는 경우, 필요하다.
주의점
•
구현체가 많아질수록 관리해야할 객체의 수가 증가한다.
•
만일 어플리케이션 특성상, 알고리즘이 많지 않고 자주 변경되지 않는다면 애플리케이션의 복잡도만 올라가게 된다.
•
개발자는 프로그래밍 시 전략 선택 과정에서 전략 간의 차이점을 정확히 인식하고 있어야 한다.
