一、“对象创建”模式
该类型模式的定义为：
通过“对象创建”模式绕开直接new一个具体的类型，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类型），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。

其典型模式为：
Factory Method（工厂方法）
Abstract Factory（抽象工厂）
Prototype（原型模式）
Builder（构建器）

（1）工厂方法
<1>该方法的动机为：
在软件系统中，经常会面临着创建对象的工作，由于需求变化，需要创建的对象的具体类型也会经常的变化。
<2>该方法的定义为：
定义一个用于创建对象的接口，让子类决定实例化哪个类。Factory Method 使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。

在讲述该设计模式时，采用文件分割器的例子。
为了能够实现不同文件分割器的设计，就需要创建不同类型的对象，若使用new方法，则需要针对不同的文件分割器new不同的对象类型。

class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};
// 具体实现类
class BinarySplitter : public ISplitter{};
class TxtSplitter: public ISplitter{};
class PictureSplitter: public ISplitter{};
class VideoSplitter: public ISplitter{};

在new时就依赖了一个具体的实现类 ISplitter* splitter = new BinarySplitter()，这样就违反了依赖倒置原则。
为了能够避开new方法依赖于具体类这一个问题，使用工厂模式，形成一个新的工厂基类，并将其写成一个虚函数。每一种实现方法都有一个自己的工厂类，这个工厂类都继承于工厂基类。

//抽象类
class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};
//工厂基类
class SplitterFactory{
public:
    virtual ISplitter* CreateSplitter()=0;  // 虚函数
    virtual ~SplitterFactory(){}
};

//具体类
class BinarySplitter : public ISplitter{};
class TxtSplitter: public ISplitter{};
class PictureSplitter: public ISplitter{};
class VideoSplitter: public ISplitter{};

//具体工厂
class BinarySplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new BinarySplitter();
    }
};

class TxtSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new TxtSplitter();
    }
};

class PictureSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new PictureSplitter();
    }
};

class VideoSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new VideoSplitter();
    }
}

通过上述方法，在MainForm中没有依赖于具体类，而是依赖于抽象类。

class MainForm : public Form
{
    SplitterFactory*  factory;//工厂

public:
    MainForm(SplitterFactory*  factory){
        this->factory=factory;
    }
    
    void Button1_Click(){
       ISplitter * splitter=factory->CreateSplitter(); //多态new
       splitter->split();
    }
};

要点总结：
<1>Factory Method 模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。
<2>Factory Method模式通过面向对象的手法，将所要创建的对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
<3>Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。

（2）抽象工厂
<1>该方法的动机：
在软件系统中，经常会面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，往往存在着更多系列对象的创建工作。
<2>该方法的定义：
提供一个接口，让该接口负责创建一系列“性关系或相互依赖的对象”，无需指定他们的具体类。
以下代码是对数据库的操作：

class EmployeeDAO{
public:
    vector<EmployeeDO> GetEmployees(){
        SqlConnection* connection = new SqlConnection();
        connection->ConnectionString = "...";

        SqlCommand* command = new SqlCommand();
        command->CommandText="...";
        command->SetConnection(connection);

        SqlDataReader* reader = command->ExecuteReader();
        while (reader->Read()){
        }
    }
};

上述代码适用于SQL Server数据库，但是不能实现对Oracle、MySql等数据库的兼容。
为此可以设计一个数据库访问有关操作的基类，后续不同数据库的操作都继承与这个基类。同时为各个操作创建其相对应的工厂类。

//数据库访问有关的基类
class IDBConnection{
};
class IDBConnectionFactory{
// 工厂类
public:
    virtual IDBConnection* CreateDBConnection()=0;
};
class IDBCommand{
};
class IDBCommandFactory{
// 工厂类
public:
    virtual IDBCommand* CreateDBCommand()=0;
};
class IDataReader{
 };
class IDataReaderFactory{
// 工厂类
public:
    virtual IDataReader* CreateDataReader()=0;
};

//支持SQL Server
class SqlConnection: public IDBConnection{
};
class SqlConnectionFactory:public IDBConnectionFactory{
};

class SqlCommand: public IDBCommand{
};
class SqlCommandFactory:public IDBCommandFactory{
};

class SqlDataReader: public IDataReader{
};
class SqlDataReaderFactory:public IDataReaderFactory{
};

//支持Oracle
class OracleConnection: public IDBConnection{
};
class OracleCommand: public IDBCommand{
};
class OracleDataReader: public IDataReader{
};

class EmployeeDAO{
    IDBConnectionFactory* dbConnectionFactory;
    IDBCommandFactory* dbCommandFactory;
    IDataReaderFactory* dataReaderFactory;
    
public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection = dbConnectionFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command = dbCommandFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //关联性

        IDBDataReader* reader = command->ExecuteReader(); //关联性
        while (reader->Read()){
        }
    }
};

由于上述各个操作是彼此关联的，所以可以讲上述一系列操作类对象放在同一个工厂类中。
在一定程度上，工厂方法可以看做时抽象工厂的一种特例。

//数据库访问有关的基类
class IDBConnection{
};

class IDBCommand{
};

class IDataReader{
};

class IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
    virtual IDBCommand* CreateDBCommand()=0;
    virtual IDataReader* CreateDataReader()=0;
};

//支持SQL Server
class SqlConnection: public IDBConnection{
};
class SqlCommand: public IDBCommand{
};
class SqlDataReader: public IDataReader{
};

class SqlDBFactory:public IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
    virtual IDBCommand* CreateDBCommand()=0;
    virtual IDataReader* CreateDataReader()=0;
};

//支持Oracle
class OracleConnection: public IDBConnection{
 };

class OracleCommand: public IDBCommand{
};

class OracleDataReader: public IDataReader{
};

class EmployeeDAO{
    IDBFactory* dbFactory;
    
public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection = dbFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command = dbFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //关联性

        IDBDataReader* reader = command->ExecuteReader(); //关联性
        while (reader->Read()){
        }
    }
};

要点总结：
<1>如果没有对应“多系列对象构建”的需求变化，则没有必要使用Abstract Factory 模式，这时候使用简单的工厂完全可以。
<2>“系列对象”指的是在某一特定系列下的对象之间有相互依赖或作用关系。不同系列的对象之间不能相互依赖。
<3>Abstract Factory 模式主要在于应对“新系列”的需求变动，其缺点在于难以应对“新对象”的需求变动。

（3）原型模式
<1>该模式的动机：
在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有着比较稳定一直的接口。
<2>该模式的定义：
使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。
现在将工厂模式所举的例子中的ISplitter和SplitterFactor两个基类进行合并，同时添加一个克隆自己的方式来构建对象的虚方法（注意为深度拷贝，使用类的拷贝构造函数）。

//抽象类
class ISplitter{
public:
    virtual void split()=0;
    virtual ISplitter* clone()=0; //通过克隆自己来创建对象
    virtual ~ISplitter(){}

};

//具体类
class BinarySplitter : public ISplitter{
public:
    virtual ISplitter* clone(){
        return new BinarySplitter(*this);
    }
};

class TxtSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new TxtSplitter(*this);
    }
};

class PictureSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new PictureSplitter(*this);
    }
};

class VideoSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new VideoSplitter(*this);
    }
};

class MainForm : public Form
{
    ISplitter*  prototype;//原型对象

public:
    MainForm(ISplitter*  prototype){
        this->prototype=prototype;
    }
    void Button1_Click(){
        ISplitter * splitter=
            prototype->clone(); //克隆原型
        splitter->split();
    }
};

如此克隆的目的是什么？
对于某些结构较为复杂的对象，当利用工厂模式进行创建时会非常复杂。有时我们需要的是具备某些“属性”的对象，这也是工厂模式无法做到的，为此需要进行克隆。
要点总结：
<1>Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）直接的耦合关系，他同样要求这些“易变类”拥有“稳定的接口”。
<2>Prototype模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地“动态创建”拥有某些稳定接口的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方clone。
<3>Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝。（C++无需利用序列化进行深拷贝）

（4）构建器
<1>该模式的动机：
在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。
<2>该模式的定义：
将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）。
该类型方法与Template Method模板方法相似，但其主要是为了解决对象的创建问题。
在该类型方法的讲解中使用了房屋建造的例子，房屋的建造过程是相对固定的，但是具体的墙、门、窗可能都存在差异。
在代码中将固定的部分实现为虚函数的流程。具体的对象则继承House类，并重写虚函数。

class House{
    //....
};

class HouseBuilder {
public:
    House* GetResult(){
        return pHouse;
    }
    virtual ~HouseBuilder(){}
protected:
    House* pHouse;
    virtual void BuildPart1()=0;
    virtual void BuildPart2()=0;
    virtual void BuildPart3()=0;
    virtual void BuildPart4()=0;
    virtual void BuildPart5()=0;
};

class StoneHouse: public House{
};

class StoneHouseBuilder: public HouseBuilder{
protected:
    virtual void BuildPart1(){
        //pHouse->Part1 = ...;
    }
    virtual void BuildPart2(){
    }
    virtual void BuildPart3(){
    }
    virtual void BuildPart4(){
    }
    virtual void BuildPart5(){
        
    }
};

class HouseDirector{
public:
    HouseBuilder* pHouseBuilder;
    HouseDirector(HouseBuilder* pHouseBuilder){
        this->pHouseBuilder=pHouseBuilder;
    }
    
    House* Construct(){
        pHouseBuilder->BuildPart1();
        for (int i = 0; i < 4; i++){
            pHouseBuilder->BuildPart2();
        }
        bool flag=pHouseBuilder->BuildPart3();
        if(flag){
            pHouseBuilder->BuildPart4();
        }
        pHouseBuilder->BuildPart5();
        return pHouseBuilder->GetResult();
    }
};

二、接口隔离模式
在组建构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接接口（稳定的），来隔离本来相互紧密关联的接口是一种常见的解决方案。
其典型模式为：
Facade（门面模式）
Proxy（代理模式
Adapter（适配器）
Mediator（中介者）
（1）门面模式

对于客户系统和子系统之前存在很多的耦合的情况，如果不考虑设计的情况，那么会形成A方案的情况，系统的依赖严重，维护性大大降低。
如果在客户层和子系统之间添加一层Facade，那么客户系统之和Facade打交道，子系统中也只和Facade打交道，那么在这时候，也就减少了客户和自系统的依赖程度，相对使两个系统更加独立，可维护提高。
<1>门面模式的动机：
上述方案A的问题在于组件的客户和组件中的各种复杂的子系统有了过多的耦合，随着外部客户程序和子系统的演化，这种过多的耦合面临很多变化的挑战。
<2>门面模式的定义：
为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。

Façade的结构：

Façade更多的是表达的一种设计原则和思想。
要点总结：
<1>从客户程序角度来看，Facade模式简化了整个组建系统的接口，对于组建内部与外部客户程序来说，达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
<2>Facade设计模式更注重从构架的层次去看整个系统，而不是单个类的层次，Facade很多时候更是一种架构设计的模式。
<3>Facade设计模式并非一个集装箱，可以任意的放入任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是简单的功能集合，以便能够实现松耦合，高内聚的特性。

（2）代理模式
<1>代理模式的动机：
在面向对象系统中，有些对象由于某种原因（比如对象创建开销很大或者某些操作需要安全控制或者需要进程外访问等），直接访问会给使用者、或者系统结构带来很多的麻烦。
<2>代理模式的定义：
为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。

client端：
class ISubject{
public:
    virtual void process();
};

class RealSubject: public ISubject{
public:
    virtual void process(){
        //....
    }
};

class ClientApp{
    ISubject* subject;
public:
    ClientApp(){
        subject=new RealSubject();
    }
    void DoTask(){
        //...
        subject->process();
        
        //....
    }
};

proxy端：
class SubjectProxy: public ISubject{
public:
    virtual void process(){
        //对RealSubject的一种间接访问
        //....
    }
};

class ClientApp{
    ISubject* subject;
public:
    ClientApp(){
        subject=new SubjectProxy();
    }
    void DoTask(){
        //...
        subject->process();
        
        //....
    }
};

用户程序不能直接访问RealSubject对象，那么他需要使用一个代理类Proxy来代理的访问RealSubject对象。
要点总结：
<1>“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方案。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的Proxy对象便是解决这一问题的常用手段。
<2>具体Proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组建模块提供抽象代理层，在架构层次对对象做proxy。
<3>proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

（3）适配器模式
<1>适配器模式的动机：
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
<2>适配器模式的定义：
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

//目标接口（新接口）
class ITarget{
public:
    virtual void process()=0;
};

//遗留接口（老接口）
class IAdaptee{
public:
    virtual void foo(int data)=0;
    virtual int bar()=0;
};

//遗留类型
class OldClass: public IAdaptee{
    //....
};

//对象适配器
class Adapter: public ITarget{ //继承
protected:
    IAdaptee* pAdaptee;//组合
public:
    Adapter(IAdaptee* pAdaptee){
        this->pAdaptee=pAdaptee;
    }
    virtual void process(){
        int data=pAdaptee->bar();
        pAdaptee->foo(data);
    }
};

//类适配器
class Adapter: public ITarget,
               protected OldClass{ //多继承
}

int main(){
    IAdaptee* pAdaptee=new OldClass();
    ITarget* pTarget=new Adapter(pAdaptee);
    pTarget->process();
}
class stack{
    deqeue container;       // 底层容器
};

class queue{
    deqeue container;       // 底层容器
};

要点总结：
<1>Adapter模式主要应用于“希望复用一些现存的类，但是接口又与服用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
<2>GoF23定义了两种Adapter模式的结构实现：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合的精神。
<3>Adapter模式可以实现的非常灵活，不必拘泥于GoF23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。

（4）中介者模式
<1>中介者模式的动机：
在软件构建的过程中，经常出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到了一些需求的更改，这种直接的引用关系将面临不断的变化。
在这种情况下，我们可以使用“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
<2>中介者模式的定义：
用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各个对象不需要显示的相互引用（编译时依赖 -> 运行时依赖），从而使其耦合松散（管理变化），而且可以独立的改变他们之间的交互。

上图描述了依赖关系的解耦合过程。
通过中间的ConcreteMediator将ConcreteColleague1和ConcreteColleague2进行了依赖。从而使得ConcreteColleague1和ConcreteColleague2之间不在直接进行依赖。以此来进行解耦。
要点总结：
<1>将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
<2>随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
<3>Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。