设计模式 - 创建型模式

1.　单件模式

• 意图
  保证一个类仅有一个实例，并提供一个访问它的全局访问。
• 实现要点
  Singleton模式是限制而不是改进类的创建。
  Singleton类中的实例构造器可以设置为Protected以允许子类派生。
  Singleton模式一般不要支持Icloneable接口，因为这可能导致多个对象实例，与Singleton模式的初衷违背。
  Singleton模式一般不要支持序列化，这也有可能导致多个对象实例，这也与Singleton模式的初衷违背。
  Singleton只考虑了对象创建的管理，没有考虑到销毁的管理，就支持垃圾回收的平台和对象的开销来讲，我们一般没必要对其销毁进行特殊的管理。
  理解和扩展Singleton模式的核心是“如何控制用户使用new对一个类的构造器的任意调用”。
  
• 详见
  http://terrylee.cnblogs.com/archive/2005/12/09/293509.html
  

2.　简单工厂模式

• 意图
  提供一个类，由它负责根据一定的条件创建某一具体类的实例
  
• 实现要点
  工厂类负责创建的对象比较少。
  客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心。
• 详见
  http://www.cnblogs.com/anlyren/archive/2008/01/25/simple_Factory_Pattern.html  
  

3.　工厂方法模式

• 意图
  定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
• 总结
  Factory Method要解决的就是对象的创建时机问题，它提供了一种扩展的策略，很好地符合了开放封闭原则。
• 详见
  http://terrylee.cnblogs.com/archive/2006/01/04/310716.html 

4.　抽象工厂模式

• 意图
  提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
  
• 实现要点
  抽象工厂将产品对象的创建延迟到它的具体工厂的子类。
  如果没有应对“多系列对象创建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。
  系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
  抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。
  通常在运行时刻创建一个具体工厂类的实例，这一具体工厂的创建具有特定实现的产品对象，为创建不同的产品对象，客户应使用不同的具体工厂。
  把工厂作为单件，一个应用中一般每个产品系列只需一个具体工厂的实例，因此，工厂通常最好实现为一个单件模式。
  
• 总结
  抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。
  
• 详见
  http://terrylee.cnblogs.com/archive/2005/12/13/295965.html

5.　建造者模式

• 概念
  将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
• 适用场合
  创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。
  要创建的复杂对象的算法，独立于该对象的组成部分，也独立于组成部分的装配方法时。
• 详见
  http://www.cnblogs.com/BeyondAnyTime/archive/2012/07/19/2599980.html
  

6.　原型模式

• 意图
  采取复制原型对象的方法来创建对象的实例
• 注意
  因为使用原型模式的时候每个类都要具备克隆方法。如果在类的设计之初没有很好的规划，等使用很久了才想到克隆，就可能非常的麻烦，尤其是在设计到深层次复制的时候，因为此时牵扯到很多因素，而且工作量非常大。
• 详见
  http://www.cnblogs.com/guoshiandroid/archive/2010/07/03/1770357.html