전략패턴
전략패턴의 핵심은 객체의 내부에서 나타날 수 있는 행동을 따로 분리하여 여러개로 확장하여 일일이 서브클래스마다 행동에 대한 하드코딩을 피한다는 것입니다.
하드코딩을 하지않는 대신, 생성자를 통해 매뉴얼(전략)을 선택하여 집어넣으면
끝입니다.
위 상황은 단순한 상황입니다. 이전 설계 할 때 모든 유닛 오브젝트는Att을 할꺼로 예상하고 베이스 오브젝트에 그 가상함수를 넣어놨습니다.
그리고 3개의 하위 클래스를 설계합니다. Marin,Medic,Tank 근데 문제가하나 있습니다. Medic은 예상을 벗어나 Att에 대한 행동을 정의할 수 없게 되었습니다. 해병은 총을 쏘고, 탱크는 캐논샷을 쏘지만 메딕은 공격을 하지 못합니다. 그래서 설계한 방법으로 베이스 클래스의 Att함수를 오버라이딩해서 {} 이렇게 빈칸으로 두기로 했습니다. 하지만 이런식으로 베이스 클래스의 가상함수가 늘어날수록 동작을 하지 않아야 되는 함수들을 일일이 오버라이딩으로 처리하여 코딩하는 것은 상당히 귀찮은 일입니다. 문법때문에 어쩔수 없다는 생각을 가져도 만약 1000개의 오브젝트에서 그런 하드코딩을 하라면….. 더불어 코딩이 실제로 들어가므로 유지보수때도 신경쓸 수 밖에 없습니다. 예를들어 베이스클래스의 기능이 10가지 인데 메딕은 그중에 3가지 밖에 쓰지 않는다고 가정해 봅시다. 그럼 나머지 7개를 빈칸으로 오버라이딩 할 수 밖에 없는 것이죠
이때 전략패턴을 사용하면 이런 수고를 덜 수 있을 뿐더러 다른 행동까지도 동적으로 정의할 수 있는 유연성이 생깁니다.
위 그림에서 같이 전략패턴에서 전략을 나타내는 객체를 매뉴얼이라고 표현했습니다. 제가 생각하기에는 매뉴얼이 전략패턴의 컨셉과 잘 맞는것 같습니다. 전략 패턴의 핵심은 객체의 내부에서나타날 수 있는 행동을 따로 분리하여 여러 개로 확장하여 일일이 서브클래스마다 행동에 대한 하드코딩을 피한다는 것입니다. 하드코딩을 하지 않는 대신, 생성자를 통해 매뉴얼(전략)을 선택하여 집어넣으면 끝입니다. 위에서 Att함수는 그 내부에서 매뉴얼을 참조해서 행동하므로 다른 Att행동을 취할 수 있습니다. 만약 생성자에 매뉴얼을 넣지 않을때 Att함수는 아무일도 하지않게 설계하면 메딕을 생성하는데 문제가 없습니다.
하나는 매개변수를 직접 마련하여 전달하는 형식이고 다른 하나는 객체 자신을 매개변수로 넘겨 접근권한을 주고 처리하게 하는 형식입니다. 전자는 매개변수 인터페이스에 맞춰서 전략객체의 기능을 사용하기때문에 매개변수를 위한 준비가 필요합니다. 그 인터페이스가 많은 서브클래스들을 고려하여 너무 복잡하다면 어떤 서브 객체에게는 쓰이지 않게 되는 매개변수가 생길 수도 있습니다.
후자는 매개변수에 객체 자신의 참조자를 넘겨 처리하는 방법입니다. 이는 상태패턴과 동일한 방법이라고 하는데요 본객체와 전략객체간의 겹합도가 높아지게 되는 방법이기도 한데 강결합으로해야 효율이 나올 수 밖에 없는 경우외에는 별로임
구구단 2단 2단노트
– 결론-
전략패턴은 말그대로 객체의 전략을 런타임에 다르게 설정할 수 있게 해주는 패턴입니다.
객체안의 여러 매서드들에 대한 행동을 무한한 형태로 전략을 조합하여 변경할 수 있습니다.
행동 전체를 변경할 수도 있지만 행동에 쓰이는 알고리즘 하나만 변형하게 하여 성능의
향상을 꾀할 수도있습니다.
예제)
#include <iostream> using namespace std; #define interface struct interface Manual { virtual void Att() = 0; }; class GunShot :public Manual { public : void Att() { cout << "따다다다당"<<endl; } }; class CanonShot : public Manual { public : void Att() { cout <<"푸학 폭~!"<<endl; } }; class SteamPack : public Manual { public : void Att() { cout <<"따다다다당 따다다다당 따다다다당~!"<<endl; } }; class Unit { Manual *_strategy; public : Unit(Manual *strategy=0) { _strategy = strategy; } virtual ~Unit() { } void Att() { if(_strategy) { _strategy->Att(); } } virtual void Display() =0; }; //*************************Marin***************************** class Marine :public Unit { SteamPack *sp; public : Marine(Manual *ma) : Unit(ma) { sp = 0; } void SteamPackUpGrade() { if(sp == 0) { sp = new SteamPack(); } } void SteamPackAttack() { if(sp) { sp->Att(); } } ~Marine() { if(sp) { delete sp; } } public: void Display() { } }; //*************************Enginneer***************************** class Medic : public Unit { public: Medic(Manual *ma=0) : Unit(ma){ } public : void Display() { } }; //*************************Tank***************************** class Tank: public Unit { public : Tank(Manual *ma) : Unit(ma) { } public: void Display() { } }; void main() { Unit *unit = new Marine(new GunShot); unit->Att(); Marine *marine = dynamic_cast<Marine*>(unit); marine->SteamPackUpGrade(); marine->SteamPackAttack(); Unit *unit2 = new Tank(new CanonShot); unit2->Att(); Unit *unit3 = new Medic(); unit3->Att();
delete unit; delete unit2; delete unit3; } |
'Programing > Design Pattern' 카테고리의 다른 글
| 상태패턴 예제 (0) | 2016.11.30 |
|---|---|
| State Pattern (상태패턴) (0) | 2016.11.30 |
| 템플릿 메서드 (0) | 2016.11.30 |