上周讲述了DOF设计模式中的“组件协作”模式（包括template method模式、strategy策略模式、observer观察者模式）和“单一职责”模式（包括decorator装饰模式和bridge桥模式）。本周主要内容为：“对象创建”模式和“接口隔离”模式，其中“对象创建”模式包括工厂方法、抽象工厂、原型模式和构建器，“接口隔离”模式包括门面模式、代理模式适配器和中介器。
（一）对象创建模式
通过“对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
为什么要绕开new？因为new会带来细节依赖，违背依赖倒置原则。
典型模式有Factory Method、Abstract Factory、Prototype、Builder
1.Factory Method工厂方法
Factory Method工厂方法的动机：在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？
Factory Method工厂方法的模式定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。
Factory Method工厂方法结构如图所示。
Factory Method工厂方法通过虚函数创建多态new，没有依赖具体类，而是依赖抽象类。
总结：
（1）Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。
（2）Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
（3）Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。
2.Abstract Factory抽象工厂
Abstract Factory抽象工厂动机：在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？
Abstract Factory抽象工厂模式定义：提供一个接口，让该接口负责创建一系列“相关或者互相依赖的对象”，无需指定它们具体的类。
Abstract Factory抽象工厂结构如图所示。
总结：
（1）如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。
（2）系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
（3）Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
3.Prototype原型模式
Prototype原型模式模式定义：使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。
这里的拷贝是指深克隆，每次要使用时通过克隆自己从而创建对象，调用拷贝构造函数。
Prototype原型模式结构如图3所示。
图3
总结：
（1）Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。
（2）Prototype模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone。
（3）Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝。
4.Builder构建器
Builder构建器动机：在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
Builder构建器模式定义：将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）。
构建器解决对象的创建工作，将构建过程是提取出来成为一个类。
Builder构建器结构如图所示。
总结：
（1）Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
（2）变化点在哪里，封装哪里——Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
（3）在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C++ vs. C#）。
（二）接口隔离模式
在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题，甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
典型模式有：Facade、Proxy、Adapter、Mediator。
总结：
（1）从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
（2）Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
（3）Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
6.Proxy代理模式
Proxy代理模式动机：在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。
如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。
Proxy代理模式模式定义：：为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。
Proxy代理模式结构如图所示。
总结：
（1）增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常见手段。
（2）具体proxy设计模式的实现方式、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做proxy。
（3）Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。
7.Adapter适配器
Adapter适配器动机：在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁徙的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？
Adapter适配器模式定义：将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Adapter适配器结构如图所示。
总结：
（1）Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁徙等方面非常有用。
（2）GoF 23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。
（3）Adapter模式可以实现的非常灵活，不必拘泥于Gof23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。
8.Mediator中介者
Mediator中介者动机：在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
Mediator中介者模式定义：用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。