简单说就是嫁接。从类层次图的设计原则来说，就是该干什么的就让它干什么，需要协作时，组合它们。

Singleton 范式唯一需要注意的就是它范围。这个范围根据需要来指定，如：

n        一个进程的地址空间内的唯一实例；

n        一个物理机器内；

n        一个虚拟机的地址空间内；

n        一个局域网内；

n        等等。

如果你是在一个库中实现，并且在多用户 - 多进程环境下运行，同步控制也应该在设计时就考虑好。

创建型设计范式一句话描述 ：

Abstract Factory ——你要什么标准就实现什么标准，谁叫客户是上帝呢；

Builder ——装配和集成或从一种形式到另一种形式的转化；

Factory Method ——挑自己爱的；或只选对的，不选贵的；

Prototype ——自我复制；

Singleton ——天下无双；

Prototype 范式是一个运行时实例的自我复制，即这个实例把自己作为它所代表的这个类型的工厂。有点像《西游记》中的孙悟空以自己为原型，用自己的猴毛变成自己一样。

有这样的能力需要具备的条件是：

1、 提供一个该类型的实例作为原型，比如石头里蹦出了孙悟空一样；

2、 这个实例必须具有自我复制能力，比如孙悟空从他师傅那获得神技；

实现这个范式的基础就是在一个需要自我复制的实例中添加一个接口：

class Prototype

{

  public:

virtual Prototype clone()

{

  // 根据自己的需要实现

};

};

原文 Intent 部分 ：

      “ This creates a dilemma: The framework must instantiate classes, but it only knows about abstract classes, which it cannot instantiate. ”

1、 Application 使用 Factory Method 对 Framework 隐藏了 Document 的实现细节；

class Document

{

       virtual void open() = 0;

       virtual void close() = 0;

};

class Factory

{

       public:

              // 一个虚函数，被子类实现以便决定真实的 Document 类型；

              virtual Document createDocument() { return 0;};

};

class Application : public Factory

{

       …

};

class Framework

{

       private:

              Application _application;

              Document _document;

       …

};

2、 提供 hook

Hook 是用来挂东西的。这个被挂的东西要求与 Hook 的定义具有相同的原型。在 C 中，它被一个函数指针定义；在 C++ 中，由于 overriding 的提供，它可以被虚函数以及纯虚函数定义；

Builder 范式是一个 Object Creational 范式。

Builder 范式主要用于装配（ Assembly ）和集成（ Integration ）。一是为相同内容创建不同的展现；二是使用不同的部分进行组合，产生一种新的对象类型。

原文 Intent 部分 ：

       “ ... create different representations . ”

       可以理解为把相同的内容经过 Builder 处理后，创建新的或转换成不同的形状。这可以想到编译器、文档的格式转换器等等的实现和用途。

Builder 范式要求从物理上隔离使用者和转换器对象。

转换器使用者根据自己的需要要求转换器对它选定的内容进行规定的转换，但它并不知道转换器如何转换；而转换器在接收到使用者传递的内容后，按照使用者的要求启动转换过程。

1、 作为一个 Singleton 实现；

这种方式的说明将在说到 Singleton 范式补充。

2、 创建系列产品；

在这种方式下又包含两种子方式：

a)        使用 Factory Method 范式；

简单地说，使用这种方式的实现就是定义一个接口，针对自己定义的产品（ widget ）集合中每个类型定义一个创建方法，并在其子类中提供实现。

b)        使用 Prototype 范式；

原文 Implementation 部分 ：

“ The concrete factory is initialized with a prototypical instance of each product in the family, and it creates a new product by cloning its prototype . ”

这句话的意思是说，对在同一个产品簇的产品，当它们的工厂被实例化时，它们同时也被实例化到这个工厂中，并在客户需要其中某个类型的产品实例时，使用 clone 方式创建一个新的对象给客户。

原本 Implementation 部分 ：

“ The Prototype-based approach eliminates the need for a new concrete factory class for each new product family . ”这句话是上句引文的下一句。

我个人认为，这句话的本意是针对 a ）方法而言的；但却与它的上一句话相互矛盾。因为上一句说这个方法是针对“ in the family ”的，而本句是针对“ a new concrete factory ”和“ new product family ”的。稍微有点英语常识的人都知道，“ the ”是定冠词，一般用于特指；而“ a ”在这里表示任意。因此我认为是说不通的，换句话说，使用基于 Prototype 的实现仍然不能消除一个具体的工厂针对一个具体产品簇的限制。即使可以，一般应用在该产品集合包含较少的产品类型时使用。

3、 定义可扩展的工厂；

这种方式针对自己定义的产品（ widget ）集合不可预知的类型扩展，提供一种叠加的方式，以便扩展自己的工厂来生产被扩展的产品类型。

原文 Intent 部分：

“ …without specifying their concrete classes ”，即对使用这个对象的用户，不直接提供 new 操作；

一个对象的类型支持多种标准；并满足用户在多种标准之间自由地从一种标准转换成另外一种标准。

为了实现这个范式，需要为将要实现的 widget 集合定义一个总的工厂抽象类，即： AbstractFactory ，同时在这个工厂类中为每个 widget 定义一个类似于 CreateXXX （ Create 表示要执行的活动， XXX 表示被创建的 widget 的类型名称）的方法；并对要实现的 widget 集合中的每个 widget 定义一个抽象类。

原文 Motivation 部分：

“ There’s also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. ”

 
由于对实现每个标准下的widget类型集合需要提供相应的WidgetFactory的实现，因此用户需要实例化每个标准下的工厂实现。

为解决这个问题，在Java中存在典型的实现方式。就是定义上图的上一部分，然后自己实现一个作为默认的；然后，在某个地方实现一个静态的方法，以实例化真实的WidgetFactory；接下来给应用开发人员提供一个标准的系统属性，比如-Djava.widget.factory=；这样可实现灵活的撤换。