1. 디자인 패턴 박광호(hopkh12@gmail.com) http://hopkh.nayana.kr/tc/

2. 참고자료 GoF디자인패턴! 이렇게 활용한다 http://code1009.tistory.com/category/셈말짓기/GoF http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf http://www.dofactory.com/Patterns/Patterns.aspx http://elky.tistory.com/category/소프트웨어%20개발

3. Abstract Factory(제품(Product)별 객체 생성) 구체적 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기위한 인터페이스를 제공한다.

4. Abstract Factory(제품(Product)별 객체 생성) class Device{}; class DeviceGraphics : Device { Grahpics* CreateWindows(); Grahpics* CreateLinux(); } class DeviceSound : Device { … } class Engine{ Grahpics* CreateGraphics(); Sound* CreateSound(); } class EngineWindows : Engine{ Graphics* CreateGraphics(){ return DeviceGraphics->CreateWindow(); } Sound* CreateSound(){ … } };

5. Builder(부분 부분 생성을 통한 전체 객체 생성) 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여 서로 다른 표현이라도 이를 생성할 수 있는 동일한 구축 공정을 제공할 수 있도록 한다.

6. Builder(부분 부분 생성을 통한 전체 객체 생성) class NPC{ void SetHP( … ){ … }; void SetSP( … ){ … }; }; void NPCBuilder{ virtual void SetHP() { … } virtual void SetSP() { … }; NPC* m_pNPC; } class NPCBuilder1 : NPCBuilder{ virtual void SetHP() { m_pNPC->SetHP( 100 ); } virtual void SetSP() { m_pNPC->SetSP( 100 ); }; } class NPCBuilder2 : NPCBuilder{ … } void Stage{ void Create( NPCBuilder* pNPCBuilder ){ pNPCBuilder->SetHP(); pNPCBuilder->SetSP(); } };

7. Factory Method(대행 함수를 통한 객체 생성) 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한결정은 서브클래스에서 이루어지도록 Factory Method 패턴은 서브클래스에게 인스턴스 생성의 책임을 미룬다.

8. Factory Method(대행 함수를 통한 객체 생성) class App { virtual View* CreateView() = 0; }; class View { }; class MyApp : public App{ View* CreateView(){ return new MyView; } }; class MyView : public View{ };

9. Prototype(복제를 통한 객체 생성) 견본적(prototypical) 인스턴스를 사용하여 생성할 객체의 종류를 명시하고 이렇게 만들어진견본을 복사해서 새로운 객체를 생성한다.

10. Prototype(복제를 통한 객체 생성) class NPC{ virtual NPC* Clone() = 0; NPC( const NPC& npc ){ … } }; class NPC_1{ virtual NPC* Clone(){ return new NPC_1( *this ); } }; NPC* p1 = new NPC_1; NPC* p2 = p1->Clone();

11. Singleton(최대 N개까지로 객체생성을 제한) 클래스에서 만들 수 있는 인스턴스가 오직 하나일 경우에 이에 대한 접근은 어디에서든지 하나로만 통일하여 제공한다.

12. Singleton(최대 N개까지로 객체생성을 제한) //개수제한 class NPC{ static ints_iTotalCount = 20; static NPC* CreateNPC(){ … } static void DeleteNPC(){ … } protected: NPC(){} NPC( const NPC& npc ){ ... } }; //단일객체 class NPCMng { static NPCMngGetInstance(){ return s_Instance; }; protected: static NPCMngs_Istance; NPCMng(){} NPCMng(const NPCMng &p )(){} };

13. Adapter(기존 모듈 재사용을 위한 인터페이스 변경) 클래스의 인터페이스를 클라이언트가 기대하는 형태의 인터페이스로 변환한다.어댑터 패턴은 서로 일치하지 않는 인터페이스를 갖는 클래스들을 함께 작동 시킨다.

14. Adapter(기존 모듈 재사용을 위한 인터페이스 변경) //현재버전 class Font { virtual SIZE GetSize(){ … } }; //새버전 class Font { virtual FontSizeGetSize(){ … } }; //개선 class GFont{ void SIZE GetSize(){ FontSize Size=m_Font.GetSize(); return SIZE( Size.x, Size.y ); } protected: Font m_Font; };

15. Bridge(인터페이스와 구현의 명확한 분리) 구현과 추상화 개념을 분리하려는 것이다. 이로써 구현 자체도 하나의 추상화 개념으로 다양한 변형이 가능해지고, 구현과 독립적으로 인터페이스도 다양함을 가질 수 있게 된다.

16. Bridge(인터페이스와 구현의 명확한 분리) class Graphics{ virtual void DrawShape() = 0; }; class GraphicsDX9 : Graphics{ virtual void DrawPrimitive(){ … }; } class GraphicsDX10 : Graphics{ virtual void DrawPrimitive(){ … }; } class Engine{ void DrawShape(){ m_pGraphics->DrawShape(); } };

17. Composite(객체간의 부분-전체 관계 형성 및 관리) 부분-전체 계층을 나타내기 위한 복합 객체를 트리 구조로 만든다.Composite 패턴은 클라이언트가 개별적 객체와 복합 객체 모두를 동일하게 다루도록 한다.

18. Composite(객체간의 부분-전체 관계 형성 및 관리) class Base{ }; class Entity : Base{ }; class Node : Base{ std::list< Base* > m_BaseList; };

19. Decorator(객체의 기능을 동적으로 추가,삭제) 객체에 동적으로 새로운 서비스를 추가할 수 있게 한다. Decorator패턴은 기능의 추가를 위해서 서브클래스를 생성하는 것보다 융통성 있는 방법을 제공한다.

20. Decorator(객체의 기능을 동적으로 추가,삭제) class UI{}; class Window : UI{}; class CheckBox : Window{}; class Button : CheckBox{}; class RadioButton : Window{ CheckBox* m_pCheckBox; }

21. Facade(서브시스템의 명확한 구분 정의) 서브시스템을 합성하는 다수의 객체들의 인터페이스 집합에 대해 일관된 하나의 인터페이스를 제공할 수 있게 한다. Facade는 서브시스템을 사용하기 쉽게 하기 위한 포괄적 개념의 인터페이스를 정의 한다.

22. Facade(서브시스템의 명확한 구분 정의) class Graphics{}; … class Sound{}; … class Input{}; //현재 Graphics* pG = new Graphics; … Sound* pS = new Sound; … Input* pI = new Input //개선 class Engine { void Create(){ m_pG = new Graphics; m_pS = new Sound; m_pI = new Input;c } Protected: Graphics* m_pG; Sound* m_pS; Input* m_pI; };

23. Flyweight(작은객체들의 공유) 대규모의 미세한 객체들을 효과적으로 사용하기 위해서는 공유 개념을 도입

24. Flyweight(작은객체들의 공유) class Mesh{ void CreateTexture( … ){ Texture* pRt = NULL; if( IsLoadTexture ( … ) ){ pRt = new Texture( … ); pRt.push_back( … ); } else{ pRt = m_TextureList.Find( … ); } m_pTexture = pRt; } protected: Texture* m_pTexture; std::list< … > m_TextureList };

25. Proxy(대리 객체를 통한 작업 수행) 다른 객체에 접근하기 위해 중간 대리 역활를 하는 객체를 둔다.

26. Proxy(대리 객체를 통한 작업 수행) class Mesh{ void CreateTexture( … ){ m_pTex = TextureMng.Get( … ) } protected: Texture* m_pTexture; }; class TextureMng{ Texture* Get( … ){ Texture* pRt = NULL; if( IsLoad( … ) ){ pRt = new Texture( … ); pRt.push_back( … ); } else{ pRt = m_TextureList.Find( … ); } return pRt; } protected: std::list< … > m_TextureList; };

27. Chain of Responsibility(행위 개선을 위한 패턴) 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴이다.하나의 요청에 대한 처리가 반드시 한 객체에서만 이루어지지 않고, 여러 객체에게 그 처리의기회를 주려는 것이다. 즉, 이 패턴에서는 하나의 서비스 처리를 여러 객체에 나눌 수 있도록한다. 메시지를 수신하여 처리를 담당할 객체들을 하나의 연결 고리로 만들고, 실제로 요청을처리하는 객체를 만날 때까지 계속해서 요청을 전달하게 한다.

28. Chain of Responsibility(행위 개선을 위한 패턴) class UI{ UI( UI* pHelp ){ … } void ShowHelp(){ m_pHelp->Show(); }; UI* m_pHelp; }; class UIHelpMain : public UI{ }; class UIHelpOption : public UI{ }; class UIMain{}; class UIInventory{}; class UIOption{}; UIHelpMainuIHelpMain; UIHelpOptionuHelpOption; UIMainuUIMain(&uUIHelpMain); UIInventoryuUIInventory(& uUIHelpMain); UIOptionuUIOption(& uHelpOption)

29. Command(수행할 작업의 일반화를 통한 조작) 요청 자체를 객체화하는 것이다. 그리고 서로 다른 요청을 객체화하여 클라이언트에게 파라미터로 넘겨줄 수 있게한다.

30. Command(수행할 작업의 일반화를 통한 조작) class Mesh{ void Render(){ … }; }; class Particle{ void Draw(){ … }; }; class RD{ virtual void Render() = 0; }; class RD_Mesh{ RD_Mesh( Mesh* p ){ … } void Render(){ m_p->Render(); } }; class RD_Particle{ RD_Particle( Particle* p ){ … } void Render(){ m_p->Draw(); } };

31. Interpreter(간단한 문법에 기반한 검증 및 작업 처리) 어떤 언어는 문법에 대한 표현을 정의하면서 그 언어로 기술된 문장을 해석하는 기법을 표현하기 위해서 인터프리터도 함께 정의하는 경우가 있다.

32. Interpreter(간단한 문법에 기반한 검증 및 작업 처리) class Paser{ } class PaserXML : Paser{… } class PaserBinary : Paser{… }

33. Iterator(동일 자료형의 여러 객체 순차 접근) 복합 객체 요소들의 내부 표현 방식을 공개하지 않고도 순차적으로 접근할 수 있는 방법을 제공한다.

34. Iterator(동일 자료형의 여러 객체 순차 접근) class LinkList{ structstData{ stData* m_pNext; intm_iData; }; LinkListIterGetIterator(){ return LinkListIter( m_pFirst ); }; stData* m_pFirst; }; class LinkListIter{ LinkListIter( LinkList::stData* p ){ m_pData = p; }; intGetData(){ return m_pData->m_iData; }; void Next(){ m_pData=m_pData->m_pNext; }; stData* m_pData; };

35. Mediator(M:N객체 관계를 M:1로 단순화) 객체들 간의 상호작용을 캡슐화하여 하나의 객체 안에 정의한다. Mediator 패턴은 각 객체가 관련성을 갖는 다른 객체에 대한 참조 관계를 직접 정의하기보다는 이를 독립된 다른 객체가 관리하게 한다.

36. Mediator(M:N객체 관계를 M:1로 단순화) class UI{ void Notify(){ m_pMessagePump->Notify( … ); } }; class MessagePump{ void Notify( … ){ } };

37. Memento(객체의 이전 상태 복원 또는 보관) 캡슐화를 위배하지 않으면서 객체의 내부 상태를 파악하고 표현함으로써 객체의 상태를 저장해둔 상태로 다시 복구 할 수 있게 한다.

38. Memento(객체의 이전 상태 복원 또는 보관) class History{ void SetData( … ){ … } HistoryData* m_pData; }; class HistoryData{ … }; class HistoryCreate{ static History* sCreate( HistoryData* pData ){ History* p = new History; p->SetData(pData ); } }; class Tool{ void Push( History* pHistory ){ … } History* Pop(){ … } std::deque<HistoryData*> m_List; }; Tool tool; tool.Push( HistoryCreate::sCreate( … );

39. Observer(One Source Multiple Use) 일대다의 관련성을 갖는 객체들의 경우 한 객체의 상태가 변하면 다른 모든 객체에 그 사항을 알리고 필요한 수정이 자동으로 이루어지도록 할 수 있어야 한다.

40. Observer(One Source Multiple Use) class Party{ static void sAdd( intiGroup, Player*p ){ … } static void sSay( intiGroup, const* char strMsg ){ … } protected: std::map<int, Player*> m_Player; }; class Player{ void CreateParty( intiParty ){ m_iParty = iParty; Party::sAdd( m_iParty, this ); } void SayParty( const* strMsg ){ Party::sSay( m_iParty, strMsg ); }; protected: intm_iParty; };

41. State(객체상태 추가 시 행위 수행의 원활한 변경) 객체 자신의 내부 상태에 따라 행위를 변경하도록 한다. 객체가 클래스를 바꾸는 것처럼 보일수 있다.

42. State(객체상태 추가 시 행위 수행의 원활한 변경) class Player{ State* m_pCurrent; State* m_pNext; void Tick(){ m_pCurrent->Tick(); … }; void NextState( … ){ … } }; class State{ void SetPlayer( … ){ … } Player* m_pPlayer; }; class StateWalk : public State{ void Tick(){ if( key[ space ] == ture ){ m_pPlayer-> NextState( StateRun ); }; } }; class StateRun : public State{ void Tick( … ){ … } };

43. Strategy(동일 목적의 여러 알고리즘 중 선택해서 적용) 다양한 알고리즘이 존재하면 이들 각각을 하나의 클래스로 캡슐화하여 알고리즘의 대체가 가능하도록 한다. Strategy패턴을 이용하면 클라이언트와 독립적인 다양한 알고리즘으로 변형할 수있다. 알고리즘을 바구더라도 클라이언트는 아무런 변경을 할 필요가 없다.

44. Strategy(동일 목적의 여러 알고리즘 중 선택해서 적용) class VB{ }; class VideoVB : public VB{ void Render( … ); }; class SystemVB: public VB{ void Render( … ); }; class Mesh{ void SetVB( VB* pVB ); };

45. Template Method(알고리즘의 기본 골격 재사용 및 상세 구현 변경) 오퍼레이션에 알고리즘의 기본 골격 구조를 정의하고 구체적인 단계는 서브클래스에 정의한다.Template Method 클래스의 서브클래스는 알고리즘의 구조를 변경하지 않고 알고리즘 처리단계들을 재정의 할 수 있다.

46. Template Method(알고리즘의 기본 골격 재사용 및 상세 구현 변경) class Base{ virtual void Tick( … ) = 0; virtual void Render( … ) = 0; }; class Mesh : public Base{ virtual void Tick( … ) { … } virtual void Render( … ) { … }; }; class Particle : public Base{ virtual void Tick( … ) { … } virtual void Render( … ) { … }; };

47. Visitor(작업 종류의 효율적 추가,변경) 객체 구조의 요소들에 수행할 오퍼레이션을 표한한 패턴이다. Visitor 패턴은 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을정의 할 수 있게한다.

48. Visitor(작업 종류의 효율적 추가,변경) class Geo{ }; class GeoComposite{ std::list< Geo* > m_List; }; class GeoRender{ void Draw( GeoComposite* pGeoComposite); }; class GeoRenderInstancing{ void Draw( GeoComposite* pGeoComposite); };