Strategy Pattern (AS3)

 Strategy Pattern 이란? 

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

- 동일 계열의 알고리즘군을 정의하고, 각 알고리즘을 캡슐화하며, 이들을 상호교환이 가능하도록 만듭니다. 알고리즘을 사용하는 클라이언트와 상관없이 독립적으로 알고리즘을 다양하게 변경할 수 있게 합니다.

여러 책들에서는 Strategy Pattern 을 위와 같이 정의 하고 있다. 두 정의의 공통적인 부분은 알고리즘군을 정의 하고 각각을 캡슐화 하여 교환 하여 사용할 수 있다고 언급 되어 있는 부분 인데, 이 말은 어떠한 로직에서 캡슐화 가능한 기능들은 따로 빼내어, 보다 확장에 유연한 프로그램 구조를 만든다는 말과 같다. 더 쉽게 말하면 알고리즘의 기준을 만들고 그 기준에 따라 구현 되는 알고리즘 들은 기준에 맞춰 설계가 되어 있기 때문에 교환해서 사용할 수 있다는 말이다. 실 생활에서 밧데리를 예로 들어 보면, 밧데리는 AA, AAA 라는 사이즈와 그 사이즈에 맞는 전압에 해당 되는 기준을 정해 놓았기 때문에 어느 회사가 만들든 기준만 맞추면 사용할 수 있게 되어 있다. 여기서 밧데리 사이즈와 사이즈에 맞는 전압이 정의해서 말한 알고리즘 군으로 비유 할수 있겠다.

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

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

구조를 만들면서 달라지는 부분과 달라 지지 않는 부분은 구분 하는것 부터 시작 된다. 헤드 퍼스트 디자인 패턴에서는 오리를 예를 들어 이 패턴을 설명하고 있다. 아래와 같이 오리는 여러 특징을 가질수 있다.

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

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

공통점 : "오리" 라고 불림

차이점 : 날 수 있고 없고, 소리가 다름

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

IFlyBehavior : 날수 있고 없고

IQuackBehavior : 소리가 다름

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

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

위와 같이 변경되는 부분에 대한 인터페이스를 만든후, 그 해당 인터 페이스를 바탕으로 달라지는 부분에 대한 실제 객체를 구현 한다. IFlyBehavior : 날수 있고 없고 에 대한 구상 객체

package {	
	public class FlyWithWings implements IFlyBehavior {
		public function fly() : void {
			trace("날수 있다");
		}
	}
}

package {
	public class FlyNoWay implements IFlyBehavior {
		public function fly() : void {
			trace("날수없다");
		}
	}
}

IQuackBehavior : 소리가 다름 에 대한 구상 객체

package
{
	public class QuachNoisy implements IQuachBehavior
	{	
		public function quach():void
		{
			trace("시끄럽게 소리를 낸다.");
		}		
	}
}

package
{
	public class QuachCalmly implements IQuachBehavior
	{
		public function quach():void
		{
			trace("조용히 소리를 낸다");
		}		
	}
}

실행 클래스

package {
	import flash.display.Sprite;

	public class Main extends Sprite {
		public function Main() {
			var duck:Duck = new Duck(new FlyWithWings,new QuachNoisy);
			duck.doFly();
			duck.doQuach();
			
			duck.setFlyType(new FlyNoWay);
			duck.setQuachType(new QuachCalmly);
			
			duck.doFly();
			duck.doQuach();
		}
	}
}

// output 날수 있다 시끄럽게 소리를 낸다. 날수없다 조용히 소리를 낸다

 위의 실행 클래스를 보면 duck을 생성한 후에 setFlyType 과 setQuachType 을 통해 duck 가지고 있는 속성을 변경 한 것을 볼수 있다. 또한 Dock 이 가지고 있는 속성인 flyType과 quachType 은 모두 인터페이스에 맞춰서 프로그래 밍 되어 있기 때문에 문제 없이 실행 된다. 이렇게 바꾸는 부분에 대한 기능을 나누고 그 나눈 기능을 인터페이스에 맞춰서 프로그래밍 하는 작업들이 처음에 Strategy Pattern의 정의 부분에서 봤던 "각 알고리즘을 캡슐화하며, 이들을 상호교환이 가능하도록 만듭니다." 이 말에 해당 하는 작업들이다.

 위와 같이 작업을 하면 좀 더 확장이 용이한 프로그램을 구현 할 수 있다. 어떠한 종류의 오리라도 만들수 있고, 그 특징을 분리 하여 구현 하였기 때문에 유지 보수도 용이해 진다. Strategy Pattern 은 아래의 원칙을 기반으로 구성 되어 있다. 상속 보다는 구성을 활용하고, 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다. Strategy Pattern은 유지 보수와 프로그램 확장을 위한 기반을 만들어 주는 패턴이다. 프로그램을 기획하는 단계에서 부터 해당 프로그램이 어느 정도 까지 확장할지 예상하고 그 기준을 고정 시켜 버리는 것이 아니라, 최대한 유연하게 코딩을 해서 어떠한 상황에서 든지 확장이 용이한 프로그램을 구현해야 한다.