国产精品久久久久永久免费观看,欧美三级日本三级少妇99,亚洲免费高清

Mediator模式

Jacc.Kim — Tue, 28 Jun 2011 02:26:00 GMT

Mediator模式
该模型主要解决两个或多个对象间的�怺�通信的问题。（个�h认�ؓ该模式的思想同Observer模式的思想�q�是有点�c�M��的。表面上看，他们所解决的问题类型根本不同，那�ؓ什么我会这么认��Z��Q�后面再说明�Q�。按理说�Q�各对象间的通信假如�Q�ObjA与ObjB要进行通信。方法有好多�U�。比如：可以在它们内部各存一份对方的引用。在一方变动时�Q�调用另一方进行同步即可。但��实如果�pȝ��大而复杂时�Q�这��显�C�的不那么清晰。因此，��希望中间会有个调停者。Mediator模式��因此而生。此�Ӟ��ObjA与ObjB内部只存��Z��份Mediator(MediatorObj)对象的引用。在对象变动�Ӟ��只需调用MediatorObj的相��x��口，通知其他对象需要同步更新即可。因此，对ObjA或ObjB或其他的��M��对象来说�Q�它们有可能�Ҏ��不知道还有其他的对象存在。（如：ObjA可能不知道ObjB的存在。）但通过MediatorObj对象�Q�却辑ֈ�了ObjA与ObjB的同步作用。（现在想下�Q�是不是与Observer模式有点�c�M��Q�因为，如果在Observer模式的实��C��Q�抽象出一个IObserverable来。那通过IObserverable对象�Q�可以通知所有View的更斎ͼ��?br />

class CClassA;
class CClassB;

class CMediator
{
public:
    CMediator(){}
    CMediator(CClassA* pObjA, CClassB* pObjB)
    {
        this->m_pObjA = pObjA;
        this->m_pObjB = pObjB;
    }
    void DoSyncFromAToB(void)
    {
        this->m_pObjB->xxx
    }
    void DoSyncFromBToA(void)
    {
        this->m_pObjA->xxx
    }
private:
    CClassA* m_pObjA;
    CClassB* m_pObjB;
};

class CClassA
{
public:
    CClassA(){}
    CClassA(CMediator* pMediator)
    {
        this->m_pMediator = pMediator;
    }
    void DoAction(void)
    {
        // do some work here

        // 通知其他对象�Q�需要同�?/span>
        this->m_pMediator->DoSyncFromAToB();
    }

private:
    CMediator* m_pMediator;
};

class CClassB
{
public:
    CClassB(){}
    CClassB(CMediator* pMediator)
    {
        this->m_pMediator = pMediator;
    }
    void DoAction(void)
    {
        // do some work here

        // 通知其他对象�Q�需要同�?/span>
        this->m_pMediator->DoSyncFromBToA();
    }

private:
    CMediator* m_pMediator;
};

Jacc.Kim 2011-06-28 10:26 发表评论

Memento模式

Jacc.Kim — Tue, 28 Jun 2011 02:02:00 GMT

Memento模式
该模式的出现�Q�主要是��Z��让用��h��?#8220;撤销”的操作。好�l�用��h��个恢复先前状态的权力。其主要思想��是��对象（假设其类型�ؓ�Q�ClassA�Q�的先前状态记录�v来（当然自己得管理好�Q�。在需要时�Q�用此恢复。根据此思�\�Q�当然实现方法就多种多样。下面参考设计模式资料中的c++代码。（觉得此代码设计还是挺有道理的。因为对Memento�c�L��_��除了ClassA的对象外�Q�其他类型的对象都不需要，且也不应该能讉K��到。因此，在具体实��C��Q�它用了友元的技术）�?

typedef std::string State;

class COperationsMemento
{
    //其实更强的，可以��该�c�设计成。可以维护一�l�状态的。这��P��可以支�?br />    //��L��恢复到先前的�W�N�U�状态。就好似photoshop的层的那��L��撤销�?br />    //��明思想�Q�此暂时只维护一个状态�?/span>
private:
    State GetState(void)
    {
        return this->_sta;
    }
    void SetState(const State& state)
    {
        this->_sta = state;
    }
    // some code here
private:
    State _sta;
};

class COperationSteps
{
public:
    friend class COperationsMemento;
    COperationSteps()
    {
        this->m_pMemento = NULL;
        this->_sta = "normal";
    }
    COperationSteps(COperationsMemento* pMemento)
    {
        this->m_pMemento = pMemento;
        this->_sta = "normal";
    }
    virtual ~COperationSteps()
    {
        if (m_pMemento != NULL)
        {
            delete m_pMemento;
            m_pMemento = NULL;
        }
    }
    //存储状�?卻I��保存状�?
    void SaveState(void)
    {
        if (m_pMemento == NULL)
        {
            m_pMemento = new COperationsMemento();
        }
        m_pMemento->SetState(this->_sta);
    }
    //恢复状�?/span>
    void RestoreState(COperationsMemento* pMemento = NULL)
    {
        if (pMemento != NULL)
        {
            this->_sta = pMemento->GetState();
        }
        else
        {
            this->_sta = m_pMemento->GetState();
        }
    }

private:
    COperationsMemento* m_pMemento;    //需要维护，因�ؓ该状态，是自��q��有的
    State _sta;
};

Jacc.Kim 2011-06-28 10:02 发表评论

Strategy模式

Jacc.Kim — Sun, 12 Jun 2011 04:13:00 GMT

Strategy模式�Q�即�Q�策略模式）。其所要所要解决的问题�Q�同Template模式是同一�c�问题。但具体的处理方式有所不同。Template则是使用�Q�封装��承与多态的方式实现�Q�主要是�Q��承与多态）。而策略模式，则主要��用��承连�?#8220;�l�合”的方式来实现逻辑接口的提供。因此，如果Template模式中的逻辑接口要是有许多的话，则逻辑抽象基类�Q�将变得十分庞大而复杂。同�Ӟ��不同实现�cȝ��接口��全部暴露无疑。而组合则重在��某一逻辑接口的实现通过多个对象的组合方式实��C��。下面看下策略模式的�l�构�Q?

1class Strategy
2{
3public:
4  //
5  virtual void Func1(void) = 0;
6  virtual void Func2(void) = 0;//�q�两个接口只是示�?br /> 7  // some other interfaces here
8};
9
10class Sub1 : Strategy
11{
12public:
13  void Func1(void)
14  {
15    // do something
16  }
17  void Func2(void)
18  {
19    // do something
20  }
21};
22
23class Sub2 : Strategy
24{
25public:
26  void Func1(void)
27  {
28    // do something
29  }
30  void Func2(void)
31  {
32    // do something
33  }
34};
35
36class Strategy;
37//�{�略�cȝ��?/span>
38class Context
39{
40public:
41  Context(const Strategy* pStrategyObj) : m_pStrategyObj(pStrategyObj) {}
42  //
43  // 逻辑接口DoAction
44  void DoAction(void)
45  {
46    if (NULL != m_pStragegyObj)
47    {
48      m_pStrategyObj->Func1();
49      m_pStrategyObj->Func2();
50      //
51    }
52  }
53};

注意�Q�设计模式中�Q�更提倡优先��用组合，而非�l�承。详�l�原因，也可以从以上模式比较得出�?br />

Jacc.Kim 2011-06-12 12:13 发表评论

Template模式

Jacc.Kim — Sun, 12 Jun 2011 03:51:00 GMT

Template模型�Q�其实很�Ҏ��理解�Q�相信大家��^时也�l�常在用。其主要思想��同处理�q�么一�c�问题：有A对象�Q�与B对象�Q�或更多�Q�，它们的处理不同，但他们的逻辑却是相同的。因此，我们在处理这�c�问题时�Q�很自然的就会想到。给它们的逻辑处理用一抽象�c�d��装�v来。用两个具体的（实现�Q�派生类�l�承之。这��是Template模型的原理�?br /> 下面是程序示例：

1class LogicalAbstractClass
2{
3public:
4     // some code here
5    // 逻辑接口1
6    virtual void Logical1() = 0;
7    // 逻辑接口2
8    virtual bool Logical2() = 0;
9     // some other logical interfaces
10};
11
12class SubClassA : public LogicalAbstractClass
13{
14public:
15    void Logical1(){  }
16    bool Logical2(){  return true/false; }
17};
18
19class SubClassB : public LogicalAbstractClass
20{
21public:
22    void Logical1(){  }
23    bool Logical2(){  return true/false; }
24};
25
26int main(int argc, char* argc[])
27{
28    LogicalAbstractClass* pA = NULL;
29    LogicalAbstractClass* pB = NULL;
30    pA = new SubClassA;
31    pB = new SubClassB;
32
33    delete pB;
34    delete pA;
35}

补充�Q�Delphi的code�C�Z��׃��l�了。一个道理。懂得思想�Q�所有语�a�通用�?img src ="http://www.shnenglu.com/Tongy0/aggbug/148524.html" width = "1" height = "1" />

Jacc.Kim 2011-06-12 11:51 发表评论

Adapter模式

Jacc.Kim — Sat, 21 May 2011 15:54:00 GMT

该模式也相对��单。其主要处理的是�q�类问题�Q�当�pȝ��或某些模块已�l�成形后�Q�突焉��要增加某些功能。而这些功能的增加
在现有的对象中，暂时没有办法处理。同�Ӟ��却发玎ͼ�该功能，其实另一模块的对象却可以处理的了。因此，��希望能够在不修改原
有操作及�pȝ��l�构的情况下�Q�就自然而然地将该功能实现出来。此�Ӟ��可以��用Adapter来处理之。（注：在此�Q�我们强调的是不
��M��改原有系�l�的�l�构的情况下�Q��?br /> ��׃��q�问题，Adapter模式有两�U�解��x��法。一�U�是通过对象适配来解冟뀂另一�U�是通过�c�适配来解冟뀂所谓的对象适配�Q�指
的是�Q�通过引入��h��我们需要功能接口的对象�Q�设�c�MؓX�Q�，在实现处理过�E�中�Q�我们��用的是X的功能接口，以此来达到我们的需求�?br />而类适配�Q�则指的是，产生一个新�c�，让该新类�Q��承自X�c�，则自�Ӟ��该新�c�d��会有了X的相��x��口。下面看下，�q�两�U�适配的代码�?/p>

对象适配
class X
{
public:
...
virtual func(...);
};

class ObjAdapterObject : public ...
{
public:
void func(...)
{
if (m_pXObj != NULL)
m_pXObj->func(...);
}
private:
X* m_pXObj;
};

�c�适配
class X的声明及定义同上�?/p>

class ClassAdapterObject: public X, public ...
{
public:
...
};

以下调用��׃��写了�Q�你懂得的�?/p>

Jacc.Kim 2011-05-21 23:54 发表评论

Facade模式

Jacc.Kim — Thu, 19 May 2011 16:39:00 GMT

Facade模式

�Q�Facade模式�Q�门面模式与Proxy模式其实�q�是有点�怼�的。也是主要实��C��U�功能的��装。Facade模式�Q�主要是��几个有相关性的功能操作�Q�封装到一��P��q��一的接口提供�?br />使用�Ӟ��通过该接口即可完成所有相关的功能。此有个好处�Q�就是提高解耦性与增加高聚性。实��C��Q�查处问题也相对方便�?br /> ��单，代码不就�l�了�?/p>

Jacc.Kim 2011-05-20 00:39 发表评论

设计模式学习�ȝ��之八

Jacc.Kim — Thu, 19 May 2011 16:38:00 GMT

十：Flyweight模式�Q�即�Q��n元模式）

说的直观点，Flyweight模式其实��是实现一个对象缓存池。取对象�Q�优先从该池中取出。而它们的区别在于�Q�从前者中取东西时�Q�如果不存在。则可以��C�生一个，�q�返回�?br />而从后者中取时�Q�存在就�q�回�Q�不存在�Q�就�q�回为空�?br /> �׃��面的解释�Q�不难想象，该模式的实现�Q?br />class Flyweight
{
public:
...
};

class SubFlyweightObjX : public Flyweight
{
...
};

class SubFlyweightObjY : public Flyweight
{
...
};

//Flyweight�cȝ��l�构
class FlyweightBuffFactory
{
public:
Flyweight* GetFlyweight(...condition...)
{
  for (vector::iterator iter = m_vBuffer.begin(); iter != m_vBuffer.end(); iter++)
  {
   if (iter.xxx = condition)
    return (Flyweight*)iter;//注：如果此句不行用这句：return (Flyweight*)(&(*iter));
  }
  Flyweight* pReturn = new xxx;
  m_vBuffer.push_back(pReturn);
  return pReturn;
}

private:
vector m_vBuffer;
};

Jacc.Kim 2011-05-20 00:38 发表评论

Proxy模式

Jacc.Kim — Thu, 19 May 2011 16:38:00 GMT

Proxy模式

代理模式�Ӟ��思想倒类��g��装的概��c��主要是��某功能操作通过另一对象�Q�来全权处理。对
被代理的对象�Q�它不管你是如何处理。它只要�l�果。比如：�Ҏ��据的提取。原本可能要�l�过N个对象共
同配合，最�l�取得数据。此�Ӟ��可以用一个代理对象，来全权处理之。又比如��_��我们上网�Q�打开�|�页�Q?br />可以通过windows的网�l�功能模块，去解析，�q�最�l�打开�|�页。同时也可以通过代理�Q�解析�ƈ最�l�打开�|?br />��c�?/p>

下面是参考代�?br />class Subject
{
public:
virtual void Request() = 0;
protected:
Subject(){}
};

class ImplSubject
{
public:
virtual void Request(){ //....}
};

class Proxy
{
public:
Proxy(){}
Proxy(Subject* sub){m_pSub = sub;}
private:
Subject* m_pSub;
void Request(){ m_pSub->Request();}
};

int main(int argc, char* argv[])
{
Subject* sub = new ImplSubject();
Proxy* p = new Proxy(sub);
p->Request();
return 0;
}

Jacc.Kim 2011-05-20 00:38 发表评论

设计模式学习�ȝ��之七

Jacc.Kim — Thu, 19 May 2011 16:35:00 GMT

九：Decorator模式�Q�即�Q�装饰模式）

(�?)假设有这��L��一个问题存在（其实现实开发中�Q�非常经帔R��刎ͼ��Q�基�c�BasicClassX有N个的�z��c�R��因为它们没有功能接口void UnknowFunction(void);
按正常的。我们的处理�Ҏ��Q�（1�Q?可以通过直接修改BasicClassX基类�Q�在此添加virtual void UnknowFunction(void);虚接口�ƈ实现�Q�然后所有derived
class中均可见。（2�Q?又或是在BasicClassX基类�Q�添加了�U�虚接口�Q�然后在具体某派生类中进行了实现。在实现使用中，用该derived class来处理�?br /> (�?)但这样做会有�q�样的问题存在：a) 会有可能让��承的深度�Q�变的很深。系�l�的�c�d��变的很多�Q�很复杂。b) �cȝ��l�构也将变的复杂化。（因�ؓ�?br />在是增加个接口，以后要是又有其他的接口功能需要添加了�Q�？�Q�） c) 无�Ş中，会加重基�cȝ��负担。因为必��d��保证扩展该接口，否则基类看不到该�?br />口�?br /> (�?)��Z��解决上面的问题。Decorator模式��可以帮助我们很��L��地解冟뀂我们实��C��个Decorator�c�R��该�c�，只要引用一个BasicClassX指针对象卛_��?br />然后在Decorator�c�M��Q�扩展功能接口，�q�样�Q�新扩展的功能就与BasicClassX的相关类�Q�无��M��关系。只是在BasicClassX相关�c�需要该扩展接口的地方，
使用Decorator�c�L��处理卛_��。就相当于BasicClassX的对象（或是它的derived class object�Q�委托Decorator来实现处理一栗��但又同时像是将BasicClassX
对象与Decorator对象�q�行�l�合在一起��用。从而达到新接口的扩展作用。Decorator模式��是�q�么回事�?br /> 下面��要提��g��Decorator�cȝ��设计
SubClassA : BasicClassX;
SubClassB : BasicClassX;
SubClassC : SubClassA;
...
SubClassN : ... : BasicClassX;

class Decorator : BasicClassX
{
public:
  Decorator(BasicClassX* pBObj){m_pBOjb = pBObj;}
  void DoOperate(void)
  {
   m_pBObj->DoOperator();
   // do new interface
   this->DoNewInterfaceFunction();
  }
  //new extened interface function
  void DoNewInterfaceFunction(void){//do something...}
  // new extened other interface function
  ...

  //write down other code in here you knowned.
  ...
private:
  BasicClassX* m_pBObj;
}
个�h认�ؓ�Q�Decorator模式�Q�你说它有用。它��实有用。说它没用。其实它也没用。�ؓ啥这栯��了？因�ؓ它完全可以通过�Q��承，或者直接修改原有的�c�M��p�L��
实现。但它的存在�Q�也��实会让�pȝ��的思�\清晰些。至��代码相对不会那么�ؕ�?/p>

Jacc.Kim 2011-05-20 00:35 发表评论

设计模式学习�ȝ��之六

Jacc.Kim — Tue, 17 May 2011 16:46:00 GMT

设计模式学习�ȝ��之六

八：Composite模式�Q�即�Q�复合模式）

复合模式旨在��递归处理�Q��{化�ؓ一�U�顺序处理。明昑֜��Q�递归处理�Q�相对较耗资源。也相对较�ؓ抽象些。而用一个Composite�c�d��象来转化处理
递归处理。将昑־�直观些。它与Decorator模式的区别是�Q�Composite模式�Q�旨在构造一个类。这个类�Q�将原本是递归�l�织的树状结构，转换为直观地转化�?br />��序�l�构。即�Q�它重要于�{化表现。而Decorator模式�Q�即�Q�修饰模式）�Q�其重要��化管理原本系�l�类体系�l�构。不至于��类�l�承体系��来��深。同�Ӟ��?br />至于让原本设计好的类�Q�越来越复杂化。同时又可以为原本类体系��d��新的功能�Q�即�Q�书上所�q�的新的职责�Q��?/p>

下面��要看下该模式的代码结构：

class ClassNode
{
public:
//写下构造函数等
...
public:
virtual void Operation(void);
virtual void Add(ClassNode* pNode);
virtual void Remove(ClassNode* pNode);
virtual ClassNode* GetNode(int iIndex);
}

//Composite�c?br />class Composite : public ClassNode
{
public:
typedef vector NODELISTVEC;
public:
void Operation(void)
{
for (NODELISTVEC::iterator iter = m_vNodeList.begin(); iter != m_vNodeList.end(); iter++)
iter->Operation();
}
void Add(ClassNode* pNode){//do something...}
void Remove(ClassNode* pNode){//do something...}
ClassNode* GetNode(int iIndex){//do something...}
private:
NODELISTVEC m_vNodeList;
}

//调用
int main(int argc, char* argv[])
{
Composite* MyCompositeForNodes = new ...;
ClassNode* xxx = new ...;//创徏节点。当然这里只是�ؓ了演�C�，所以只创徏一个节炏V��一��|��有可能有N个节炏V�?br /> MyCom,positeForNodes.Add(xxx );
...
MyCompositeForNodes.Operation();
}

//个�h认�ؓ�Q�该模式�Q�很怪啊。。因为通过�q�样转换后，原本的父子关�p�d��被破坏掉了�?br />//如果有大侠理解的��q��话，�Q�还请不吝补充下。。不盛感�Ȁ�?/p>

Jacc.Kim 2011-05-18 00:46 发表评论

设计模式学习�ȝ��之五

Jacc.Kim — Mon, 16 May 2011 17:16:00 GMT

设计模式学习�ȝ��之五

七：Decorator模式�Q�即�Q�装饰模式）

Jacc.Kim 2011-05-17 01:16 发表评论

设计模式学习�ȝ��之四

Jacc.Kim — Sun, 15 May 2011 16:42:00 GMT

设计模式学习�ȝ��之四

六：Bridge模式�Q�即�Q�桥接模式）

讲之前，先声明：�׃��本�h电脑不是很好�Q�没法装上vc环境�q�行。因此以下代码，仅是手工输入�Q�在环境中未必能�~�译通过�?br>但以下，仅仅只是介绍一�U�思想。仅供参考。同�Ӟ��如果说明有误之处�Q�欢�q�指正。另外，则于一�ơ性手工输入下面那么多东东�Q�确�?br>不容易，所以Delphi的具体实现。就不在此列出。如有兴��用Delphi实现的朋友，也可以找本�h交流�Q�本人盛感荣�q��?br>�Q�当然如果是C++的朋友也同样、甚��x��加欢�q�）

看了�q�么多次的桥接模式，�q�次�ȝ��明白了。要想理解桥接模式，个�h认�ؓ�Q�还是有必要同抽象及其实现进行一下比较�?br> 1) 抽象及实现。我�怿��Q�跟不同的�h说话�Q�都会有诀�H�在里头。同是coder�Q�相信，最默契的沟通，�q�是code吧。我们来看下抽象及其实现的代码�?br>//抽象基类声明
class AbstractClassX
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}

//AbstractClassX的具体实�?ClassXImplX1
class ClassXImplX1 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 1... }
}

//AbstractClassX的具体实�?ClassXImplX2
class ClassXImplX2 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 2... }
}

在实际应用中�Q�我们用的是抽象�c�R��而实际上实例化的�Q�却是某具体子类。这�U�实现被我们多数人所使用。而它实际上解决的只是�q�么一�c�问题，卻I��同一行�ؓ的不同表现。当
然大多数需求，用此��可以了�?br> 但现在假如说有这么一�U�情况：假如��_��上面的处理仅仅只适用于��^台A�Q�而用户却希望同时�Q�它也要能够在��^台B上也能够一��L��操作。那当如何？
很明昄��Q�此�U�需要，�q�不是行��Z��的需求，因�ؓ不论是在�q�_��A上还是��^台B上，都要执行相同的操作。而且表示也是一��L��。该需要的实现。实际上是需要我们重新封装个抽象层，
来专门处理��^台B上的该行为。而实际的实现�Q�却�q�是跟��^台A上的一栗��其实我们仔�l�一惟뀂其实��^台A了的抽象�Q�即�Q�AbstractClassX�Q�与�q�_��B上的抽象�Q�假如�ؓ�Q�AbstractClassY�Q�，
其实它们是类似的。因为需要处理的功能一栗��因此，我们��想�Q�如果将�q�种抽象与实现具体分��d��来。在抽象中，留个具体实现的抽象引用（此其实就是该模式所指的Bridge----卻I��?br>通过该桥�Q�将抽象与具体的实现�q�接��h��。因此，我想该模式的名称��是因此得来的吧�Q�。那栗��抽象可以不受限制的扩展�Q�实��C��同样可以不受限制的扩展。这��P��pȝ��的框架就不需�?br>更改�Q�其不妙哉？�Q�因此就有了如下的code

//******************************************************************
//* 抽象声明及抽象部分的实现
//******************************************************************
//抽象的抽象基�c�d��?br>class AbstractClass
{
private:
//xxx
protected:
AbstractImpl* m_pAIObj; //具体的抽象实现的抽象对象�Q�这话很ao口，但理解了�q�话�Q�也��q��解了该模式。可以大�a�不惭地说�Q�该模式的秘密就在这句话上）
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}

//�q�_��A上的抽象的具体实�?注意�Q�此实现子类�Q�是针对抽象�?
class AbstractClassA : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}

//�q�_��B上的抽象的具体实�?注意�Q�此实现子类�Q�是针对抽象�?
class AbstractClassB : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}

//******************************************************************
//* 实现的抽象声明及其实�?br>//******************************************************************
//实现部分的抽象基�c�d��?br>class AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}

//具体��法1的具体实�?br>class ImplX : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}

//具体��法1的具体实�?br>class ImplY : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}

//******************************************************************
//* 实际应用斚w��
//******************************************************************

int main(int argc, char* argv[])
{
AbstractImplClass* pImplObj = new ImplX();//或new ImplY();�{�等�?br> //下面注意下：因�ؓ上面的代码中�Q�本��Zؓ了简写，�q�没有明��写出抽象部分的具体构造函数�?br> //�怿��Q�是�E�序员，看完下面�q�行都懂得，上面的抽象部分的声明�Q�应该声明一个什么样�?br> //构造函数吧�?br> AbstractClass* pAbstractObj = new AbstractClassA(pImplObj);//或new AbstractClassB(pImplObj);�{�等�?/p>

//do other something...

//在此补充一点：有上面的设计�Q�系�l�的框架��都无需修改。不论是实现的具体算法改变了�Q�还�?br> //抽象的需求变动。程序都无需要修�Ҏ��架代码，�Q�仅仅只需要写个具体的实现�c�（不管是实现的实现�c�，�q�是
//抽象的实现类�Q�即可。这��是桥接模式�?br>}

Jacc.Kim 2011-05-16 00:42 发表评论

设计模式学习�ȝ��之三

Jacc.Kim — Sun, 15 May 2011 07:48:00 GMT

设计模式学习�ȝ��之三

五：Prototype模式�Q�即�Q�原型模式）

此模式其实很��单，主要��是通过“克隆”的技术，来��生出新的对象来。其与抽象工厂模式以及Builder模式的区别是�Q�抽象工厂模式式�Q�主要用来��生多个有�怺�依赖关系的对象的创徏�?br>而构建模式则主要用来处理一个复杂模块的一步步构徏工作。原型模式，则注重通过自��n�Q�来复制��Z��份与自��n一��L��实例对象来。原型本�w�也有点�c�M��一个抽象工厂�?br> 原型模式常用的接口一般有�Q�Clone(); Asign(); �q�有拯��构造函数。（对Delphi来说�Q�主要还是前两种�Ҏ��Q?/p>

前面一至五�Q�可被归�U��ؓ�Q�创建型模式

Jacc.Kim 2011-05-15 15:48 发表评论

设计模式学习�ȝ��之二

Jacc.Kim — Sun, 15 May 2011 07:31:00 GMT

设计模式学习�ȝ��之二

三：Singleton模式�Q�单实例模式�Q?/p>

��֐�思义�Q�即单例模式。其主要思想��是在项目中�Q�仅创徏一个实例对象。该对象的抽象，除了通过指定的获取实例接口外�Q�再没其他办法可以初始化�?br>此可以保证整个系�l�生命周期内�Q�仅会有一个实例存在。可以想象一下，它是可以与先前说的工厂模式或抽象工厂模式�l�合使用的。因��Z��般来��_��工厂可能只会
有一个（臛_��Ҏ��U�逻辑处理来说是这��L��Q��?br> 在C++中，实现单例模式�Q�相�Ҏ��较直观及合理。将该实例定义成static成员卛_��。�ƈ提供获取及释放该成员的接口。而在delphi中，�Q�就本来的了解来��_��
��g��q�没有直观的静态成员这一说法。但可以定义一个全局变量�Q��ƈ提供获取与释攑֏�量的接口来模拟。（但，毕竟没办法同�c�d��的实例被创徏出来�Q�所以最好要�?br>详细注释说明。告知其他组员，此�ؓ单实例）

参考的c++实现�Q?br> class CA
{
private:
  CA(){}
private:
  static CA* m_pAObj;
public:
  virtual ~CA(){}
  static CA* GetAObj(void)
  {
   if (m_pAObj == NULL)
    m_pAObj = new CA();
   return m_pAObj;
  }
  static void SafeReleaseAObj(void)
  {
   if (m_pAObj != NULL)
    delete m_pAObj;
   m_pAObj = NULL;
  }
};
static CA* CA::m_pAObj = NULL;

参考的Delphi实现�Q?br> unit xxx
interface
uses
   xxx,...,yyy;
type
   TMyClass = class
   //xxxx
   end;
var
   gAObj: TMyClass;//此�ؓ全局的单实例对象�?br> function GetAObj: TMyClass;
procedure SafeReleaseAObj;
implemention//�q�个单词忘了是不是这么写。反应是实现的那个单词。�?br> procedure SafeReleaseAObj;
begin
   if Assigned(gAObj) then
     FreeAndNil(gAObj);
end;
funciton GetAObj: TMyClass;
begin
   if not Assigned(gAObj) then
     gAObj = TMyClass.Create;
   Result := gAObj;
end;

//说明�Q�以上仅是��时写的，�q�未在程序中�~�译��试。但思�\肯定不会错。可供参考用�?br>
四：Builder模式�Q�即�Q�构建模式）

往往在实际项目的开发过�E�中会发玎ͼ�某些模块的功能过于复杂。此�Ӟ��我们自然��׃��惛_��其�q�行�q�一步的划分。如�Q�细分成DA,DB,...,DN。然后由该模块的某个��理角色�q�行协调�q�作�?br>�q�样�Q�Builder模式��可用在此设计上。其思想�Q�就是将复杂问题�q�一步细化�?/p>

Jacc.Kim 2011-05-15 15:31 发表评论

设计模式学习�ȝ��之一

Jacc.Kim — Sun, 15 May 2011 04:14:00 GMT

设计模式学习�ȝ��之一

设计模式其实只是一�U�程序设计的思想准则。通过该思想准则来指导我们的�E�序开发行为，��量让开发的�E�序更加�E�_��、高效、思�\清晰、少bug......
开发一�E�序��目�Q�往往�q�不只限于单一��C��用某一模式。往往会多�U�模式同时��用�?/p>

其实�Q�设计模式在具体��目中的应用开发中。要说要用xxx/xxx模式来搭框架开发等�{�，�q�些都是不对的。因��Z��为，设计模式的应用，是随着��目�?br>不同而定的。因��Z��同的��目有着不同的解��x��案。而不同的解决�Ҏ��Q�将军_��着�Q�需要��用哪xxx/哪xxx模式来处理会比较好，此时才能��_��定了项�?br>的框架等�{��?br> 比如��_��本来需要开发一个本地资源管理的��目。如果你一开始就�l�它定了一定要用单实例模式来搭框架实现。那我们��׃��明白了这个实例，在框架中�Q?br>到底它应该是什么。反�q�来�Q�正常的�Q�我们应该根据这个项目的需要来��定应该用到的模式。就拿该例子来说。我们可以对资源斚w��Q��用抽象工栈模�?br>在资源与展现及其处理斚w��Q�我们可以应用观察模式（卻I��所谓的observer模式�Q�。如此一来，我很明确了，该系�l�大�|�的框架。这正应了刚开始的一句话
�Q�设计模式只是一�U�程序设计的思想准则�Q�它只是用来指导�E�序开发的行�ؓ�?/p>

当然��x��得设计模式的东东�Q�确实还是离不开面向对象�Q�的思想�Q�。对oo思想更解的越深刻�Q�学赯��计模式的��相对越��L��Q�也更解的会更深��M��Q�当�Ӟ��
学习它将是个不断�q�代的过�E�的�Q�。反�q�来�Q�对设计模式理解的越深刻�Q�对oo的理解及应用与设计，也将大大有益�?/p>

一�Q�Factory模式�Q�工厂模式）

所谓的Factory模式�Q�即�Q�它能类似工厂一��P��不断��C�生（卻I��创徏�Q?#8220;产品”出来。但它所创徏出来的那�?#8220;产品”�Q�一般是抽象�cȝ��产品。�D例：
假如有抽象类AbstractBasicClass。我们要想��用它�Q�必��d��有它的实现类。按正常来说�Q�我们可以直接通过其具体的子类实例化一个��品出来。但�q�样�?br>有个问题�Q�当AbstractBasicClass拥有N�U�不同的实现子类�Ӟ��那我们到底要使用哪种具体子类来实例化�Q��ƈ且，各个不同的具体实现子�cȝ��命名�Q�也��是
个可怕的问题。因此这��L��l�护��变得十分复杂。而Factory的设计就可以��h��很好的一个维护作用。其实Factory模式的设计，�q�有一个好处，��是使得实例
化得��C��推迟�Q�到了后�?---一般指执行期）�?/p>

二：AbstractFactory模式�Q�抽象工厂模式）

上面Factory模式�Q�其实针对的是一�cȝ��的情况，卻I��处理的上上面的AbstractBasicClass�q�一�cȝ��的情��c��而实际项目中�Q�却往往需要处理N�U�的�q�样抽象�c�R�?br>的情��c��此�Ӟ��我们��这N�U�类的��品创建都归到一个Factory中时�Q�此时的Factory即�ؓ一个AbstractFactory了。因此说�Q�Factory与AbstractFactory只不�q?br>是处理的�c�d��cȝ��个数差异�|�了。其思想是类似的�?br> 但一般来说AbstractFactory所产生出来的种抽象�c�，其实它们之间�Q�一般来��_��或多或少�Q�会是有一定的关系的。比如：一个Abstractfactory产生��Z��?br>抽象�cȝ��产品A和B。则A可能��需要B的某些功能，反之�c�M��?/p>

��结�Q�Factory与AbstractFactory的设计，最�l�的目的都只是�ؓ了��用系�l�抽象类的维护更加简单些�?/p>

Jacc.Kim 2011-05-15 12:14 发表评论