每一天从不跳舞，这是对生活的失望.

创建模式可以抽象化实例化过程. 它们帮助系统独​​立于这些对象的创建，组合和表示方式. 类创建模式使用继承来更改实例化的类，而对象创建模式将实例化委托给另一个对象.

随着系统的发展，越来越多地依赖对象组成而不是类继承，创建模型变得越来越重要. 发生这种情况时，重点就从硬编码一组固定的行为转变为定义较小的一组基本行为，这些基本行为可以组合成许多更复杂的行为. 以这种方式创建具有特定行为的对象不仅仅需要实例化一个类.

在这些模式下有两个重复出现的主题. 首先，它们都封装了有关系统使用哪些特定类的信息. 其次，它们隐藏了这些类的实例是如何创建和组合的. 整个系统对这些对象的了解是抽象类定义的接口. 因此，创建模式在创建内容，创建者，创建方式以及创建时间方面给您很大的灵活性. 它们使您可以使用结构和功能差异很大的“产品”对象配置系统. 配置可以是静态的（即在编译时指定）或动态的（在运行时指定）.

提供一个接口，以创建一系列相关或相互依赖的对象，而无需指定其具体类.

ConcreteFactoryAbstractProductConcreteProductClient分隔具体的类. 易于更换的产品线. 有利于产品的一致性. 支持新产品很难.

参考文献:

将复杂对象的组成部分从其表示形式中分离出来，以便同一构造过程可以创建不同的表示形式.

ConcreteBuilderDirectorProduct允许您更改产品的内部表示形式. 将构造代码与演示代码分开. 使您可以更精细地控制构建过程.

参考文献:

定义用于创建对象的接口，然后让子类确定要实例化的类.

ConcreteProductCreatorConcreteCreator不再将特定于应用程序的类绑定到代码. 只需创建特定的ConcreteProduct对象，就必须创建Creator的子类. 提供子类的钩子. 连接并行的类层次结构.

参考文献:

指定要通过原型实例创建的对象的类型，并通过复制这些原型来创建新对象.

ConcretePrototypeClient

参考文献:

确保一个类只有一个实例，并提供一个全局访问点来访问它.

受控访问唯一实例. 缩小名称空间. 允许优化操作和表示. 允许可变数量的实例. 比课堂操作更灵活.

参考文献:

使用系统创建的那些对象的类来对系统进行参数化的方法有两种:

参数化系统的另一种方法更多地取决于对象组成:

考虑以原型模式描述的图形编辑器框架. 通过产品类可以通过多种方式对GraphicTool进行参数设置:

哪种模型最好取决于许多因素. 乍一看，在我们的图形编辑器框架中，“工厂方法”模式最易于使用. 定义GraphicTool的新子类很容易，并且仅在定义调色板时才创建GraphicToo的实例. 它的主要缺点是GraphicTool子类的数量激增，而且它们都做不到.

AbstractFactory没有太多改进，因为它需要同样大的GraphicsFactory类层次结构. 仅当已经存在GraphicsFactory类层次结构时，AbstractFactory才比FactoryMethod更好. 是因为编译器自动提供了它，还是因为系统的其他部分都需要此GraphicsFactory类层次结构.

通常，原型模式可能是最适合图形编辑器框架的模式，因为它只需要为每个Graphics类实现Clone操作. 这样可以减少类的数量，并且Clone可以用于其他用途，而不仅仅是纯实例化.

Factory Method使设计仅具有几个复杂性即可自定义. 其他设计模式需要新的类，而Factory Method仅需要新的操作. 使用AbstractFactory，Prototype或Builder的设计比使用FactoryMethod的设计更为灵活，但也更加复杂. 通常，设计是从使用FactoryMethod开始的，当设计师发现需要更大的灵活性时，设计就会演变为其他创意模式.

结构化模式涉及如何组合类和对象以获得更大的结构. 结构化类模式使用继承机制来组合接口或实现. 一个简单的示例是使用多种继承方法将两个以上的类组合为一个类. 结果，该类包含父类的所有属性. 该模型对于多个独立开发的类库一起工作特别有用. 另一个示例是类形式的适配器模式. 通常，适配器使一个接口（适配器的接口）与其他接口兼容，从而提供了多个不同接口的统一抽象. 为此，类适配器对Adaptee类进行私有继承. 这样，适配器可以用适配器接口表示其接口.

结构化对象模式不结合接口和实现，而是描述如何结合一些对象以实现新功能. 由于可以在运行时更改对象组成关系，因此对象组成方法具有更大的灵活性，并且无法通过静态类组成来实现这种机制.

将类的接口转换为客户所需的另一个接口. 适配器模式允许由于接口不兼容而无法一起工作的类一起工作.

ClientAdapteeAdapter

参考文献:

将抽象部分与实现部分分开，以便它们都可以独立更改.

您不希望抽象及其实现之间存在固定的绑定关系. 应该通过生成子类的方法来增强类的抽象及其实现. 对抽象实现部分的修改不会对客户端产生任何影响，即不必重新编译客户端的代码. （C ++）您想对客户端完全隐藏抽象实现部分. 有许多要生成的类，而这样的类层次结构意味着必须将一个对象分成两部分. 您想在多个对象之间共享实现（也许使用引用计数），但同时要求客户端不知道这一点.

RefinedAbstractionImplementorConcreteImplementor单独的接口及其实现. 提高可伸缩性您可以独立扩展“抽象”和“实现”层次结构. 实施细节对客户是透明的.

参考文献:

将对象分组为树结构，以表示“整体”层次结构. 复合使用户能够一致地使用单个对象和复合对象.

LeafCompositeClient定义一个包含基础对象和复合对象的类层次结构. 简化客户代码. 使添加新类型的组件变得更加容易. 使您的设计更加通用. 有时网络设计模式，您希望组合仅包含某些组件. 使用Composite，您不能依靠类型系统来施加这些约束，必须在运行时进行检查.

参考文献:

动态地向对象添加一些其他职责. 在增加的功能方面，它更加灵活.

ConcreteComponentDecoratorConcreteDecorator比静态继承更灵活. 避免在层次结构中使用过高的类. 装饰器与其组件不同. 有很多小物件.

参考文献:

SubsystemClasses它将子系统组件与客户隔离开. 它实现了子系统与客户之间的松散耦合关系，并且子系统内部的功能组件经常紧密耦合. 如果应用程序要求，它不限制它们对子系统类的使用.

参考文献:

使用共享技术有效地支持大量细粒度的对象.

ConcreteFlyweightUnsharedConcreteFlyweightFlyweightFactoryClient使用Flyweight模式时，传输，查找和/或外部状态的计算都具有运行时开销，尤其是当flyweight最初存储为内部状态时. 但是，这些节省被空间节省所抵消. 共享的Flyweight越多，节省的存储空间就越多. Flyweight模式通常与Composite模式组合以表示分层结构，该结构是共享叶节点的图形. 作为共享的结果，Flyweight叶节点无法存储指向父节点的指针. 父节点的指针将作为其外部状态的一部分传递给Flyweight.

参考文献:

为其他对象提供代理，以控制对该对象的访问.

ProxyRealSubjectProxy模式在访问对象时引入了一定程度的间接访问. 根据代理的类型，附加的间接调用有多种用途: 代理模式还可以向用户隐藏称为写时复制的另一种优化方法，该方法与根据需要创建对象有关. 实施写时复制时必须对实体进行引用计数. 写时复制可以大大减少复制大型实体时的开销.

参考文献:

适配器模式和桥接模式具有一些共同的功能. 它们都为另一个对象提供了另一种间接度，这有利于系统的灵活性. 它们都涉及从本身以外的接口向该对象转发请求.

这些模式之间的主要区别在于它们各自的用途. 适配器模式主要用于解决两个现有接口之间的不匹配问题. 它不考虑这些接口的实现方式，也不考虑它们各自如何演变. 这种方法使他们可以一起工作，而无需重新设计两个独立设计的类中的任何一个. 另一方面，桥接模式将抽象接口与其（可能是多个）实现桥接起来. 尽管此模式允许您修改实现它的类，但它仍为用户提供了稳定的接口. 随着系统的发展，桥接模式也将适应新的实现方式.

由于存在这些差异，因此适配器和桥接模式通常用于软件生命周期的不同阶段. 当发现两个不兼容的类必须同时工作时，有必要使用Adapter模式，其通用目的是避免代码重复. 这里的耦合是不可预测的. 相反，Bridge的用户必须事先知道抽象将具有多种实现，并且抽象和实现都将独立发展. 适配器模式是在设计完类之后实现的. 在设计类之前，先实施Bridge模式. 这并不意味着适配器模式不如桥接模式好，只是因为它们解决了不同的问题.

您可能会想到外观是另一组对象的适配器. 但是，这种解释忽略了Facade定义新接口，而Adapter重用现有接口这一事实. 请记住，适配器使两个现有接口协同工作，而不是定义一个全新的接口.

Composite和Decorator模式具有相似的，这表明它们都基于递归组合来组织可变数量的对象. 这种共性可能使您认为装饰器对象是退化的组合，但是此视图无法理解装饰器模式的要点. 同样，相似性仅以递归组合结束，因为这两种模式的目的不同.

Decorator旨在使您能够在不生成子类的情况下向对象添加职责. 这避免了静态实现所有功能组合，从而导致子类的急剧增加. 复合具有不同的目的. 它旨在构造类，以便可以以统一的方式处理多个相关对象，并且可以将多个对象视为一个对象. 它不是关于装饰，而是关于展示.

尽管它们的用途截然不同，但它们是互补的. 因此，复合模式和装饰器模式通常结合使用. 使用这两种模式进行设计时，我们不需要定义新的类，只需要将一些对象插入在一起即可构建应用程序. 这时，系统中将有一个抽象类，它具有一些复合子类和装饰器子类，以及一些实现系统的基本构建块. 此时，复合材料和装饰器将具有一个公共接口. 从Decorator模式的角度来看，复合材料是ConcreteComponent. 从复合模型的角度来看，装饰器是Leaf. 当然，不必同时使用它们，正如我们所看到的，它们的用途非常不同.

另一个类似于Decorator模式的模式是Proxy. 两种模式都描述了如何对对象提供一定程度的间接引用. 代理和装饰器对象的实现部分都保留指向另一个对象的指针，并且将请求发送到该对象. 但是，它们又有不同的设计目标.

类似于装饰器模式，代理模式构成一个对象并为用户提供一致的接口. 但是与Decorator模式不同的是，Proxy模式无法动态添加或分隔属性，并且它不是为递归组合而设计的. 其目的是提供一种在不方便或不希望使用时直接访问实体的替代方法，例如，如果该实体位于远程设备上，访问受到限制或该实体被永久存储.

在代理模式下，实体定义关键功能，并且代理提供（或拒绝）对其的访问. 在装饰器模式中，组件仅提供某些功能，并且一个或多个装饰器负责完成其他功能. 装饰器模式适用于在编译时无法（至少不方便地）确定对象的全部功能的情况. 这种开放性使递归合成成为Decorator模式的重要组成部分. 在代理服务器模式中不是这种情况，因为代理服务器模式强调可以静态表示的关系（代理服务器及其实体之间的关系）.

行为模式涉及算法和对象之间的责任分配. 行为模式不仅描述对象或类的模式，还描述它们之间的通信模式. 这些模式表征了复杂的控制流，这些流在运行时很难跟踪. 它们将您的注意力从控制流转移到对象的连接方式.

为多个对象提供处理请求的机会，从而避免了请求的发送者和接收者之间的耦合. 将对象连接到一个链中，并沿着该链传递请求，直到对象处理该请求为止.

ConcreteHandlerClient减少耦合. 增强了将责任分配给对象的灵活性. 无法保证接受.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-162343-1.html