5.对象创建
- 通过“对象创建”模式绕开new，来避免对象创建(new)过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定，他是接口抽象之后的第一步工作。
- 典型模式
- Factory Method
- Abstract Factory
- Prototype
- Builder
Factory Method
动机
- 在软件系统中，经常面临创建对象的工作，由于需求的变化，需要创建的对象的具体类型经常变化。
- 定义一个创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）。
结构
要点总结
- Factory Method模式用于隔离类对对象的使用者和具体类型之间的耦合关系。面对经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。
- Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好的解决了紧耦合关系。
- Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。
Abstract Factory
动机
- 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时，由于需求的变化，往往存在更多系列对象的创建工作。
- 提供一个借口，让该接口负责创建一系列“现骨干或者相互依赖的对象”，无需指定他们具体的类。
结构
要点总结
- 如果没有应对“多系列对象构建”的需求变化，则使用Factory Method就足够了。
- “系列对象”指的是在某一特定系列下的对象之间有相互依赖或作用的关系。不同系列的对象之间不能相互依赖。
- Abstract Factory模式主要在于应对“新系列”的需求变动（可以扩展一个系列），其缺点在于难以应对“新对象”的需求变动（某个已有系列需要增加新的对象）。
- 设计模式主要解决稳定中有变化的情况，如果在两个极端情况，一是所有地方都有变化，二是所有地方都不变化，那么就根本没有必要使用设计模式了。
- 综上所看，可以说Factory Method是Abstract Factory的一个特例，所以可以统称为Factory模式。
Prototype
动机
- 在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。
- 使用原型实例制定创建对象的种类，然后通过拷贝（深克隆）这些原型来创建新的对象。
- 和工厂模式不同，它主要能够解决工厂模式要求创建方法/参数相同的问题，尤其适应“某些结构复杂的对象”的创建工作。
结构
要点总结
- Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合。同样要求这些“易变类”拥有“稳定的接口”。
- Prototype模式对于“如何创建易变类的实体对象”曹勇“原型克隆”的方法来做，它使得我们可以非常灵活得动态创建“某些稳定接口”的新对象————所需工作仅仅是注册一个新类的对象，然后在任何需要的地方Clone。
- Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝（C++使用拷贝构造函数即可）。
Builder
动机
- 在软件系统中，经常面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个负责对象的各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。
- 将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）。
结构
要点总结
- Builder模式主要用于“分步骤构建一个负责的对象”。在这其中，“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
- 变化点在哪里，封装到哪里————Builder模式主要在于对应“复杂对象各个部分”的频繁需求变动。缺点在于难以应对“分步骤构建算法”的需求变动。
- 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别。
6.接口隔离
- 在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口。
- 典型模式
- Facade
- Proxy
- Adapter
- Mediator
Facade
动机
- 上图A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化（变化），这种过多的耦合面临很多变化的挑战。
- 为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。
结构
-
更多的体现的是一种设计原则和思想。关键在于子系统内外部的解耦。
要点总结
- 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了“解耦”的效果————子系统内部的任何变化不会影响到Facade接口的变化。
- Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
- Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
Proxy
动机
- 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接的访问会给使用者、或者系统结构带来很多麻烦。如何在不是去透明操作对象的同事来管理/控制这些对象特有的负载型？
- 为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。
结构
要点总结
- “增加一层间接层”是软件系统中对许多复杂问题的一种常见的解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的Proxy对象便是解决这一问题的常用手段。
- 具体的proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做Proxy。
- Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。
Adapter
动机
- 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中使用，但是新环境要求的接口是这些现存对象所不满足的。
- 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
结构
要点总结
- Adapter模式主要应用于“希望复用一些实现的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用和类库迁移时非常有用。
- GOF23 定义了两种Adapter模式的实现结构：
- 对象适配器
class Adapter: public ITarget{ IAdaptee* pAdaptee; //非常灵活 ... }- 非常灵活，pAdaptee可以指向任何可具体的实现类。
- 类适配器
class Adapter: public ITarget, //共有接口 protected IAdaptee{ //多继承，实现继承 ... }- 不是很好，有局限性，如果IAdaptee仅仅是个接口，没有实现，如果换做具体类，那就没有了灵活性，一般不推荐使用。C++中可以，但是在JAVA等语言中不支持。
- 对象适配器
- Adapter模式可以实现的非常灵活，不必拘泥于GOF23中定义的两种结构。
Mediator
动机
- 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
- 用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖to运行时依赖），从而使其耦合松散（管理变化），而且可以独立的改变他们之间的交互。
结构
要点总结
- 将多个对象间复杂的关系关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
- 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂（复杂的消息机制）。这时候可以对Mediator对象进行分解处理。
- Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内部各个对象之间（双向）的关联关系。
