工厂方法：factory method
其实是当我们在类里面要实例化一个类的时候，有可能有多种情况出现，需要创建的对象类型经常改变，我们可以通过对象创建模式来绕过new，支持对象创建的稳定。
Filesplitter* = new Filespliiter//依赖了具体类
Class Binarysplitter{};
Class Txtsplitter{};
Class picturesplitter{};
一般出现这样，我们会构造一个抽象基类
class ISplitter{
};
其他类继承基类
依赖倒置原则，依赖抽象而不依赖细节
所以之前的实例化要改成建立一个工厂
SplitterFactory* factory;
ISplitter * splitter =factory->createsplitter();
class splitterFactory{
public:
virtualisplitter* createspliiter = 0；
virtual~splitterFactory();
};
虚函数是一个运行时的依赖，所以写成虚函数，虚函数就是一种延迟到运行。
前面各种的splitter都是具体类
后面每个配一个具体的工厂
class BinarySplitterFactory: publicsplitterfactory{
public:
virtualISplitter* CreateSpliter(){
returnnew binarySplitter();
}
};
通常把工厂放在函数外面，不需要多次创建具体的工厂，在mainform里也不需要指定他是什么工厂。在mainform的构造器里外界传进来一个factory，然后this->factory = factory;
将来外界传递进来一个具体的splitter就可以使用了。
ISplitter* splitter =
factory->CreateSplitter();//多态的new
那mainform的构造函数需要一个具体类的输入是不是也依赖了具体类？
但mainform里面已经没有依赖了，具体的外面的部分我们不管，但我们铜鼓偶这种方式不是把变化消灭了，而是把变化赶出去了，这就是工厂模式处理事情的意义所在。
对应的有抽象类ISplitter和工厂基类SplitterFactory
可以看到mainform只依赖这两个抽象类
工厂模式的定义是定义一个用于创建对象的接口，让子类决定实例化哪一个类，使一个类的实例化延迟。
抽象工厂：
现在用的是sql数据库，现在要支持多个数据库
class EmployeeDAO{
public:
vectorGetEmployees{
squlconnection* connection = newsqlconnection();
sqlcommand* command = new sqlcommand();
sqldatareader* reader =command->executereader();
}
};
构建一系列基类
//数据库有关的访问的基类
class IDBConnection{};
class IDBCmmand{};
class IDataReader{};
class squlConnection:publicIDBConnection{};
class squlCommand:public IDBCommand{};
class IDBConnectionFactory{
public:
virtualIDBConnection* CreateDBConnection() = 0;
};
class sqlCommandFactory:publicIDBCommandFactory{
};
这样在class employeeDAO中要创建三个工厂
IDBConnection* dbConnectionFactory;
IDBCmmand* dbCommandFactory;
IDBReaderFactory* dataReaderFactory;
但是这三个对象其实是有关联性的，也就是多个工厂之间有关联，假如未来有人传了不同的factory给你，会出错，所以要把三个工厂放在一起。
Class IDBFactory{
};
class sqlDBFactory: public IDBFactory{};
这样的组合相关联的工厂的方式叫虚拟工厂，当软件面临一系列相互依赖的对象的创建工作，
abstractFactory:createProductA()createProductB()
如果不是多对象，没必要用abstractfactory，简单工厂就可以
抽象基类是要求稳定的
每个模式都有缺点，稳定的部分就是缺点
原型模式：
原型模式把工厂模式中基类和抽象类合并起来，
class ISplitter{
public:
virtualvoid split() = 0;
virtualISplitter* clone() = 0;
vitual~ISplitter(){}
};
克隆在具体类中使用拷贝构造函数
使用原型实例指定创建对象的种类，通过拷贝这些原型来创建新的对象
什么时候使用原型，什么时候使用工厂
如果对象很复杂的时候用原型，写不出的时候。
构建器builder：
对象比较复杂，由各个部分的子对象用一定的算法构成，各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。
函数有buildpart1,buildpart2,buildpart3..
使用的流程是稳定的
init(){
..part1,
part2
part3
part4
}
int main(){
House*pHouse = new stoneHouse();
pHouse->Init();
}
把house和house builder相分离
house builde专管构建，把house扔出去
还可以吧init的初始化再拆出去，
class HouseDirector{
public:
HouseBuilder*pHouseBuilder;
HouseDirector(HouseBuilder*pHouseBuilder){
This->pHouseBuilder = pHouseBuilder;
}
House*Construct(){
pHouseBuilder->BuildPart1();
}
};
House和HouseBuilder都是抽象基类，要写StoneHouseBuilder
HouseDirector是不变的。
Class HouseBuilder{
Public:
House*GetResult(){
}
};
门面模式façade
“接口隔离模式”
典型的有façade, proxy, adapter, mediator
某些接口之间的直接依赖会带来很多问题，所以添加一层间接接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
指针是一种间接
软件的诞生也是一种间接的思想
操作系统也是一种间接的思想
软件设计思想的核心是间接
复杂的子系统之间有了过多的耦合
façade模式简化了整个组件系统的接口，达到了一种解耦的效果，内部子系统的任何变化不会影响到façade接口的变化
更注重从架构的层次去看整个系统
并不是一个集装箱，可以任意地放进任何多个对象，façade模式中组件的内部应该是相互耦合关系比较大的一些列组件。
代理模式proxy
增加一层间接接口
有些对象由于某种原因比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等，会给系统结构和使用者带来很多麻烦。
如何在不失去透明操作对象的同时来管理/控制这些对象持有的复杂性？增加一层间接层
结构
class ISubject{
public:
virtualvoid process();
};
class RealSubject: public ISubject{
public:
virtual void process(){
//…
}
};
class ClientApp{
ISubject*subject;
public:
ClientAPP(){
Subject = new SubjectProxy();
}
voiddoTask(){
//…
subject->process();
//…
}
};
class SubjectProxy: public ISubject{
RealSubjectrealSubject;
public:
virtualvoid process(){
对RealSubject的间接访问
}
};
具体的proxy设计模式的实现方法相差非常大，process(){}里的内容，对RealSubject的间接访问
有些对单个对象做细粒度的控制，比如copy-on-write技术，有些可能对组件模块提供抽象代理层，在结构层次对对象做proxy。
Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，损失一些透明性是可以接受的。
适配器adaptor
由于应用环境的变化，需要将一些现存的对象放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种迁移的变化。
使得原本接口不兼容不能一起工作的类可以一起工作。
Class ITarget{
Public:
Virtualvoid process() = 0;
};//目标接口，新接口
class IAdaptee{
public:
virtualvoid foo(int data) = 0;
virtualvoid bar() = 0;
};//遗留接口，老接口
class Adaptor: public ITarget{
protected:
IAdaptee*pAdaptee;
Public:
Adapter(IAdatpee*)
Vitualvoid process(){
intpAdaptee->bar();
pAdaptee->foo(data);
}
};
//遗留类
class OldClass: public IAdatpee{
public:
//…
};
int main(){
IAdaptee*pAdaptee = new Oldclass();
ITarget* Adaptor= new Adaptor(pAdaptee);
pTarget->process();
}
class stack{
deqeuecontainer;
};
class queue{
dequecontainer;
};
这两种也是一种adaptor的一种设计方式
设计模式要更灵活。
Adaptor模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况，在遗留代码复用，类库迁移等方面非常有用。
对象适配器和类适配器，对象适配器是一个继承一个组合。
类适配器，多继承
class Adaptor: public ITarget, protectedIAdaptee{};
中介者
对象互相关联交互的情况，对象有一种复杂的应用关系，当需求发生改变的时候，直接的引用关系会不断的变化。
用一个中介对象来分装一系列的对象交互。中介者使得各个对象不需要显示的相互引用。编译时依赖-》运行时依赖
使其耦合松散，可以独立改变他们之间的交互。
原本多个对象互相耦合，为了解耦，创建一个中介者，然后剩余的对象通过交互都通过这个M来进行，这个时候要建立一个通知的规范。
M同时依赖两边，同时依赖界面元素和绑定模型。
