1.Strategy Pattern

문제제기

- 우리가 기존의 객체지향 프로그래밍을 활용하여 게임을 만든다고 가정해보자.
Person 이라는 Super Class를 사용하여 다음과같이 여러 직업군의 캐릭터를 정의할 수 있을 것이다.

 

- 만약 우리가 attack 이라는 method를 구현하고자 한다. 그러나 여기서 야기될 수 있는 문제점이 여러개가 보인다.
 1) 만약 Person을 상속받은 허수아비 가있다면 attack을 할 수 없어야한다. (그렇다면 그냥 override 해버리면 되잖아?)
 2) attack은 override를 해서 해결했지만, 만약에 추가적으로 sound 같은 행위를 구현해야한다면? interface가 계속늘어가고, 계속해서 override를 통해 재정의 해야할 것이다.

 

- 그렇다면 차라리 Interface를 implements 하면 어떻게 될까?
 이런식으로 만든다면, 물론 일부만 attack을 할 수 있고, 일부는 안하게 선택적으로 행위를 정의 할 수 있지만, Attack 행동에 대한 코드재사용성은 전혀 기대할 수 없다(클래스별로 공격 행위에 대한 코드를 작성해야 하며, 새로운 클래스가 생겼을때나, 클래스의 공격을 패치를 통해 변동시키고 싶다면??). 그리고 별개로 새로운 행동이 추가되면 될수록 재사용성은 전혀 기대할 수 없다.

 

문제를 명확하게 구체화

- attackAble 인터페이스 사용은 처음에는 괜찮아 보이지만, 자바의 인터페이스는 코드가 전혀 들어가있지 않기 때문에, 재사용성은 꽝이다.
- 즉 attack 이외의 한 행동이 추가될때마다, 그 interface를 구현한 obejct를 찾아가 일일히 코딩해야 한다는 것이다.
- 여기서 찾아낼 수 있는 디자인원칙이 있다.

디자인 원칙1
어플리케이션에서 달라지는 부분을 찾아 달라지지 않는 부분으로부터 분리시킨다

 

디자인 패턴 원리 적용

 - 위 다이어그램에서는 attack, run, drink 등의 행동이, 바뀌는 부분 일 것이다. 그러나 글쓴이의 편의를 위해, attack의 예시만 한번 확인 해보겠다.

- attack에 대한 class 집합은 어떻게 디자인 할 수 있을까?
 우선 최대한 유연하게 만들어야한다. 또한 Person의 인스턴스에 attack을 할당할 수 있어야한다. 즉, Person의 클래스에 Setter를 만들어서 프로그램의 실행중에도 동적으로 할당할수 있는게 가장 좋다.
여기서 디자인원칙 2번째를 알 수있다.

디자인 원칙2
구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

 

 

- 위와 같이 attackBehavior 라는 interface를 구체화하여 공격을 나타내는 클래스를 만들었다.
 (물론 객체지향 패턴에서 클래스는 변수와 메소드를 둘다가지고 있어야한다. 행동만 나타내는 클래스는 이상할 수 있다. 그러나 더 구체화 시키다보면, 클래스별 axe 시너지등을 계산할때 getter setter등을 통해 내부 멤버변수를 다룰 수도 있을것이다.)

 

 

- 위에서 만든 캡슐화된 공격 행동을 Person과 합쳤다.
 기존 객체지향 프로그래밍의 "A는 B이다" 라는 관계가 아니라 "A에는 B가있다" 와 같이 합치는 것을 구성(composition) 이라고 한다. 이 테크닉은 매우 중요하며 디자인의 3번째 원칙이다

디자인 원칙3
상속보다는 구성을 활용한다.

 

 위 패턴이 바로 Starategy Pattern 이다. 즉 각각을 캡슐화 하여, 교환해서 사용할 수 있도록 만든다. Starategy Pattern을 적용한다면, Object를 사용하는 클라이언트와는 독립적으로 Obejct의 캡슐화된 행위등을 변경할 수 있다.

 

 

위 글은 Head first design Patterns책의 내용을 기초로 작성되었습니다.