设计模式——设计模式选择——创建型对象创建型模式

对象创建型模式

Abstract Factory（Kit）——抽象工厂

意图

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

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述。

适用性

1. 一个系统要独立于它们的产品的创建、组合和表示时
2. 一个系统要由多个产品系列中的一个来配置时
3. 当你强调一系列相关的产品对象的设计以便进行联合使用时
4. 当你提供一个产品类库，而只想显示它们的接口而不是实现时

结构

参与者

• AbstractFactory
  声明一个创建抽象产品对象的操作接口
• ConcreteFactory
  实现创建具体产品对象的操作
• AbstractProduct
  为一类产品对象声明一个接口。
• ConcreteProduct
  定义一个将被相应的具体工厂创建的产品对象
  实现AbstractProduct接口
• Client
  仅使用由AbstractFactory和AbstractProduct类声明的接口

协作

• 通常在运行时刻创建一个ConcreteFactroy类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。
• AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。

效果

AbstractFactory模式有下面的一些优点和缺点：

它分离了具体的类

Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。

它使得易于交换产品系列

一个具体工厂类在一个应用中仅出现一次一一即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。

它有利于产品的一致性

当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而Abstract Factory很容易实现这一点。

难以支持新种类的产品

难以扩展抽象工厂以生产新种类的产品。这是因为Abstract Factory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及Abstract Factory类及其所有子类的改变。我们会在实现一节讨论这个问题的一个解决办法。

实现

下面是实现Abstract Factory模式的一些有用技术：

将工厂作为单件

一个应用中一般每个产品系列只需一个Concrete Factory的实例。因此工厂通常最好实现为一个Singleton。

创建产品

Abstract Factory仅声明一个创建产品的接口，真正创建产品是由Concrete Product子类实现的。最通常的一个办法是为每一个产品定义一个工厂方法（参见Factory Method）。一个具体的工厂将为每个产品重定义该工厂方法以指定产品。虽然这样的实现很简单，但它却要求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别很小。

如果有多个可能的产品系列，具体工厂也可以使用Prototype模式来实现。具体工厂使用产品系列中每一个产品的原型实例来初始化，且它通过复制它的原型来创建新的产品。在基于原型的方法中，使得不是每个新的产品系列都需要一个新的具体工厂类。

定义可扩展的工厂

Abstract Factory通常为每一种它可以生产的产品定义一个操作。产品的种类被编码在操作型构中。增加一种新的产品要求改变Abstract Factory的接口以及所有与它相关的类。一个更灵活但不太安全的设计是给创建对象的操作增加一个参数。该参数指定了将被创建的对象的种类。它可以是一个类标识符、一个整数、一个字符串，或其他任何可以标识这种产品的东西。实际上使用这种方法，Abstract Factory只需要一个”Make”操作和一个指示要创建对象的种类的参数。这是前面已经讨论过的基于Prototype的和基于类的抽象工厂的技术。

相关模式

• Abstract Factory类通常用工厂方法（Factory Method）实现，但它们也可以用Prototype实现。
• 一个具体的工厂通常是一个单件（Singleton）。

Builder——生成器

意图

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述

适用性

在以下情况使用Builder模式

• 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
• 当构造过程必须允许被构造的对象有不同的表示时。

结构

参与者

• Builder
  为创建一个product对象的各个部件指定抽象接口。
• ConcreteBuilder
  实现Builder的接口以构造和装配该产品的各个部件。
  定义并明确它所创建的表示。
  提供一个检索产品的接口（例如，GetResult）。
• Director
  构造一个使用Builder接口的对象。
• Product
  表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。
  包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

协作

• 客户创建Director对象，并用它所想要的Builder对象进行配置。
• 一旦产品部件被生成，导向器就会通知生成器。
• 生成器处理导向器的请求，并将部件添加到该产品中。
• 客户从生成器中检索产品。

下面的交互图说明了Builder和Director是如何与一个客户协作的。

效果

它使你可以改变一个产品的内部表示

Builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产品是通过抽象接口构造的，你在改变该产品的内部表示时所要做的只是定义一个新的生成器。

它将构造代码和表示代码分开

Builder模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息；这些类是不出现在Builder接口中的。每个ConcreteBuilder包含了创建和装配一个特定产品的所有代码。这些代码只需要写一次；然后不同的Director可以复用它以在相同部件集合的基础上构作不同的Product。

它使你可对构造过程进行更精细的控制

Builder模式与一下子就生成产品的创建型模式不同，它是在导向者的控制下一步一步构造产品的。仅当该产品完成时导向者才从生成器中取回它。因此Builder接口相比其他创建型模式能更好的反映产品的构造过程。这使你可以更精细的控制构建过程，从而能更精细的控制所得产品的内部结构。

实现

通常有一个抽象的Builder类为导向者可能要求创建的每一个构件定义一个操作。这些操作缺省情况下什么都不做。一个ConcreteBuilder类对它有兴趣创建的构件重定义这些操作。这里是其他一些要考虑的实现问题：

装配和构造接口

生成器逐步的构造它们的产品。因此Builder类接口必须足够普遍，以便为各种类型的其体生成器构造产品。

1. 一个关键的设计问题在于构造和装配过程的模型。构造请求的结果只是被添加到产品中，通常这样的模型就己足够了。
2. 但有时你可能需要访问前面已经构造了的产品部件。像语法分析树这样自底向上构建的树型结构就是一个例子。在这种情况下，生成器会将子结点返回给导向者，然后导向者将它们回传给生成者去创建父结点。

为什么产品没有抽象类

通常情况下，由具体生成器生成的产品，它们的表示相差是如此之大以至于给不同的产品以公共父类没有太大意思。因为客户通常用合适的具体生成器来配置导向者，客户处于的位置使它知道Builder的哪一个具体子类被使用和能相应的处理它的产品。

在Builder中却省的方法为空

C++中，生成方法故意不声明为纯虚成员函数，而是把它们定义为空方法，这使客户只重定义他们所感兴趣的操作。

相关模式

Abstract Factory与Builder相似，因为它也可以创建复杂对象。主要的区别是Builder模式着重于一步步构造一个复杂对象。而Abstract Factory着重于多个系列的产品对象（简单的或是复杂的）。Builder在最后的一步返回产品，而对Abstract Factory来说，产品是立即返回的。

Composite通常是用Builder生成的。

Factory Method（虚拟构造器Virtual Constructor）——工厂方法

意图

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述

适用性

在下列情况下可以使用Factory Method模式：

• 当一个类不知道它所必须创建的对象的类的时候。
• 当一个类希望由它的子类来指定它所创建的对象的时候。
• 当类将创建对象的职责委托给多个帮助子类中的某一个，并你希望将哪一个帮助子类是代理者这一信息局部化的时候。

结构

参与者

• Product
  定义工厂方法所创建的对象的接口。
• ConcreteProduct
  实现Product接口。
• Creator
  
  1. 声明工厂方法，该方法返回一个Product类型的对象。Creator也可以定义一个工厂方法的缺省实现，它返回一个缺省的ConcreteProduct对象
  2. 可以调用工厂方法以创建一个Product对象。
• ConcreteCreator
  重定义工厂方法以返回一个ConcreteProduct实例。

协作

• Creator依赖于它的子类来定义工厂方法，所以它返回一个适当的Concreteproduct实例。

效果

基本效果

工厂方法不再将与特定应用有关的类绑定到你的代码中。代码仅处理Product接口；因此它可以与用户定义的任何ConcreteProduct类一起使用。

工厂方法的一个潜在缺点在于客户可能仅仅为了创建一个特定的Concreteproduct对象，就不得不创建Creator的子类。当Creator子类不必需时，客户现在必然要处理类演化的其他方面；但是当客户无论如何必须创建Creator的子类时，创建子类也是可行的。

另外两种效果——为子类提供挂钩(hook)

用工厂方法在一个类的内部创建对象通常比直接创建对象更灵活。Factory Method给子类一个挂钩以提供对象的扩展版本。

另外两种效果——连接平行的类层次

迄今为止，在我们所考虑的例子中，工厂方法并不往往只是被Creator调用，客户可以找到一些有用的工厂方法，尤其在平行类层次的情况下。

当一个类将它的一些职责委托给一个独立的类的时候，就产生了平行类层次。考虑可以被交互操纵的图形；也就是说，它们可以用鼠标进行伸展、移动，或者旋转。实现这样一些交互并不总是那么容易，它通常需要存储和更新在给定时刻记录操纵状态的信息，这个状态仅仅在操纵时需要。因此它不需要被保存在图形对象中。此外，当用户操纵图形时，不同的图形有不同的行为。

实现

当应用Factory Method模式时要考虑下面一些问题：

主要有两种不同的情况

1. Factory Method模式主要有两种不同的情况：1）第一种情况是，Creator类是一个抽象类并且不提供它所声明的工厂方法的实现。2）第二种情况是，Creator是一个具体的类而且为工厂方法提供一个缺省的实现。也有可能有一个定义了缺省实现的抽象类，但这不太常见。
2. 第一种情况需要子类来定义实现，因为没有合理的缺省实现。它避免了不得不实例化不可预见类的问题。在第二种情况中，具体的Creator主要因为灵活性才使用工厂方法。它所遵循的准则是，“用一个独立的操作创建对象，这样子类才能重定义它们的创建方式。”这条准则保证了子类的设计者能够在必要的时候改变父类所实例化的对象的类。

参数化工厂方法

该模式的另一种情况使得工厂方法可以创建多种产品。工厂方法采用一个标识要被创建的对象种类的参数。工厂方法创建的所有对象将共享Product接口。

特定语言的变化和问题

不同的语言有助于产生其他一些有趣的变化和警告(cavent)。

使用模板以避免创建子类

工厂方法另一个潜在的问题是它们可能仅为了创建适当的Product对象而迫使你创Creator子类。

命名约定

使用命名约定是一个好习惯，它可以清楚地说明你正在使用工厂方法。

相关模式

Abstract Factory经常用工厂方法来实现。Abstract Factory模式中动机一节的例子也Factory Method进行了说明。

工厂方法通常在Template Methods中被调用。

Prototypes不需要创建Creator的子类。但是，它们通常要求一个针对Product类的Initialize操作。Creator使用Initialize来初始化对象。而Factory Method不需要这样的操作。

Prototype——原型

意图

用原型实例指定对象的种类，并且通过拷贝这些原型创建新的对象。

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述

适用性

当一个系统应该独立于它的产品创建、构成和表示时，要使用Prototype模式；以及

• 当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者
• 为了避免创建一个与产品类层次平行的工厂类层次时；或者
• 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
  

参与者

• Prototype
  声明一个克隆自身的接口。
• Concreteprototype
  实现一个克隆自身的操作。
• Client(GraphiCT00L）
  让一个原型克隆自身从而创建一个新的对象。

协作

客户请求一个原型克隆自身。

效果

Prototype有许多和Abstract Factory和Builder一样的效果：它对客户隐藏了具体的产品类，因此减少了客户知道的名字的数目。此外。这些模式使客户无需改变即可使用与特定应相关的类。
下面列出Prototype模式的另外一些优点。

运行时刻增加和删除产品

Prototype允许只通过客户注册原型实例就可以将一个新的具体产品类并人系统。它比其他创建型模式更为灵活，因为客户可以在运行时建立和删除原型。

改变值以指定新对象

高度动态的系統允许你通过对象复合定义新的行为一一例如，通过为一个对象变量指定值——并且不定义新的类。你通过实例化已有类并且将这些实例注册为客户对象的原型，就可以有效定义新类别的对象。客户可以将职责代理给原型，从而表现出新的行为。

这种设计使得用户无编程即可定义新“类”。实际上，克隆一个原型类似于实例化一个类。Prototype模式可以极大的减少系统所需要的类的数目。

改变结构以指定新对象

许多应用由部件和子部件来创建对象。例如电路设计编辑器就是由子电路来构造电路的。为方便起见，这样的应用通常允许你实例化复杂的、用户定义的结构，比方说，一次又一次的重复使用一个特定的子电路。

Prototy模式也支持这一点。我们仅需將这个子电路作为一个原型增加到可用的电路元素选择板中。只要复合电路对象将Clone实现为一个深拷贝(deep copy),具有不同结构的电路就可以是原型了。

减少子类的构造

Factory Method经常产生一个与产品类层次平行的Creator类层次。Prototype模式使得你克隆一个原型而不是请求一个工厂方法去产生一个新的对象。因此你根本不需要Creator类层次。这一优点主要适用于像C++这样不将类作为一级类对象的语言。C# Java这样的语言从中获益较少，因为你总是可以用一个类对象作为生成者。在这些语言中，类对象经起到原型一样的作用了。

用类动态配置应用

一些运行时刻环境允许你动态将类装载到应用中。在像C++这样的语言中。Prototype模式是利用这种功能的关键。

一些希望创建动态载入类的实例的应用不能静态引用类的构造器。而应该由运行环境在载入时自动创建每个类的实例，并用原型管理器来注册这个实例。这样应用就可以向原型管理器请求新装载的类的实例，这些类原本并没有和程序相连接。

Prototype的主要缺陷是每一个Prototype的子类都必须实现Clone操作，这可能很困难。例如，当所考虑的类己经存在时就难以新增Clone操作。当内部包括一些不支持拷贝或有循环引用的对象时，实现克隆可能也会很困难的。

实现

因为在像C++这样的静态语言中，类不是对象，并且运行时刻只能得到很少或者得不到任何类型信息，所以Prototype特别有用。而在C#、Java这样的语言中Prototype就不是那么重要了，因为这些语言提供了一个等价于原型的东西（即类对象）来创建每个类的实例。
当实现原型时，要考虑下面一些问题：

使用一个原型管理器

当一个系统中原型数目不固定时（也就是说，它们可以动态创建和销毁），要保持一个可用原型的注册表。客户不会自己来管理原型，但会在注册表中存储和检索原型。客户在克隆一个原型前会向注册表请求该原型。我们称这个注册表为原型管理器（prototypemanager)。

原型管理器是一个关联存储器（associative store），它返回一个与给定关键字相匹配的原型。它有一些操作可以用来通过关键字注册原型和解除注册。客户可以在运行时更改甚或浏览这个注册表。这使得客户无需编写代码就可以扩展并得到系统清单。

实现克隆操作

Prototype模式最困难的部分在于正确实现Clone操作。当对象结构包含循环引用时，这尤为棘手。

初始化克隆对象

当一些客户对克隆对象已经相当满意时，另一些客户将会希望使用他们所选择的一些值来初始化该对象的一些或是所有的内部状态。一般来说不可能在Clone操作中传递这些值，因为这些值的数目由于原型的类的不同而会有所不同。一些原型可能需要多个初始化参数，另一些可能什么也不要。在Clone操作中传递参数会破坏克隆接口的统一性。

可能会这样，原型的类已经为（重）设定一些关键的状态值定义好了操作。如果这样的话，客户在克隆后马上就可以使用这些操作。否则，你就可能不得不引人一个Initialize操作，该操作使用初始化参数并据此设定克隆对象的内部状态。注意深拷贝Clone操作——一些复制在你重新初始化它们之前可能必须要被删除掉（删除可以显式地做也可以在Initialize内部做)。

相关模式

Prototype和Abstract Factory模式在某种方面是相互竞争的。但是它们也可以一起使用。Abstract Factory可以存储一个被克隆的原型的集合，并且返回产品对象。

大量使用Composite和Decorator模式的设计通常也可从Prototype模式处获益。

Singleton——单例模式

意图

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

动机

对一些类来说，只有一个实例是很重要的。虽然系统中可以有许多打印机，但却只应该有一个打印假脱机（printer spooler），只应该有一个文件系统和一个窗口管理器。一个数字滤波器只能有一个A/D转换器。一个会计系统只能专用于一个公司。

适用性

在下面的情况下可以使用Singleton模式

• 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
• 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

结构

参与者

• Singleton
  定义一个Instance操作，允许客户访问它的唯一实例。Instance是一个类操作
  可能负责创建它自己的唯一实例。

协作

客户只能通过Singleton的Instance操作访问一个Singleton的实例。

效果

Singleton模式有许多优点：

对唯一实例的受控访问

因为Singleton类封装它的唯一实例，所以它可以严格的控制客户怎样以及何时访问它。

缩小命名空间

Singleton模式是对全局变量的一种改进。它避免了那些存储唯一实例的全局变量污染名空间。

允许对操作和表示的精化

Singleton类可以有子类，而且用这个扩展类的实例来配置一个应用是很容易的。你可以用你所需要的类的实例在运行时刻配置应用。

允许可变数目的实例

这个模式使得你易于改变你的想法，并允许Singleten类的多个实例。此外，你可以用相同的方法来控制应用所使用的实例的数目。只有允许访问Singleton实例的操作需要改变。

比类操作更灵活

另一种封装单件功能的方式是使用类操作（即C++中的静态成员函数或者是Smalltalk中的类方法）。但这两种语言技术都难以改变设计以允许一个类有多个实例。

实现

下面是使用Singleton模式时所要考虑的实现问题：

保证一个唯一的实例

Singleton模式使得这个唯一实例是类的一般实例，但该类被写成只有一个实例能被创建。做到这一点的一个常用方法是将创建这个实例的操作隐藏在一个类操作（即一个静态成员函数或者是一个类方法）后面，由它保证只有一个实例被创建。这个操作可以访问保存唯一实例的变量，而且它可以保证这个变量在返回值之前用这个唯一实 例初始化。这种方法保证了单件在它的首次使用前被创建和使用。

创建Singleton类的子类

主要问题与其说是定义子类不如说是建立它的唯一实例，这样客户就可以使用它。事实上，指向单件实例的变量必须用子类的实例进行初始化。最简单的技术是在Singleton的Instance操作中决定你想使用的是哪一个单件。

另一个选择Singleton的子类的方法是将Instance的实现从父类中分离出来并将它放入子类。

链接的方法在链接时刻确定了单件类的选择，这使得难以在运行时刻选择单件类。使用条件语句来决定子类更加灵活一些，但这硬性限定（hard-wire）了可能的Singleton类的集合。这两种方法不是在所有的情况都足够灵活的。

一个更灵活的方法是使用一个单件注册表（registry of singleton）。可能的Singleton类的集合不是由Instance定义的，Singleton类可以根据名字在一个众所周知的注册表中注册它们的单件实例。

这个注册表在字符串名字和单件之间建立映射。当Instance需要一个单件时，它参考注册表，根据名字请求单件。

注册表查洵相应的单件（如果存在的话）并返回它。这个方法使得Instance不再需要知道所有可能的Singleton类或实例。它所需要的只是所有Singleton类的一个公共的接口，该接口包括了对注册表的操作。

相关模式

很多模式可以使用Singleton模式实现。参见Abstract Factory、Builder，和Prototype。

创建型模式的讨论

用一个系统创建的那些对象的类对系统进行参数化有两种常用方法。

一种是生成创建对象的类的子类；这对应于使用Factory Method模式。这种方法的主要缺点是，仅为了改变产品类，就可能需要创建一个新的子类。这样的改变可能是级联的（cascade)。例如，如果产品的创建者本身是由一个工厂方法创建的，那么你也必须重定义它的创建者。

另一种对系统进行参数化的方法更多的依赖于对象复合：定义一个对象负责明确产品对
象的类，并将它作为该系统的参数。这是Abstract Factory、Builder和Prototype模式的关键特征。所有这三个模式都涉及到创建一个新的负责创建产品对象的“工厂对象”。Abstract Factory由这个工厂对象产生多个类的对象。Builder由这个工厂对象使用一个相对复杂的协议，逐步创建一个复杂产品。Prototype由该工厂对象通过拷贝原型对象来创建产品对象。在这种情况下，因为原型负责返回产品对象，所以工厂对象和原型是同一个对象。

总的来说，Prototype模式对绘图编辑器框架可能是最好的，因为它仅需要为每个Graphics类实现一个Clone操作。这就减少了类的数目，并且Clone可以用于其他目的而不仅仅是纯粹的实例化。

Factory Method使一个设计可以定制且只略微有一些复杂。其他设计模式需要新的类，而Factory Method只需要一个新的操作。人们通常将Factory Method作为一种标准的创建对象的方法。但是当被实例化的类根本不发生变化或当实例化出现在子类可以很容易重定义的操作中（比如在初始化操作中）时，这就并不必要了。

使用Abstract Factory、Prototype或Builder的设计甚至比使用Factory Methd的那些设计更灵活，但它们也更加复杂。通常，设计以使用Factory Methd开始，并且当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化。当你在设计标准之间进行权衡的时候，了解多个模式可以给你提供更多的选择余地。

最后

以上就是任性花瓣为你收集整理的设计模式——设计模式选择——创建型对象创建型模式的全部内容，希望文章能够帮你解决设计模式——设计模式选择——创建型对象创建型模式所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。