3. Strategy Pattern (전략 패턴)

Strategy Pattern은 언제 사용해야하는 패턴일까?

 

1. Purpose

Defines a set of encapsulated algorithms that can be swapped to carry out a specific behavior

행위를 캡슐화하여 동적으로 자유롭게 바꿀수 있게 해준다.

 

2. Use When

• The only difference between many related classes is their behavior.
• Multiple versions or variations of an algorithm are required.
• The behavior of a class should be defined at runtime.
• Conditional statements are complex and hard to maintain

 

예시를 통해 알아보자.

Original Design

오리를 표현하기 위해 Duck이라는 객체를 만든다고 하자. 행동으로 Quack, Swim, Display를 가지며 각각의 오리들은 생김새가 다르기 때문에 그에맞는 display함수를 implement한다. 이때 Fly이라는 새로운 Behavior를 추가한다고 하자.

 

Add fly Behavior

 

이때 간단히 fly이라는 Behavior를 상위 Duck객체에 추가함으로서 해결할 수 있다. 현재 존재하는 예시의 오리들은 모두 날수있기 때문이다. 날지못하는 오리가 있다면 어떨까? 욕조에 띄우는 고무인형 오리 Rubber Duck은 날지못하며 울음소리도 다르다.

 

Add RubberDuck

다형성을 이용하여 울음소리(quack)를 낼때 다른 소리를 내도록 구현해주며, fly함수는 아무것도 하지않도록 구현해준다. 한두개는 괜찮다고 하자.

 

하지만 추가적으로 나무로만든 장난감 오리 Decoy Duck을 추가한다면 어떨까? Decoy Duck은울음소리도 내지못하며 날지도 못한다. 이렇게 각각의 Behavior에 대하여 overriding을 하여 추가적으로 구현해야한다면 상당히 불편할것이며, 새로운 Behavior의 추가에도 유연하게 대처하지 못한다.

 

여기서 알수있는것은 무작정 상속을 이용하는것은 좋은 방법이 아니라는 것이다. 상속은 재사용성이라는 측면에서는 좋은 방법이 될 수 있지만, 유지보수면에서는 많은 시간을 쏟게 만든다. 이때 사용할 수 있는 패턴이 Strategy Pattern(전략패턴)이다.

 

 

전략패턴을 적용한 Duck 구조

위 그림은 전략패턴을 적용한 Dcuk 구조이다. 상위 클래스인 Duck객체에서 수시로 변하는 Behavior였던 fly와 quack을 별도의 Interface로 생성한다. Duck객체는 각 Behavior를 멤버변수로 가지고 있는다. Duck을 상속하는 각 오리들은 Duck에서 멤버변수로 가지고있는 Behavior를 자신에게 필요한 전략(Algorithm)으로 갈아 끼우면서 동적으로 사용할 수 있도록 한다. 이는 기본 OO Principle중 'Encapsulate what varies' , 'Program to an interface, not an implementation' 과 'Favor composition over inheritance' 을 잘 따르고 있다.

 

만약 Client가 새로운 종류의 Duck을 추가한다고 하면, 적용할 수 있는 FlyBehavior, QuackBehavior에서 필요한 Behavior를 갖게할 수 있다. 추가적으로 다른 울음소리를 가진 오리가 있다고 하더라도  QuackBehavior를 상속하는 Behavior를 추가로 정의하고 변수가 가리키도록 하여 해결할 수 있다.

 

Strategy Pattern

적용방법으로는

첫째, Behavior에 대해 필요한 algorithm들을 정의하고

둘째, 그것들을 하나의 Strategy으로 묶는다.

셋째, Context에서 변수로 Strategy를 가지게 하며 자유롭게 바꾸어 다른 알고리즘을 적용할 수 있도록 만든다.