스트래티지 패턴(strategy pattern)
알고리즘 군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
우선 이 정의는 내가 지금 공부하고 있는 'Head First Design Patterns'이란 책에서 정의하고 있다. 그런데 개인적으로는 잘 와닿지가 않는다. 조금 더 쉽게 이해해보자.
예를 들어 RPG 게임에서 캐릭터는 직업을 갖기 전 무기는 맨손이다. 캐릭터의 공통적인 행위(걷기, 앉기, 뛰어다니기) 등은 일반적으로 변하지 않는 행위(어떤 캐릭터든 동일한 행위)라고 보고, 캐릭터의 직업에 따라 들 수 있는 무기의 경우 검, 지팡이, 활, 총 등 직업에 따라 무기를 드는 행위는 변한다고 봤을 때 "애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다."는 디자인 원칙에 따라 '무기'를 따로 분리시켜 클래스로 캡슐화한다.
만약 캐릭터의 공통 행위(걷기, 앉기, 뛰어다니기)와 변하는 행위(무기 드는 행위)를 한 클래스에 두고 캐릭터1 하위 클래스를 만든 다음 캐릭터 클래스를 상속받아 하위 클래스의 무기를 Override 하는 방식은 괜찮을까?
이럴 경우 RPG게임이 업데이트가 되어 무기가 없는 캐릭터인 상인이 추가가 되었다고 하면, 상인은 무기를 들지도 않는데 무기를 override 하여 빈 공간을 만들어 놓아야 한다. 그렇지 않으면 공격할 수 없는 상인이 공격하는 상인이 되는 경우가 생기게 될 수 있다.
또한 무기 인터페이스에 구상 클래스를 두지 않고 캐릭터의 서브 클래스(캐릭터1 클래스)에 implements를 하여 구현을 하는 방식은 괜찮을까? 이럴 경우 특정 직업이 성장을 하여 한 단계 위로 승급을 하여 직업 계열 클래스가 추가된다고 했을 때 같은 코드를 중복하여 사용하게 되는 경우가 생기게 된다.
따라서 캡슐화할 땐 "구현이 아닌 인터페이스에 맞춰서 프로그래밍한다."는 디자인 원칙에 따라 무기를 인터페이스로 만들고 직업 특성에 맞는 구상 클래스를 만들어 놓으면 이 인터페이스를 활용할 공간에서 가져다가 쓰면 된다.
- 잘못된 부분이 있다면 피드백 주시길 바랍니다!!!