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