如何使用创建型模式

转自：http://www.cnblogs.com/eagle927183/p/3480059.html

名称	GoF的定义	功能描述
Singleton	保证一个类仅有一个实例，并提供一个该实例的全局访问点。	解决的是类实例化个数的问题，严格控制实体对象的数量
Simple Factory	非23种Gof模式，没有Gof定义(个人定义：专门定义一个类来负责创建其他类的实例，被创建的实例常常具有共同的父类。)	解决的是“某个对象”的创建工作，由于需求的变化，这个对象的具体实现常常面临着剧烈的变化，但是这个对象拥有的接口相对稳定。简单工厂实现了客户端和对象创建的解耦。
Factory Method	定义创建对象的接口，让子类决定实例化哪一个类。工厂方法使得一个类的实例化延迟到其子类。	功能和简单工厂一样，它具有简单工厂的优点，并规避了简单工厂的缺点(违反“开放-关闭原则”)
Abstract Factory	提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。	抽象工厂解决了一个系列易变对象的创建问题
Builder	将一个复杂对象的构建与它的表现分离，使得同样的构建过程可以创建不同的表现	应对项目中一些复杂对象的创建工作。所谓“复杂对象”，是指对象中还含有其它的子对象。
Prototype	使用原型实例指定创建对象的种类，并通过复制这个原型创建新的对象	解决了某些结构复杂的对象的创建工作。由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口，原型模式通过原型(可以理解为一个特殊的工厂类)来克隆易变对象

假定在游戏中我们需要用到墙(Wall)、屋子(Room)、门(Door)等部件。同样是对象的创建问题，但是会根据所要解决的问题不同而使用不同的创建型模式。

　　假定一个屋子只允许有一个门存在，那么这就是一个使用Signleton模式的例子，确保只有一个Door类的实例被创建，解决的是对象创建个数的问题。

　　在游戏中需要创建墙、屋子的实例时，为了避免直接对构造器的调用而实例化类，也是应对这些类可能有不同表现的问题，这时我们会使用简单工厂模式或工厂方法模式，每一个部件都有它自己的工厂类，解决的是“单个对象”的需求变化问题。

　　更进一步，在游戏场景中，不可能只有一种风格的墙或屋子，可能有现代风格的(Modern)、古典风格(Classical)等其他系列风格的部件。这时就是一系列对象的创建问题了，可以使用抽象工厂模式，解决的是“系列对象”的需求变化问题。

　　现在再考虑一下：我们知道一个屋子一般由4面墙、一扇窗户、一张门、一个天花板构成，但具体用什么风格的墙、窗户、门、天花板是不断变化的，这时我们可以用生成器模式，解决的是“对象部分”的需求变化问题。

　　如果在游戏中，需要大量的古典风格或现代风格的墙或屋子，这时我们可以通过拷贝一个已有的原型对象来生成新对象，这就是原型模式。通过克隆来解决“易变对象”的创建问题。

　　究竟选用哪一种模式，取决于很多的因素。使用Abstract Factory、Prototype或Builder的设计比使用Factory Method的设计更加灵活，但是也更加复杂，尤其Abstract Factory需要庞大的工厂类来支持。通常，设计以使用Factory Method开始，当需要更大的灵活性时，设计便会向其他设计模式演化，了解多个设计模式，可以让你有更多的选择余地。