'Design Pattern' 태그의 글 목록

http://blog.naver.com/lithium81?Redirect=Log&logNo=80123523651

영어 정리 잘 되어있는 사이트: http://vincehuston.org/dp

doc 문서: http://trozan.tistory.com/entry/%EB%AC%B8%EC%84%9C-GoF%EC%9D%98-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%EC%A0%95%EB%A6%AC

저작자표시

'SE > RF_DP' 카테고리의 다른 글

Decorator Pattern (0)	2010.07.15

안녕하세요. moltak입니다.

오늘은 디자인 패턴 중 데코레이터 패턴입니다.

의도:

데코레이터 패턴은 어떤 클래스를 꾸미는 역할을 합니다.

예전에 우리가 만들었던 코드를 "감싸"서 새로운 임무를 부여하는 것이 가능합니다.

"감싸"다는 말은 이 패턴에서 굉장히 중요합니다.

활용성:

제가 보는 책(head first design patterns)에서는 데코레이션 패턴을 커피 예를 들어서 설명을 했습니다.

커피집에 가면 커피가 굉장히 많은데 그 커피에 대한 클래스를 만들고 모든 재료, 기능들을 넣는 것 보단 커피 클래스 따로 재료 클래스 따로 만들고 있었습니다.

커피 클래스, 재료 클래스를 따로 만들게 되었을 때 서로 유기적으로 잘 묶기만 한다면 한 클래스에 모든 기능을 넣는 것 보단 당연히 구조적으로 좋겠죠?

데코레이션 패턴에서는 유기적으로 묶는 방법으로 "감싸"는 것을 선택했습니다.

위 클래스 다이어그램을 보시면 가장 상위에 Coffee 추상 클래스가 보입니다.

그 아래로 그것을 상속받는 Americano, Espresso, Cafelatte같은 클래스가 있습니다.

또, Decorator라는 추상클래스가 있는데 이 클래스는 getDescription이라는 순수가상함수를 갖고 있습니다.

그래서 아래 재료들이 무조건 이 함수를 새로 정의하게 만들었습니다.

이 패턴의 시나리오는 위 소스에서 보는 것과 같이 원하는 커피 인스턴스를 생성하고 원하는 재료를 만들어서 서로에게 계속 참조를 시킨다는 것입니다. (감싼다는 의미가 이것입니다.)

사용자가 getDescription함수를 호출하거나 cost 함수를 호출하면 제어가 계속 참조하는 곳으로 올라가게 됩니다.

(아래 소스 참조)

이런 식으로 사용자는 예전부터 있던 클래스를 하나도 수정하지 않고 단지 "감싸"서 예전 클래스에 새로운 기능을 부여하는 것이 가능합니다.

#include <iostream>
using namespace std;

class Coffee
{
protected:
	string description;

public:
	virtual ~Coffee(){};

virtual string getDescription()
	{
		return description;
	}

virtual int cost() = 0;
};

class Americano : public Coffee
{
public:
	Americano()
	{
		description = "Americano";
	}

int cost()
	{
		return 2000;
	}
};

class Espresso : public Coffee
{
public:
	Espresso()
	{
		description = "Espresso";
	}

int cost()
	{
		return 2500;
	}
};

class Cafelatte : public Coffee
{
public:
	Cafelatte()
	{
		description = "Cafelatte";
	}

int cost()
	{
		return 2600;
	}
};

class Decorator : public Coffee
{
public:
	virtual string getDescription() = 0;
};

class Milk : public Decorator
{
	Coffee* coffee;

public:
	Milk( Coffee* coffee )
	{
		this->coffee = coffee;
	}

string getDescription()
	{
		string name = coffee->getDescription();
		name += ", Milk";

return name;
	}

int cost()
	{
		return 500 + coffee->cost();
	}
};

class Mocha : public Decorator
{
	Coffee* coffee;

public:
	Mocha( Coffee* coffee )
	{
		this->coffee = coffee;
	}

string getDescription()
	{
		string name = coffee->getDescription();
		name += ", Mocha";

return name;
	}

int cost()
	{
		return 600 + coffee->cost();
	}
};

class Whip : public Decorator
{
	Coffee* coffee;

public:
	Whip( Coffee* coffee )
	{
		this->coffee = coffee;
	}

string getDescription()
	{
		string name = coffee->getDescription();
		name += ", Whip";

return name;
	}

int cost()
	{
		return 800 + coffee->cost();
	}
};

void main()
{
	Coffee* coffee = new Americano();
	
	coffee = new Milk( coffee );
	coffee = new Mocha( coffee );
	coffee = new Whip( coffee );

cout << coffee->getDescription().c_str() << "  " << coffee->cost() << endl;
	delete coffee;
}

Bloger : moltak.net

'SE > RF_DP' 카테고리의 다른 글

Design Pattern 도움 사이트 (0)	2011.03.15

옵져버 패턴입니다.

의도:

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

활용성:

추상화 개념이 두 가지의 측면을 갖고 하나가 다른 하나에 종속적일 때. 이런 종속 관계를 하나의 객체로 분리시켜 이들 각각을 재사용할 수 있다.

한 객체에 가해진 변경으로 다른 객체를 변경해야 할 때 프로그래머들은 얼마나 많은 객체들이 변경되어야 하는지를 몰라도 된다.

객체는 다른 객체에 변화를 통보할 수 있는데, 변화에 관심 있어 하는 객체들이 누구인지에 대한 가정 없이도 이루어져야 할 때.

보통 GUI 툴킷을 이용해서 프로그램을 작성하면 사용자에게 보여주는 UI와 데이터는 따로 나눠서 관리하게 됩니다. 그런 상황에서 하나의 데이터와 여러 개의 UI가 있을 경우 데이터를 공유시켜야 합니다. 그런 상황에서 옵져버 패턴을 사용하게 되면 굉장히 편합니다. Subject의 상태가 변화됨에 따라 Observer들의 상태가 자동으로 바뀌기 때문입니다.

#include <set>
#include <iostream>

using namespace std;

//////////////////////////////////////////////////////////////////////////
// ObserverInterface
class KOberverInterface
{
public:
	virtual void Update() = 0;
};

//////////////////////////////////////////////////////////////////////////
// Observer Class
class KOberver : public KOberverInterface
{
	char m_ObserverName;

public:
	KOberver( char Name ) : m_ObserverName( Name ) {}

virtual void Update()
	{ // 통지메시지 수신
		cout << m_ObserverName << " 통지 받음" << endl;
	}
};

//////////////////////////////////////////////////////////////////////////
// Subject
class Subject
{	
public:
	virtual void AttachObservers( KOberverInterface* pObserver ) = 0;
	virtual void DetachObservers( KOberverInterface* pObserver ) = 0;
	virtual void notifyObservers() = 0;
};

//////////////////////////////////////////////////////////////////////////
// Observermanager Class
class KObserverManager : public Subject
{
	set< KOberverInterface * > m_Observers;
	int state;

public:
	KObserverManager( int nState ) : state( nState ) {}

void AttachObservers( KOberverInterface* pObserver )
	{ // 옵져버 삽입
		m_Observers.insert( pObserver );
	}

void DetachObservers( KOberverInterface* pObserver )
	{ // 옵져버 해제
		m_Observers.erase( pObserver );
	}

void notifyObservers()
	{ // 옵져버들에게 메시지 발송
		for( set< KOberverInterface * >::const_iterator i = m_Observers.begin(); i != m_Observers.end(); i ++ )
		{
			( *i )->Update();
		}
	}

void SetState( int state )
	{
		if( this->state != state )
		{
			this->state = state;
			notifyObservers();
		}
	}

int GetState()
	{
		return state;
	}
};

void main()
{
	KObserverManager manger( 1 );
	KOberver a( 'a' );
	KOberver b( 'b' );
	KOberver c( 'c' );

manger.AttachObservers( &a );
	manger.AttachObservers( &b );
	manger.AttachObservers( &c );
	manger.SetState( 2 );

cout << endl << "b 제거" << endl;
	manger.DetachObservers( &b );
	manger.SetState( 3 );
}

Subject를 상속받는 ObserverManager의 상태가 변경되면 그 변경사항들이 옵져버들에게 반영됩니다.

Bloger: moltak.net

'SE > agile' 카테고리의 다른 글

UML: 클래스 다이어그램 기초 (0)	2010.07.08
① 사용자 요구조건 조사 (0)	2010.03.18
02] XP 개발 주기의 개괄 (0)	2010.03.18
01] XP 정의, 4개 구성 (0)	2010.03.18

디자인 패턴에 대해 잘 알지는 못하지만... 예전에 열심히 공부해보려 했던 때가 있습니다.

디자인 패턴을 공부하시다 보면 아시겠지만 우리가 봉착한 문제를 유연하고 멋있게 해결합니다.

그 중에 제가 가장 잘 사용하는 것이 이 Singleton Pattern 입니다.

싱글톤 패턴의 정의는 아래와 같습니다.

소프트웨어 엔지니어링 영역에서의 singleton은 객체지향 프로그래밍 시 클래스가 단 하나의 사건, 즉 단 하나의 인스턴스만을 갖도록 하는 패턴이다. 이 패턴은 주로 중요한 자원을 관리하고자 할 때, 다수의 인스턴스가 생성되지 않도록 제한하기 위해서 사용한다. 예를들어, 한번에 하나의 인스턴스만이 DB에 연결되도록 설정할때 사용할 수 있다.

여러개의 인스턴스가 생성되면 안되는 것들을 하나만 생성되게 막는 것입니다.

일단 어떻게 사용하시는지 보시죠.

저는 어제 올렸던 KSocket을 계속 발전 시켜 나갈 것입니다.

일단 헤더파일을 보시죠.

아래와 같이 instance를 하나 선언하고 가장 중요한 것은 생성자, 파괴자를 private로 선언하는 것입니다.

아무데서나 마음대로 사용할 수 없도록.

생성자 파괴자는 이제 static 함수에 의해서만 호출 될 수 있겠죠??

그리고 아래와 같이 인스턴스를 초기화 시켜주고 인스턴스 생성자, 인스턴스 파괴자 함수를 만들어 줍니다.

간단하고 명쾌하네요.

하지만 클래스를 만들 때마다 위 처럼 안에 함수를 생성해야 한다는 것이 너무 귀찮고 안좋아 보입니다.

그래서 아래 처럼 템플릿으로 만들었습니다.

[참조: http://www.iamcorean.net/140]

위 블로그를 가시면 알겠지만 굉장히 간결하게 짜 놓은 것을 볼 수 있네요.

조금만 보시면 쉽게 아실 겁니다.

사용은 m_KClientSocket = KSingleton< KSocketClient >::getInstance(); 이렇게 하시면 됩니다.

하지만 위 코드는 문제점이 있죠. 생성자, 파괴자는 인스턴스 생성 함수에 의해서만 호출 한다는 것이 깨져 버렸습니다.

이것은 다음에 해결하도록 하겠습니다.

그럼 모두들 즐프 하세요 ^^/

저작자표시

'Programming > 이것저것' 카테고리의 다른 글

IL Code에 심볼 정보가 포함되는 이유 (0)	2010.04.24
초기화 하지 않은 메모리 (0)	2010.04.16
typeid 연산자 (1)	2010.04.15
enum 문자열 (0)	2010.04.09
ASCII Table (0)	2010.04.05

code toolbox

Design Pattern

Design Pattern 도움 사이트

'SE > RF_DP' 카테고리의 다른 글

Decorator Pattern

'SE > RF_DP' 카테고리의 다른 글

Observer Pattern

'SE > agile' 카테고리의 다른 글

[Design Pattern] Singleton Pattern

'Programming > 이것저것' 카테고리의 다른 글

+ Recent posts

티스토리툴바