[Design Pattern] 전략 패턴(Strategy Pattern)

Strategy Pattern 이란

---

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

독립적으로 알고리즘을 변경할 수 있다는 말은 알고리즘을 사용하는 클라이언트에서 어떠한 concrete 객체를 사용하는지 모르지만, Interface에 정의된 대로 사용할 수 있음을 의미한다.

아래의 예제에 적용해서 이야기해보면, Duck 추상 클래스에서 어떠한 concrete 한 FlyBehavior 나 QuackBehavior 객체를 사용하는지 모르지만, Interface로 정의해 둔 FlyBehavior, QuackBehavior에 정의된 대로 사용할 수 있다. Duck 추상 클래스는 어떠한 concrete 객체를 사용하는지 모르기 때문에 이 부분을 캡슐화되어 있다고 한다.

 

Strategy Pattern 이 사용되는 Case

1) 알고리즘이 다양하고 변형되어야 하는 경우

2) 사용되어야 할 행동, 알고리즘이 runtime에 결정되어야 하는 경우

 

Strategy Pattern 예제

Strategy Pattern 예제 클래스 다이어그램으로 Class 들 간의 관계를 확인해보도록 하자.

Strategy Pattern Class Diagram Exmple

 

위의 Strategy Class Diagram을 간략하게 설명해보면, Duck 추상 클래스가 있고 이를 상속받는 concrete Duck 클래스들이 있으며 각각 클래스에서 어떻게 보이는지를 display 메서드를 정의하고 있다. (display의 경우에는 concrete Duck들 마다 전부 다르게 override 해주어야 하기 때문에 상속한 sub-class에서 ovrride 메서드를 구현한다.)

 

각각의 Duck들의 다양한 부분인 FlyBehavior와 QuackBehavior는 별도의 Interface로 정의하고 이에 대한 concrete 한 행동 클래스들이 구현되어 있다. 그리고 Duck 추상 클래스와 각 행동에 대한 Interface는 composition(구성) 관계를 맺고 있다. (composition 관계를 맺는다는 것은 Duck 추상 클래스의 멤버 변수로 가지고 있다는 것을 의미한다.) 이 부분이 객체지향 원칙인 Inheritance 보다 Composition을 사용하라 라는 부분에 해당한다. 이렇게 Duck 추상 클래스를 직접 Inheritance 하지 않고, 행동 Interface 들을 composition 함으로써 다형성을 이용해 각 구현체가 정의되기 때문에, Duck 추상 클래스에서는 실제 구현체에 대해서 알지 못해도 된다. (캡슐화와 시스템의 유연성이 크게 향상될 수 있다.)

 

위의 Strategy Class Diagram의 예제를 Strategy Pattern을 적용한 결과에 대해서 위에서 언급한 적절한 case가 맞는지 살펴보자.

1) 알고리즘이 다양하고 변형되어야 하는 경우

• FlyBehavior 클래스와 QuackBehavior 클래스가 다양하고 Duck 마다 다르게 적용되어야 한다.

2) 사용되어야 할 행동, 알고리즘이 runtime에 결정되어야 하는 경우

• 각 Duck 클래스마다 실행하는 행동들이 초기에 결정될 수 도 있지만, 이를 runtime에 동적으로 변경할 수 있다. 이는 각 행동 클래스들이 Duck 클래스와 composition 관계에 있기 때문에 가능하며, setter 함수로 이를 설정할 수 있다.

 

Strategy Pattern의 중요 부분

Strategy Pattern에서 핵심은 알고리즘을 사용할 클라이언트와 알고리즘 군을 정의하는 부분의 관계이다. 위에서 언급한 Inheritance 보다 Composition을 사용하라 라는 의미를 나름대로 정리해 보았다.

• 알고리즘 군이 클라이언트를 직접 상속해서 알고리즘을 구현하는 구조는 좋지 않다.
  • 동일한 알고리즘을 사용하는 클라이언트가 있는 경우 코드가 중복될 수 있다.
  • 알고리즘을 직접 구현하고 있기 때문에 캡슐화되어 있지 않다.
• 클라이언트가 concrete한 알고리즘과 composition 관계로 구성되는 것은 좋지 않다.
  • 클라이언트의 알고리즘을 변경하기 위해서는 클라이언트 코드가 수정되어야 하며 이는 유연한 구조가 아니다.
  • 알고리즘을 구현하는 객체를 가지고 있으며 해당 알고리즘에 대해 캡슐화되어 있다.
• 클라이언트가 알고리즘군에 대한 Interface와 composition 관계로 구성되도록 한다.
  • 클라이언트의 알고리즘을 Interface를 구현한 알고리즘으로 변경 가능하다. (다형성을 이용한 동적인 구조)
  • 알고리즘을 구현하는 객체를 가지고 있으며 해당 알고리즘에 대해 캡슐화되어 있다.

 

해당 자료는 "Head First Design Pattern" 책을 참조해서 작성되었습니다.