转载请注明原文地址：http://www.cnblogs.com/ygj0930/p/6515557.html
一：简单工厂模式
适用情况：一个基类有很多个子类，在程序中可能会在不同情况下需要使用到不同的子类。传统做法是用条件语句在相应条件下显式调用子类的构造函数来创建一个子类对象来进行操作。这样有个弊端就是一旦子类多起来就很麻烦，要创建很多子类对象，容易搞混。并且所以创建、调用都要显式进行，很繁琐。
这个时候，就可以用简单工厂模式来进行对多情况下返回不同子类对象、用一个父类指针管理多个子类对象的简便操作。
模式实现：
首先，定义一个基类（抽象类）以及其中的抽象方法们；
然后，定义一系列子类实现基类以及方法；
最后，定义一个工厂类，在工厂类中定义一个工厂方法，该方法接收一个参数，依据参数的不同return不同的子类对象：return new subclass();
而在其他类、方法中，只能操作工厂类的工厂方法来获得相应对象并调用方法，对子类的具体实现是不可见的。并且，是用一个父类指针来接收相应的对象来操作。可以在不同情况下调用工厂方法更改指针所指的子类对象。从而实现一个指针变量管理不同情况下的子类的目的。
UML图：
二：工厂方法模式
简单工厂模式的最大不足在于，工厂类负责一切子类的创建，一旦有新的子类添加，则要相应修改工厂类、工厂方法。违背了“开闭原则”（开闭原则：可以对外扩展，但不能被外面的变化引起内部修改）。
解决方法就是工厂方法模式：
在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象。这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。
即：抽象的工厂基类中定义了抽象的工厂方法；
然后为每个产品子类定义相应的具体工厂，如工厂子类A专门负责返回产品子类A；
在应用时，使用一个工厂基类指针指向具体的工厂实例调用get()方法得到具体的产品；
这样，一旦有新产品添加，只需要增加一个工厂子类即可，而不需要修改任何地方。
UML图：
三：建造者模式
使用情况：
一个类中的成员有对其他类的引用，并且在不同情况下引用的类是不同的子类。我们称这个类是有不同部件类构成的，并且部件类随情况的不同而不同。
这种情况下，如果为每种情况定义一个具体的子类，情况多起来的话就要定义很多很多类了，十分麻烦。这个时候，可以使用建造者模式。
建造者模式局限：各个产品的部件类不能有太大的差别，产品内部不能太复杂，不然需要定义很多适应不同情况的建造者，造成臃肿。
抽象建造者：定义了建造者们需要对那些部件进行建造操作，即定义针对各个部件类的build()方法，一个方法返回一个部件类；
具体建造者：针对不同的产品，每个产品对应一个建造者，在其中实现了各部件的build()方法获取明确的部件子类，最后组装出一个具体的产品类，通过方法返回出去；
指挥者：这个是用户唯一可见的类，指挥者包含一个建造者父类指针、一个制造方法。用户通过指挥者对象，指定具体的建造者对象（构造方法指定、setBuilder(builder)指定），然后制造方法中依次调用建造者的buildX()方法来指定产品的各个部件，最后return builder.getProduct()；把一个建造好的产品返回。
四：单例模式
在某些情况下，一个类只能拥有一个实例对象存在，比如：打印机对象，在某一时刻只能有一台打印机工作，所以只需要一个打印机对象就够了。在需要打印时，先向系统请求打印机，系统检查打印机对象是否存在，有则把这个打印机对象返回给你用。没有，则新建一个打印机给你，同时把这个打印机保存起来，下次申请使用时直接把这个打印机对象返回给你。
类似于这种只需要一个类对象的情况下，我们使用单例模式。
由于单例类的成员是静态私有的，所以不能通过 类名或对象名.成员 的形式访问到，而只能通过公有的静态函数getXX()来访问到该实例成员。而且该实例成员是静态的，所以只会有一个。于是，无论你在外面创建了多少个Singleton 变量，都只能通过getIntance()方法来获得具体对象，而这些对象都是同一个。
