'Software Engineering/Design Pattern'에 해당되는 글 19건

  1. 2014.08.05 Reactor 패턴과 Proactor 패턴
  2. 2011.02.10 Design Pattern Quick Reference
  3. 2008.02.09 데코레이터 패턴 (Decorator) (2)
  4. 2008.02.09 커맨드 패턴 (Command)
  5. 2008.02.09 플라이웨이트 패턴 (Fly Weight)
  6. 2008.02.09 프록시 패턴 (Proxy)
  7. 2008.02.05 스트래티지 패턴 (Strategy) (2)
  8. 2008.02.05 스테이트 패턴 (State) (2)

Reactor 패턴

- 어떠한 이벤트가 발생하면, 이곳으로 알려달라는 방식.

- 윈도우 메시지 핸들러처럼, 특정 이벤트가 발생한다면 통지 받겠다는 방식.


Proactor 패턴

- 특정 작업을 시키고, 그 작업이 완료되면 알려달라는 방식.

- IOCP에서 Completion Port가 이 방식을 취하고 있다.



얼추 비슷한데, 구현에서 차이점이 명확해진다.


Proactor는 작업을 시키면서 콜백함수를 직접 넘김으로써 구현되고, Reactor는 디스패쳐를 구현하는 구조가 일반적.


Reactor 패턴 사용시에는 디스패쳐를 통함으로써 스팟 포인트가 발생하게 되는 단점이 있다고 보면된다.


이에 비해 Proactor는 명령을 내린 작업에 대해서만 통지를 받게 된다.


IOCP의 예를 들면, 내가 물려놓은 소켓에 Recv 이벤트가 발생했다고 해도, WSARecv를 걸지 않으면, 해당 이벤트가 발생했는지 여부에 대해 통지를 받지 않음을 의미한다.


이는 이벤트 폭발로 인한 부하 발생이나, 스팟 포인트를 감소 시킬 수 있는 테크니컬한 멀티 스레드 프로그래밍이 가능하게 하려면 Reactor 패턴보다는 Proactor 패턴이 유리하다는 것을 의미힌다.



Reactor 패턴은 디스패쳐를 거치기 때문에, 직렬화에 유리하긴 하나 이 디스패쳐가 스팟 포인트가 되는 것이 일반적이란 단점이 있다. (물론 그렇지 않게 구현 할 수 도 있으나, 그렇게 멀티스레드 로직을 수행하기엔 예외 상황이 지나치게 커질 위험이 있다.) 


stateless 하게 구현하기 위해선 proactor 기반의 처리 구조로 구현하는 것이 좀 더 유리하다고 볼 수 있다. (stateless하게 만들 수 있다면, reactor패턴을 쓴다고 해도 스팟 포인트를 줄일 수 있긴 하다.)

'Software Engineering > Design Pattern' 카테고리의 다른 글

Reactor 패턴과 Proactor 패턴  (0) 2014.08.05
Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
Posted by 엘키 엘키

댓글을 달아 주세요



출처  : http://www.mcdonaldland.info/2007/11/28/40/

'Software Engineering > Design Pattern' 카테고리의 다른 글

Reactor 패턴과 Proactor 패턴  (0) 2014.08.05
Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
Posted by 엘키 엘키

댓글을 달아 주세요

프로그램을 작성하다보면, 객체간에 동적으로 결합이 필요한 경우가 많습니다. 객체간에 동적으로 결합/해제를 통해서 기능을 추가/제거 하는 것을 데코레이터 패턴이라고 합니다.


class LogDecorator
{
public:
	void Log(char *str, ...);
};

class Game
{
	LogDecorator *m_pLogDecorator;
public:
	void Start()
	{
		if(m_pLogDecorator)
			m_pLogDecorator->Log("Game::Start() ...");

		//게임시작처리
	}

	void End()
	{
		if(m_pLogDecorator)
			m_pLogDecorator->Log("Game::End() ...");

		//게임종료처리
	}

	void SetLog(LogDecorator *pLogDecorator)
	{
		m_pLogDecorator = pLogDecorator;
	}
};

Game클래스를 보면, LogDecorator 클래스가 결합되었을 때에만 로그를 기록하도록 되어있습니다. 


Game클래스는 LogDecorator 클래스를 통해서 기능이 추가/제거 되는데, 이처럼 동적으로 객체간의 결합을 통해 기능이 확장 되는 것을 데코레이터 패턴이라고 합니다.

'Software Engineering > Design Pattern' 카테고리의 다른 글

Reactor 패턴과 Proactor 패턴  (0) 2014.08.05
Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://blog.naver.com/jun0683 BlogIcon 우주미아홍구 2008.10.03 16:53  댓글주소  수정/삭제  댓글쓰기

    감사히 퍼가겠습니다 -_-;;

    내용이 좋네욤 켈켈..

  2. Favicon of http://blog.naver.com/whitejopd BlogIcon 신사 2009.10.19 10:30  댓글주소  수정/삭제  댓글쓰기

    패턴 다 퍼갈께용.내용이 넘조아용^^

객체의 내부 동작 하나 하나보다, 어떤 동작을 한다는 것 자체가 중요할 때가 있습니다. 캐릭터에게 행동을 시킬 때, 어떤 행동을 하는지는 중요하지 않고, 행동을 한다는 그 자체만 중요할 때가 바로 그렇습니다.

이렇게 행동을 일반화하는 것을 커맨드 패턴이라고 부르고, 캡슐화의 구현이라고 보셔도 좋습니다.

다만 일반 캡슐화와는 조금 다른것이, 커맨드 패턴은 한 클래스당 한가지 일만 시키는 경우가 많다는 것입니다. 동작 하나를 하나의 클래스로 관리함으로써, 다양한 동작을 관리하기 쉽게 하겠다는 것이지요.

class ICommand
{
public:
	virtual void Act() = 0;
};

class CharacterParent : public ICommand
{
protected:
	virtual CharacterParent * SearchTarget() = 0; //타겟찾기
	virtual void Act(CharacterParent *pCharaterParent) = 0; //공격
public:
	virtual void Act(){
		Act(SearchTarget());
	}
};

class Monster : public CharacterParent
{
	virtual CharacterParent * SearchTarget()
	{
		//사정거리내의캐릭터를찾는다.
	}

	virtual void Act(CharacterParent *pCharaterParent)
	{
		Attack(pCharaterParent);
	}

	void Attack(CharacterParent *pCharaterParent)
	{
		//파라미터로넘어온캐릭터를공격한다.
	}
};

class Pet : public CharacterParent
{
	virtual CharacterParent * SearchTarget()
	{
		//가장약한아군캐릭터를찾는다
	}

	virtual void Act(CharacterParent *pCharaterParent)
	{
		Heal(pCharaterParent);
	}

	void Heal(CharacterParent *pCharaterParent)
	{
		//파라미터로넘어온캐릭터를회복시킨다
	}
};

void Act(ICommand *pCommand)
{
	pCommand->Act();
}

외부에서는 캐릭터가 공격을 하던, 회복을 시켜주던 상관없습니다. 해당 캐릭터가 행동한다는 그 자체가 중요하죠.

이렇듯 객체의 내부 행동을 숨기고, 외부 인터페이스를 일반화하는 것을 커맨드 패턴이라 합니다.

'Software Engineering > Design Pattern' 카테고리의 다른 글

Design Pattern Quick Reference  (0) 2011.02.10
데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
스트래티지 패턴 (Strategy)  (2) 2008.02.05
Posted by 엘키 엘키

댓글을 달아 주세요

동일한 종류의 객체 끼리는 중복된 정보를 가지게 될 가능성이 높습니다. 그래서 같은 종류의 객체끼리 중복되는 정보를 공유하는 것이 메모리 관리 측면이나, 중복을 제거하는 측면이나 이롭습니다.

중복되는 정보를 공유 하는 방법을 플라이 웨이트 패턴이라고 합니다.

class ImageData { int m_nIdx; int m_nWidth, m_nHeight; char *m_pData; public: char *GetData(){return m_pData;} int GetWidth(){return m_nWidth;} int GetHeight(){return m_nHeight;} }; class ImagePool // ImageData의 객체 소유권은 ImagePool에 있다. { public: ImageData *GetImageData(int nIdx); };




팝업 메뉴마다 공유 될 수 있는 이미지 데이터를 메뉴 객체마다 따로 들고 있는 것은 메모리상의 중복이 생깁니다. 같은 이미지 데이터를 사용하는 메뉴 객체가 CImageData의 정보를 링크해 사용 한다면 CImageData의 관리도 한 곳에서 이뤄지는 잇점과, 위에서 말한 메모리 상의 중복도 제거할 수 있게 되는 것입니다.


class QuestInfo { int m_nQuestNo; //퀘스트식별번호 char m_szTItle[32]; //퀘스트이름 char m_szDesc[512]; //퀘스트설명 int m_nQuestMissionNo; //퀘스트목표에할당된번호 int m_nCompensateNo; //퀘스트보상번호 int m_nRequireProgressQuantity; //목표 달성을 위해 필요한 진행량 //기타등등.. }; class QuestInfoPool //QuestInfo의객체소유권은 QuestInfoPool에게있다 { public: QuestInfo *GetQuestInfo(int nQuestNo); }; class QuestData { int m_nIdx; //퀘스트고유번호 int m_nProgressQuantity; //진행량 QuestInfo *m_pQuestInfo; public: QuestData(); ~QuestData(){} //여기서m_pQuestInfo를delete 하면큰일난다. void SetQuestInfo(QuestInfo *pQuestInfo) { m_pQuestInfo = pQuestInfo; } };


퀘스트의 경우에도 퀘스트의 종류에 따라 퀘스트 이름, 설명, 보상번호, 목표 번호, 목표 달성량 같은 것은 고정된 정보이고, 퀘스트의 고유 번호, 진행량과 같은 정보는 현재 진행중인 퀘스트마다 다르다.

이렇게 고정된 정보와 변할 수 있는 정보를 나누고, 고정된 정보를 묶고 링크해서 사용함으로써 플라이 웨이트 패턴을 구현할 수 있습니다.


'Software Engineering > Design Pattern' 카테고리의 다른 글

데코레이터 패턴 (Decorator)  (2) 2008.02.09
커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
스트래티지 패턴 (Strategy)  (2) 2008.02.05
스테이트 패턴 (State)  (2) 2008.02.05
Posted by 엘키 엘키

댓글을 달아 주세요

어떤 객체가 수행하는 기능을 그대로 수행하면서, 부가적인 기능을 수행하거나 기존 역할을 대행하기 위해 새 클래스를 정의하고, 새로 정의된 클래스를 통해서 외부와 통신하는 것을 프록시 패턴이라고 합니다.


class IObject { public: virtual void Use() = 0; }; class QuickSlot { IObject *m_piObejct; public: bool isExist() { return m_pObejct != NULL ? true : false; } void Use() { if(m_pObejct) m_pObejct->Use(); } }; class QuickSlotProxy { QuickSlot *m_pQuickSlot; public: QuickSlotProxy() : m_pQuickSlot(NULL) { } ~QuickSlotProxy() { if(m_pQuickSlot) delete m_pQuickSlot; } bool isExist() { if(m_pQuickSlot) return m_pQuickSlot->isExist(); return false; } bool Use() { if(m_pQuickSlot) { m_pQuickSlot->Use(); return true; } //bool형으로바뀌면서실제사용했는지여부를알수있게되었다. return false; } };

void형에서 bool형으로 바뀐 use함수에서는 아이템 사용을 성공 여부를 알릴 수 있도록 기능이 확장되었으며, QuickSlot 클래스에 변화를 가하지 않고도 기능 확장이 가능해졌습니다. 예를 들어, QuickSlot의 Use함수 호출 횟수 계산 기능을 추가한다 했을 때에도 QuickSlot 클래스를 변경할 필요 없게 되는 잇점이 생기게 되는 것이죠.

'Software Engineering > Design Pattern' 카테고리의 다른 글

커맨드 패턴 (Command)  (0) 2008.02.09
플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
스트래티지 패턴 (Strategy)  (2) 2008.02.05
스테이트 패턴 (State)  (2) 2008.02.05
컴포지트 패턴 (Composite)  (0) 2008.02.05
Posted by 엘키 엘키

댓글을 달아 주세요

범용 적으로 사용 될 수 있는 알고리즘을 독립적인 클래스로 구성하고, 해당 클래스를 선택적으로 사용할 수 있게 하는 것을 스트래티지 패턴이라고 합니다.

스테이트 패턴과 비슷한 점이 많은 패턴이지만, 범용적으로 사용 될 수 있는 알고리즘을 독립시킨다는 점에서 차이가 있습니다.


class Sort { public: virtual void Sort(int * pScore) = 0; }; class BubbleSort : public Sort { public: virtual void Sort(int *pScore) { //버블정렬 } }; class QuickSort : public Sort { public: virtual void Sort(int *pScore) { //퀵정렬 } }; class Score { Sort* m_pSort; public: void SetSort(Sort *pSort){m_pSort = pSort;} void Sort() { if(m_pSort) { m_pSort->Sort(); } } };


'Software Engineering > Design Pattern' 카테고리의 다른 글

플라이웨이트 패턴 (Fly Weight)  (0) 2008.02.09
프록시 패턴 (Proxy)  (0) 2008.02.09
스트래티지 패턴 (Strategy)  (2) 2008.02.05
스테이트 패턴 (State)  (2) 2008.02.05
컴포지트 패턴 (Composite)  (0) 2008.02.05
이터레이터 패턴 (Iterator)  (0) 2008.02.05
Posted by 엘키 엘키

댓글을 달아 주세요

  1. 2008.02.05 16:29  댓글주소  수정/삭제  댓글쓰기

    CBubbleSort와 CQuickSort는 CSort로부터 상속받아야 하지 않을까요?

내부적인 상태에 따라 다른 동작을 해야 될 경우, 각 동작의 enum형을 정의하고, 그에 따른 동작을 정의하면 다음과 같은 코드 구조가 될 것이다.

enum NPC_STATE { NPCSTATE_WANDERING = 0, //배회하기 NPCSTATE_DETECTING, //적탐지루틴검사 NPCSTATE_RUSH, //돌격모드. 타겟에게돌격하는상태 NPCSTATE_FIGHT, //전투모드타겟을적으로 }; class Npc { NPC_STATE m_NpcState; public: void SetNpcState(NPC_STATE NpcState){m_NpcState = NpcState;} void Wandering(); void Detecting(); void Rush(); void Fight(); void Act() { switch(m_NpcState) { case NPCSTATE_WANDERING: Wandering(); break; case NPCSTATE_DETECTING: Detecting(); break; case NPCSTATE_RUSH: Rush(); break; case NPCSTATE_FIGHT: Fight(); break; } } };

스테이트 패턴은 상태에 따라 다른 함수 호출을 하는 것이 아니라, 각 상태별 동작을 상태 객체로 정의 해두고 상태가 변했을 때 객체를 교체한다. 그리고 설정된 상태 객체의 함수를 호출 함으로써 분기문을 제거한다.

class NpcState { public: virtual void Act() = 0; }; class NpcStateWandering : public NpcState { public: virtual void Act() { //배회동작 } }; class NpcStateDetecting : public NpcState { public: virtual void Act() { //탐지동작 } }; class NpcStateRush : public NpcState { public: virtual void Act() { //러쉬동작 } }; class NpcStateFight : public NpcState { public: virtual void Act() { //전투동작 } }; class Npc { NpcState* m_pNpcState; public: void SetNpcState(NpcState *pNpcState){m_pNpcState = pNpcState;}

void Act() { if(m_pNpcState) { m_pNpcState->Act(); } } };


'Software Engineering > Design Pattern' 카테고리의 다른 글

프록시 패턴 (Proxy)  (0) 2008.02.09
스트래티지 패턴 (Strategy)  (2) 2008.02.05
스테이트 패턴 (State)  (2) 2008.02.05
컴포지트 패턴 (Composite)  (0) 2008.02.05
이터레이터 패턴 (Iterator)  (0) 2008.02.05
옵저버 패턴 (Observer)  (0) 2008.02.04
Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://mupa.tistory.com BlogIcon mupa 2008.02.05 18:09  댓글주소  수정/삭제  댓글쓰기

    여기도 상속이 다빠졌네,,
    근데 자식들의 포인트를 넘겨주는데,, 그포인트들은 누가 관리하나여?
    그걸 어떻게 관리/사용 하냐에 따라 틀려질꺼 같은데여,,음,,,

    • Favicon of https://elky.tistory.com BlogIcon 엘키 엘키 2008.02.05 18:35 신고  댓글주소  수정/삭제

      네 수정했어요~ 자식 포인터 관리는 별개 문제죠 ㅎㅎ 객체 소유 주체를 얘기하고자 한게 아니고, switch, case 문 대신에 상태 객체를 둔다는게 중요한거니까요.

이전버튼 1 2 3 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today29
Total1,605,483

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함