Strategy Pattern

GoF의 디자인 패턴 중 Strategy Pattern에 대한 정의는 다음과 같다.

Strategy Pattern 에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. Strategy Pattern을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

알고리즘군을 정의 하고 각각을 캡슐화 하여 교환 하여 사용할 수 있다고 정의 되어 있는데 이 말은 어떠한 로직에서 캡슐화 가능한 기능들은 따로 빼내어, 보다 확장에 유연한 프로그램 구조를 만든다는 말과 같다.

어떠한 프로그램이 기획되고 구현 되는 과정에서 만들어야하는 프로그램의 기본 스펙이 확정되어 끝까지 유지 되는 경우는 없고, 새로운 이슈가 추가 되거나 프로젝트를 완료 하고 나서 추가적인 이슈가 발생하는 경우가 대부분이기 때문에 프로그래머는 그러한 확장 가능성을 고려 하여 작업 해야 한다.

그러면 어떤 부분에 대한 확장 가능성을 고려 해야 하는가? 바로 달라질 가능성 대해서 고려 해야 한다.

애플리케이션에서 달라지는 부분을 찾아 내고, 달라지지 않는 부분으로 부터 분리 시킨다.

헤드 퍼스트 디자인 패턴 에서는 오리를 예를 들어 이 패턴을 설명하고 있다. 아래와 같이 오리는 여러 특징을 가질수 있다.

 날수 있는 오리, 날수 없는 오리, 장난감 오리, 꽥꽥거리는 소리는 내는 오리, 아무소리도 못내는 오리

위의 오리들의 공통점과 차이점은 무엇 인가?

공통점 : "오리" 라고 불림
차이점 : 날 수 있고 없고, 소리가 다름

Strategy Pattern에서는 위의 차이점(달라지는) 부분을 분리 시켜 모듈화 하는 작업을 한다.

IFlyBehavior : 날수 있고 없고
IQuackBehavior : 소리가 다름

package
{
	public interface IFlyBehavior
	{
		function fly(): void
	}
}

package{
	public interface IQuackBehavior{
		function quack():void
	}
}

구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

위와 같이 작업을 하면 좀 더 확장이 용이한 프로그램을 구현 할 수 있다. 어떠한 종류의 오리라도 만들수 있고, 그 특징을 분리 하여 구현 하였기 때문에 유지 보수도 용이해 진다.  하지만 오리가 날수 있다, 없다로 Strategy Pattern을 비유 하기엔  억지 스러운 면이 있다. 그러면 어떠한 것들이 Strategy Pattern 으로 구현 되어 있을까?

곰 플레이어나 윈도우 플레이어 같은 동영상 플레이어에서 이 패턴을 찾을수 있다. 동영상 플레이어는 여러가지 종류의 파일들을 로드하여 재생할 수 있다. 파일의 종류가 여러 가지기 때문에(avi, wmv, mp4  등등) 파일 자체에 대한 기준도 있어야 겠지만, 플레이어에서 파일 별로 어떠한 코덱을 사용하여 재생 해야 되는가에 대한 분리가 되어 있을 것이다. (동영상 플레이어에서 달라질수 있는 (확장이 필요할수 있는) 것은 파일의 형식에 따라 달라 지는 재생 방법이다.) 여러 동영상 플레이어가 재생 방법에 대한 분리를 해 놓아서 우리는 새로운 코덱만 설치 하면 볼 수 없던 영상도 재생 할 수 있다. 또한 새로운 영상 표준이 나온다 하더라도 분리를 통해 구현이 이루어 졌기 때문에 확장에 용이 하다고 볼 수 있다.

실제로 동영상 플레이어가 이렇게 구현 되었다는 의미는 아니다 (단지 추측일 뿐이다)

Strategy Pattern은 유지 보수와 프로그램 확장을 위한 기반을 만들어 주는 패턴이다. 프로그램을 기획하는 단계에서 부터 해당 프로그램이 어느 정도 까지 확장할지 예상하고 그 기준을 고정 시켜 버리는 것이 아니라, 최대한 유연하게 코딩을 해서 어떠한 상황에서 든지 확장이 용이한 프로그램을 구현해야 한다.