设计模式学习（三）：创建型模式【转】

原文&＃xff1a;http://www.cnblogs.com/zhenjing/archive/2010/12/09/design_category.html

模式的分类

　　模式依据其目的可分为创建型&＃xff08;Creational&＃xff09;、结构型(Structural)、或行为型(Behavioral)三种。创建型模式与对象的创建有关&＃xff1b;结构型模式处理类或对象的组合&＃xff1b;行为型模式描述类或对象之间的职责分配和交互。

　　根据范围准则&＃xff0c;模式可分为类模式和对象模式。类模式处理类和子类之间的关系&＃xff0c;这些关系通过继承建立&＃xff0c;是静态的&＃xff0c;由编译时确定。对象模式处理对象间的关系&＃xff0c;这些关系在运行时刻是可变化的&＃xff0c;更具动态性。从某种意义上来说&＃xff0c;几乎所有模式都使用继承机制&＃xff0c;所以“类模式”专指那些集中于处理类间关系的模式&＃xff0c;而大部分模式都属于对象模式的范畴。

　　分类如下:

     说明:

　　创建型类模式将对象的部分创建工作延迟到子类&＃xff0c;而创建型对象模式则将它延迟到另一个对象中。结构型类模式使用继承机制来组合类&＃xff0c;而结构型对象模式则描述了对象的组合方式。行为型类模式使用继承描述算法和控制流&＃xff0c;而行为型对象模式则描述一组对象如何协作完成单个对象所无法完成的任务。

　　还有其他组织模式的方式。有些模式经常会被绑在一起使用&＃xff0c;例如,Composite常和Iterato r或Visitor一起使用&＃xff1b;有些模式是可替代的&＃xff0c;例如&＃xff0c;Prototype常用来替代Abstract Factory&＃xff1b;有些模式尽管使用意图不同&＃xff0c;但产生的设计结果是很相似的&＃xff0c;例如&＃xff0c;Composite和Decorator的结构图是相似的。

创建型模式

　　创建型模式抽象了实例化过程。它们帮助一个系统独立于如何创建、组合、管理和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类&＃xff0c;而一个对象创建型模式将实例化委托给另一个对象。

　　随着系统演化得越来越依赖于对象复合而不是类继承&＃xff0c;创建型模式变得更为重要。当这种情况发生时&＃xff0c;重心从对一组固定行为的硬编码(hard-coding)转移为定义一个较小的基本行为集&＃xff0c;这些行为可以被组合成任意数目的更复杂的行为。这样创建有特定行为的对象要求的不仅仅是实例化一个类&＃xff0c;而可能是一组复杂的对象组合。

　　在这些模式中有两个不断出现的主旋律。第一&＃xff0c;它们都将关于该系统使用哪些具体的类的信息封装起来。第二&＃xff0c;它们隐藏了这些类的实例是如何被创建和放在一起的。整个系统关于这些对象所知道的是由抽象类所定义的接口。因此&＃xff0c;创建型模式在什么对象被创建&＃xff0c;谁来创建&＃xff0c;如何创建&＃xff0c;以及何时创建这些方面给予设计者很大的灵活性。它们允许你用结构和功能差别很大的“产品对象”配置一个系统。配置可以是静态的&＃xff08;即在编译时指定&＃xff09;&＃xff0c;也可以是动态的&＃xff08;在运行时&＃xff09;。

Abstract Factory

意图: 提供一个创建一系列相关或相互依赖对象的接口&＃xff0c;用于创建相关或依赖的对象家族&＃xff0c;而无需明确指定具体类。

动机: 封装一系列相关或相互依赖对象的创建&＃xff0c;隐藏了相关对象创建过程的选取组合问题,减少错误组合的可能性。

适用性: 常用于不同软件构建环境(平台,不同的软件需求配置等)下相关对象的创建。

结构: 一般使用继承来封装不同软件构建环境。父类定义所有的一系列创建接口&＃xff0c;由具体类实现。本质上抽象工厂由多个工厂方法组成(每个子类均为对象工厂)。

优点: 减少对象错误组合使用的可能性。

Factory Method

意图&＃xff1a;定义一个用于创建对象的接口&＃xff0c;让子类决定将哪一个类实例化。FactoryMethod使一个类的实例化延迟到其子类。

动机: 让子类自己决定所需创建的对象,这里的对象一般并非子类本身&＃xff0c;而是子类所需要的其他对象。本质&＃xff1a;通过子类来创建对象&＃xff0c;使客户仅依赖父类的抽象接口。

适用性: 常用于调用统一的抽象类接口,而让子类自己决定(实现)所需创建的对象&＃xff0c;由此&＃xff0c;封装了子类所创建对象的类型。

结构: 一般内嵌于具有继承关系的子类中&＃xff0c;很少单独使用。抽象类提供创建接口&＃xff0c;子类实现。典型例子: STL中迭代器的创建(end()&＃xff0c;begin())。常用抽象接口&＃xff1a;MakeObj()&＃xff1b;CreateObj()。

优点: 封装了子类所创建对象的类型。

组合模式: 经常用于TemplateMethod中的子类中,使创建过程成为TemplateMethod的一个步骤。

Note&＃xff1a;实际中&＃xff0c;设计者常常使用专门的工厂类负责相关对象的创建&＃xff0c;这不同于FactoryMethod&＃xff0c;但都属于对象工厂(负责创建对象的类)。

Builder

意图: 将一个复杂对象(一般内部含有多个其他对象)的构建与它的表示分离&＃xff0c;使得同样的构建过程可以创建不同的表示。

动机: 封装复杂对象或具有多种组合的对象的创建过程。比如提供不同的接口表示同一个对象不同的构建过程。

适用性: 常用于封装具有可变构建过程的对象。

结构: 提供不同的接口封装不同的构建过程&＃xff1b;提供较小粒度的接口&＃xff0c;封装构建过程中对象间的交互关系&＃xff0c;让客户通过提供的接口自己合成创建过程。

优点: 要么封装整个对象的构建&＃xff0c;要么封装了创建过程中对象间的交互关系。

组合模式: 经常用于封装Composite的创建过程(提供小粒度的对外接口)。

Prototype

意图&＃xff1a;用原型实例指定创建对象的种类&＃xff0c;并且通过拷贝这个原型来创建新的对象。

动机: 拷贝已有对象(包括状态).

适用性: 常用于包含状态的对象拷贝&＃xff0c;简化状态的同步过程。典型例子&＃xff1a;CAD。

结构: 对象既有自拷贝的对外接口。注意区分浅拷贝和深拷贝&＃xff0c;多线程也需要注意。

优点: 简化了对象状态的重新构建。向客户隐藏制造新实例的复杂性&＃xff1b;提供让客户能够产生未知类型对象的途径&＃xff1b;有时复制对象更高效。

组合模式: 有时与工厂Factory一同使用&＃xff0c;通过单一的接口来创建所需的对象。(Map&＃43;clone)

Singleton

意图&＃xff1a;保证一个类仅有一个实例&＃xff0c;并提供一个访问它的全局访问点。

动机: 保证一个类仅有一个实例。

适用性: 方便对象的全局访问&＃xff1b;或在当对象因存在多个副本引发性能问题时,才考虑使用Singleton来限制对象实例化。

结构: 常常和静态变量等相关.

优点: 方便全局访问&＃xff0c;限制对象实例化&＃xff0c;解决系统的性能问题。

缺点: Singleton本质上是一个全局变量&＃xff0c;全局变量并不是什么好东西&＃xff0c;不好管理&＃xff0c;且容易引发其他问题。一般并不推荐使用Singleton.

ObjectPool

意图: 在创建对象比较昂贵&＃xff0c;或者所能创建对象(File/socket)数目有限制时&＃xff0c;管理对象的重用。

动机: 封装对重用对象的管理。

适用性: 当对象的创建和/或管理必须遵循一组定义明确的规则集, 并且这些规则都与如何创建对象、创建多少对象和在已有对象完成当前任务时如何重用等相关时&＃xff0c;使用Object Pool来创建和管理对象。

结构: 类似于简单的Factory&＃xff0c;即使用单独的类。

优点: 封装对重用对象的管理。

CreationMethod

意图: 基于类的不同构造函数&＃xff0c;提供多种不同的对象构建过程

动机: 使用不同的Creation函数(语义明确)来区别所创建对象的用途(意图)。

适用性: 类中存在多种不同的构造函数&＃xff0c;并且每种构造函数所构建的类有不同的用途/意图。

结构: 一般Creation函数需要是static函数&＃xff0c;根据所使用的语言而定。类的构造函数为私有。

优点: 根据不同的Creation函数名&＃xff0c;可以很清楚的描述构建对象的用途。

变化: 有时直接把派生类的构建直接放入抽象类中&＃xff0c;并使用Creation Method。