{
 3public:
 4  //
 5  virtual void Func1(void) = 0;
 6  virtual void Func2(void) = 0;//这两个接口只是示例
 7  // some other interfaces here
 8}

{
12public:
13  void Func1(void)
14  {
15    // do something
16  }
17  void Func2(void)
18  {
19    // do something
20  }
21}

{
25public:
26  void Func1(void)
27  {
28    // do something
29  }
30  void Func2(void)
31  {
32    // do something
33  }
34}

{
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}

    注意：设计模式中，更提倡优先使用组合，而非继承。详细原因，也可以从以上模式比较得出。

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

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

类适配
class X的声明及定义同上。

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

以下调用就不写了，你懂得的。

 （Facade模式）门面模式与Proxy模式其实还是有点相似的。也是主要实现一种功能的封装。Facade模式，主要是将几个有相关性的功能操作，封装到一起，由统一的接口提供。
使用时，通过该接口即可完成所有相关的功能。此有个好处，就是提高解耦性与增加高聚性。实现中，查处问题也相对方便。
 简单，代码不就给了。

十：Flyweight模式（即：享元模式）

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

class SubFlyweightObjX : public Flyweight
{
...
};

class SubFlyweightObjY : public Flyweight
{
...
};

//Flyweight类的结构
class FlyweightBuffFactory
{
public:
 Flyweight* GetFlyweight(...condition...)
 {
  for (vector<Flyweight* >::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<Flyweight* > m_vBuffer;
};

 代理模式其，思想倒类似于封装的概念。主要是将某功能操作通过另一对象，来全权处理。对
被代理的对象，它不管你是如何处理。它只要结果。比如：对数据的提取。原本可能要经过N个对象共
同配合，最终取得数据。此时，可以用一个代理对象，来全权处理之。又比如说：我们上网，打开网页，
可以通过windows的网络功能模块，去解析，并最终打开网页。同时也可以通过代理，解析并最终打开网
页。

 下面是参考代码
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;
}

 (注2)假设有这样的一个问题存在（其实现实开发中，非常经常遇到）：基类BasicClassX有N个的派生类。因为它们没有功能接口void UnknowFunction(void);
按正常的。我们的处理方法，（1） 可以通过直接修改BasicClassX基类，在此添加virtual void UnknowFunction(void);虚接口并实现，然后所有derived
class中均可见。（2） 又或是在BasicClassX基类，添加了纯虚接口，然后在具体某派生类中进行了实现。在实现使用中，用该derived class来处理。
 (注3)但这样做会有这样的问题存在：a) 会有可能让继承的深度，变的很深。系统的类将变的很多，很复杂。b) 类的结构也将变的复杂化。（因为现
在是增加个接口，以后要是又有其他的接口功能需要添加了？？？） c) 无形中，会加重基类的负担。因为必须得保证扩展该接口，否则基类看不到该接
口。
 (注1)为了解决上面的问题。Decorator模式就可以帮助我们很轻松地解决。我们实现一个Decorator类。该类，只要引用一个BasicClassX指针对象即可。
然后在Decorator类中，扩展功能接口，这样，新扩展的功能就与BasicClassX的相关类，无任何关系。只是在BasicClassX相关类需要该扩展接口的地方，
使用Decorator类来处理即可。就相当于BasicClassX的对象（或是它的derived class object）委托Decorator来实现处理一样。但又同时像是将BasicClassX
对象与Decorator对象进行组合在一起使用。从而达到新接口的扩展作用。Decorator模式就是这么回事。
 下面简要提炼下Decorator类的设计
 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;
 }
 个人认为，Decorator模式，你说它有用。它确实有用。说它没用。其实它也没用。为啥这样说了？因为它完全可以通过，继承，或者直接修改原有的类体系来
实现。但它的存在，也确实会让系统的思路清晰些。至少代码相对不会那么乱。

八：Composite模式（即：复合模式）

 复合模式旨在将递归处理，转化为一种顺序处理。明显地，递归处理，相对较耗资源。也相对较为抽象些。而用一个Composite类对象来转化处理
递归处理。将显得直观些。它与Decorator模式的区别是：Composite模式，旨在构造一个类。这个类，将原本是递归组织的树状结构，转换为直观地转化为
顺序结构。即：它重要于转化表现。而Decorator模式（即：修饰模式），其重要简化管理原本系统类体系结构。不至于将类继承体系越来越深。同时，不
至于让原本设计好的类，越来越复杂化。同时又可以为原本类体系添加新的功能（即：书上所述的新的职责）。

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

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

//Composite类
class Composite : public ClassNode
{
public:
 typedef vector<ClassNode* > 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 ...;//创建节点。当然这里只是为了演示，所以只创建一个节点。一棵树有可能有N个节点。
 MyCom,positeForNodes.Add(xxx );
 ...
 MyCompositeForNodes.Operation();
}

//个人认为，该模式，很怪啊。。因为通过这样转换后，原本的父子关系就被破坏掉了。
//如果有大侠理解的深的话，，还请不吝补充下。。不盛感激。

七：Decorator模式（即：装饰模式）

 (注2)假设有这样的一个问题存在（其实现实开发中，非常经常遇到）：基类BasicClassX有N个的派生类。因为它们没有功能接口void UnknowFunction(void);
按正常的。我们的处理方法，（1） 可以通过直接修改BasicClassX基类，在此添加virtual void UnknowFunction(void);虚接口并实现，然后所有derived
class中均可见。（2） 又或是在BasicClassX基类，添加了纯虚接口，然后在具体某派生类中进行了实现。在实现使用中，用该derived class来处理。
 (注3)但这样做会有这样的问题存在：a) 会有可能让继承的深度，变的很深。系统的类将变的很多，很复杂。b) 类的结构也将变的复杂化。（因为现
在是增加个接口，以后要是又有其他的接口功能需要添加了？？？） c) 无形中，会加重基类的负担。因为必须得保证扩展该接口，否则基类看不到该接
口。
 (注1)为了解决上面的问题。Decorator模式就可以帮助我们很轻松地解决。我们实现一个Decorator类。该类，只要引用一个BasicClassX指针对象即可。
然后在Decorator类中，扩展功能接口，这样，新扩展的功能就与BasicClassX的相关类，无任何关系。只是在BasicClassX相关类需要该扩展接口的地方，
使用Decorator类来处理即可。就相当于BasicClassX的对象（或是它的derived class object）委托Decorator来实现处理一样。但又同时像是将BasicClassX
对象与Decorator对象进行组合在一起使用。从而达到新接口的扩展作用。Decorator模式就是这么回事。
 下面简要提炼下Decorator类的设计
 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;
 }
 个人认为，Decorator模式，你说它有用。它确实有用。说它没用。其实它也没用。为啥这样说了？因为它完全可以通过，继承，或者直接修改原有的类体系来
实现。但它的存在，也确实会让系统的思路清晰些。至少代码相对不会那么乱。

六：Bridge模式（即：桥接模式）

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

 看了这么多次的桥接模式，这次总算明白了。要想理解桥接模式，个人认为，还是有必要同抽象及其实现进行一下比较。
 1) 抽象及实现。我相信，跟不同的人说话，都会有诀窍在里头。同是coder，相信，最默契的沟通，还是code吧。我们来看下抽象及其实现的代码。
//抽象基类声明
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... }
}

 在实际应用中，我们用的是抽象类。而实际上实例化的，却是某具体子类。这种实现被我们多数人所使用。而它实际上解决的只是这么一类问题，即：同一行为的不同表现。当
然大多数需求，用此就可以了。
 但现在假如说有这么一种情况：假如说，上面的处理仅仅只适用于平台A，而用户却希望同时，它也要能够在平台B上也能够一样的操作。那当如何？
很明显的，此种需要，并不是行为上的需求，因为不论是在平台A上还是平台B上，都要执行相同的操作。而且表示也是一样的。该需要的实现。实际上是需要我们重新封装个抽象层，
来专门处理平台B上的该行为。而实际的实现，却还是跟平台A上的一样。其实我们仔细一想。其实平台A了的抽象（即：AbstractClassX）与平台B上的抽象（假如为：AbstractClassY），
其实它们是类似的。因为需要处理的功能一样。因此，我们就想，如果将这种抽象与实现具体分离开来。在抽象中，留个具体实现的抽象引用（此其实就是该模式所指的Bridge----即：桥
通过该桥，将抽象与具体的实现连接起来。因此，我想该模式的名称就是因此得来的吧）。那样。抽象可以不受限制的扩展，实现也同样可以不受限制的扩展。这样，系统的框架就不需要
更改，其不妙哉？！因此就有了如下的code

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

//平台A上的抽象的具体实现(注意：此实现子类，是针对抽象的)
class AbstractClassA : public AbstractClass
{
private:
 //xxx
protected:
 //xxx
public:
 //xxx
 void DoSomething(void) { m_pAIObj.DoSomething(); }
 //xxx
}

//平台B上的抽象的具体实现(注意：此实现子类，是针对抽象的)
class AbstractClassB : public AbstractClass
{
private:
 //xxx
protected:
 //xxx
public:
 //xxx
 void DoSomething(void) { m_pAIObj.DoSomething(); }
 //xxx
}

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

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

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

//******************************************************************
//* 实际应用方面
//******************************************************************

int main(int argc, char* argv[])
{
 AbstractImplClass* pImplObj = new ImplX();//或new ImplY();等等。
 //下面注意下：因为上面的代码中，本人为了简写，并没有明确写出抽象部分的具体构造函数。
 //相信，是程序员，看完下面这行都懂得，上面的抽象部分的声明，应该声明一个什么样的
 //构造函数吧。
 AbstractClass* pAbstractObj = new AbstractClassA(pImplObj);//或new AbstractClassB(pImplObj);等等。

 //do other something...

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

五：Prototype模式（即：原型模式）

 此模式其实很简单，主要就是通过“克隆”的技术，来产生出新的对象来。其与抽象工厂模式以及Builder模式的区别是：抽象工厂模式式，主要用来产生多个有相互依赖关系的对象的创建。
而构建模式则主要用来处理一个复杂模块的一步步构建工作。原型模式，则注重通过自身，来复制出一份与自身一样的实例对象来。原型本身也有点类似一个抽象工厂。
 原型模式常用的接口一般有：Clone(); Asign(); 还有拷贝构造函数。（对Delphi来说，主要还是前两种方法）

 前面一至五，可被归纳为：创建型模式

三：Singleton模式（单实例模式）

 顾名思义，即单例模式。其主要思想就是在项目中，仅创建一个实例对象。该对象的抽象，除了通过指定的获取实例接口外，再没其他办法可以初始化。
此可以保证整个系统生命周期内，仅会有一个实例存在。可以想象一下，它是可以与先前说的工厂模式或抽象工厂模式结合使用的。因为一般来说，工厂可能只会
有一个（至少对某种逻辑处理来说是这样的）。
 在C++中，实现单例模式，相对比较直观及合理。将该实例定义成static成员即可。并提供获取及释放该成员的接口。而在delphi中，（就本来的了解来说）
似乎并没有直观的静态成员这一说法。但可以定义一个全局变量，并提供获取与释放变量的接口来模拟。（但，毕竟没办法同类型的实例被创建出来，所以最好要加
详细注释说明。告知其他组员，此为单实例）

 参考的c++实现：
 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实现：
 unit xxx
 interface
 uses
   xxx,...,yyy;
 type
   TMyClass = class
   //xxxx
   end;
 var
   gAObj: TMyClass;//此为全局的单实例对象。
 function GetAObj: TMyClass;
 procedure SafeReleaseAObj;
 implemention//这个单词忘了是不是这么写。反应是实现的那个单词。。
 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;

 //说明：以上仅是临时写的，并未在程序中编译测试。但思路肯定不会错。可供参考用。
 
四：Builder模式（即：构建模式）

 往往在实际项目的开发过程中会发现，某些模块的功能过于复杂。此时，我们自然就会想到将其进行进一步的划分。如：细分成DA,DB,...,DN。然后由该模块的某个管理角色进行协调运作。
这样，Builder模式将可用在此设计上。其思想，就是将复杂问题进一步细化。

 设计模式其实只是一种程序设计的思想准则。通过该思想准则来指导我们的程序开发行为，尽量让开发的程序更加稳健、高效、思路清晰、少bug......
开发一程序项目，往往并不只限于单一地使用某一模式。往往会多种模式同时使用。

 其实，设计模式在具体项目中的应用开发中。要说要用xxx/xxx模式来搭框架开发等等，这些都是不对的。因为个人认为，设计模式的应用，是随着项目的
不同而定的。因为不同的项目有着不同的解决方案。而不同的解决方案，将决定着，需要使用哪xxx/哪xxx模式来处理会比较好，此时才能说，确定了项目
的框架等等。
 比如说：本来需要开发一个本地资源管理的项目。如果你一开始就给它定了一定要用单实例模式来搭框架实现。那我们就不明白了这个实例，在框架中，
到底它应该是什么。反过来，正常的，我们应该根据这个项目的需要来确定应该用到的模式。就拿该例子来说。我们可以对资源方面，使用抽象工栈模式
在资源与展现及其处理方面，我们可以应用观察模式（即：所谓的observer模式）。如此一来，我很明确了，该系统大置的框架。这正应了刚开始的一句话
：设计模式只是一种程序设计的思想准则，它只是用来指导程序开发的行为。

 当然想懂得设计模式的东东，确实还是离不开面向对象（的思想）。对oo思想更解的越深刻，学起设计模式的将相对越轻松，也更解的会更深刻些（当然，
学习它将是个不断迭代的过程的）。反过来，对设计模式理解的越深刻，对oo的理解及应用与设计，也将大大有益。

一：Factory模式（工厂模式）

 所谓的Factory模式，即：它能类似工厂一样，不断地产生（即：创建）“产品”出来。但它所创建出来的那些“产品”，一般是抽象类的产品。举例：
假如有抽象类AbstractBasicClass。我们要想使用它，必须得有它的实现类。按正常来说，我们可以直接通过其具体的子类实例化一个产品出来。但这样会
有个问题，当AbstractBasicClass拥有N种不同的实现子类时，那我们到底要使用哪种具体子类来实例化，并且，各个不同的具体实现子类的命名，也将是
个可怕的问题。因此这样的维护将变得十分复杂。而Factory的设计就可以起来很好的一个维护作用。其实Factory模式的设计，还有一个好处，就是使得实例
化得到了推迟（到了后期----一般指执行期）。

二：AbstractFactory模式（抽象工厂模式）

 上面Factory模式，其实针对的是一类类的情况，即：处理的上上面的AbstractBasicClass这一类类的情况。而实际项目中，却往往需要处理N种的这样抽象类、
的情况。此时，我们将这N种类的产品创建都归到一个Factory中时，此时的Factory即为一个AbstractFactory了。因此说，Factory与AbstractFactory只不过
是处理的类各类的个数差异罢了。其思想是类似的。
 但一般来说AbstractFactory所产生出来的种抽象类，其实它们之间，一般来说，或多或少，会是有一定的关系的。比如：一个Abstractfactory产生出两个
抽象类的产品A和B。则A可能就需要B的某些功能，反之类似。

 小结：Factory与AbstractFactory的设计，最终的目的都只是为了使用系统抽象类的维护更加简单些。