Strategy Pattern 전략 패턴 디자인 패턴 Class를 쉽게 교환하자!
■ 목적
: 필요한 순간 Class(정책이나 알고리즘)을 교체하여 사용하는 디자인 패턴
위와같이 작업하다가 필요에 따라 Class 를 교환해서 사용하기 위해서 만들어졌다.
■ 예시
과거에 오리는 동일하게 quack하고 swim 그리고 display만 있으면 되었다.
모습만이 다르니 대부분의 것들은 Duck이라는 하나의 추상 클래스(abstract : 함수 정의도 있고 함수 선언도 있는 클래스)로 모든 것이 가능했다.
하지만 RubberDuck이 추가 되면서 상황이 바뀌었다. RubberDuck은 quack 소리가 다르다. 그래서 RubberDuck이 quack을 만들 수 있도록 따로 클래스에 함수를 만들어 주어야 했다.
심지어 fly 할 수도 없다. 그래서 override를 하되 기능을 아무것도 넣지 못하는 이상한게 만들어졌다.
그래서 다음과 같은 문제가 생겼다.
- 상위 클래스가 업데이트 되면 하위 클래스 전체가 영향을 받는다.
- 상속만으로는 문제를 해결할 수 없다. coupling 문제가 생기고 flex하지 못 한 클래스가 생겨버린다.
■ 의도와 동기
- 변화하는 것들을 Encapsulation 하고(Class 화) 상호 교환이 가능하도록 만듬
- 각각을 구분하는데 interface를 사용해서 구분한다. 클라이언트와 독립적인 다양한 알고리즘을 적용할 수 있도록 한다.
- 사용자가 모르고 있는 데이터를 사용하여 여러 정책들이 반영될 수 있도록 구현한다.
- 여러 정책이 수행되어야 하는 조건들 (if-else, switch)문이 없어질 수 있다.
■ 클래스 다이어그램
-
Strategy라는 큰 인터페이스(내부가 텅텅 비고 함수의 선언만 있는)가
-
여러개의 다른 클래스들(ConcreteStrategy : 내부가 구현된 클래스들)을 상속한 관계로 묶이고
-
Strategy를 활용하는 Context 클래스는 Strategy를 Composition(클래스 내부에 변수로 선언)하여 사용한다.
■ 용어설명
- Strategy
- 정책이 수행해야 하는 기능들을 인터페이스로 선언
- ConcreteStrategy
- Strategy에 선언된 여러 기능들을 구현
- 다양한 정책들이 구현될 수 있음
- Context
- 어떤 ConcreteStrategy 가 수행 될 것인지에 따라 정책을 선택한다
- Strategy에 선언된 메서드 기반으로 접근한다.
- Strategy 클래스와 Context 클래스는 선택한 알고리즘이 동작하도록 협력한다.
■ 결론
- 인터페이스에 선언된 기능을 구현한 다양한 정책을 다른 클래스에 영향을 주지 않고 추가, 삭제 할 수 있다.
- 각 기능을 if-else 조건문을 구현하는 것이 아닌 정책 클래스를 선택하도록 구현하여 유지보수가 용이하다.
■ 유사한 패턴
바로 Sort를 구현할 때 이것을 이용하면 좋다.
메인 저장소 : 개발자봉순이 : 네이버 블로그 (naver.com)
#디자인패턴 #designpattern