State Pattern과 Strategy Pattern의 공통점과 차이점

공통점

인터페이스를 사용함으로써 Concrete Class를 캡슐화 한다.

 

따라서 Context Class에서, 어떤 클래스가 할당 됐는지에 관계 없이 인터페이스 만을(Strategy, State) 인자로 받아서 그대로 가상 메서드를 수행하는 코드가 적혀있다. 즉, 두 패턴 모두 Context Class는 영향을 받지 않고 유연한 변경에 대처가 가능하다는 것이다.

 

 

 

 

 

차이점

표면상으로는 다를게 없는데 왜 굳이 분리를 해놨을까.

 

차이점은 다음과 같다.

State는, State에 따른 로직의 끝에, setState(new State())를 호출함으로써 State를 스스로 변환할 수 있는데 반해,

Strategy의 경우 외부에서 데이터의 입력이 필요하다.

즉, Strategy 패턴의 경우 어떤 Concrete Class를 할당할지 client 혹은 사용자가 결정을 해야한다는 것이다.

State 패턴의 경우는 현재 선풍기가 Off 상태이므로 강풍 버튼을 누른다면 On 상태로 상태 전이를 하면서 선풍기를 돌리는 것이고,

On 상태에서 강풍 버튼을 누른다면 이미 On State이므로 아무런 상태 전이가 없다는 점이 다르다는 것.

(하지만 On 상태라도 약풍이 불고 있었다면 또 달라지겠으나 이는 State가 3개라는 관점이다.)

 

따라서 다음과 같이 정리할 수 있다.

Strategy Pattern : 행동(알고리즘)을 소유한 객체를 실행 시에 선택할 수 있게 하여 상황에 맞는 행동을 하게 하는데 유용

 -> 다양한 알고리즘이 짜증나는 경우 고려

State Pattern : 다양한 상태변화(전이)가 아주 복잡한 로직을 제어하는 데 유용

 -> if, else 문에 의한 분기점이 많아 복잡한 경우 고려