简单工厂，工厂方法和抽象工厂的区别总结

简单工厂：严格说并不是一个设计模式。简单工厂没有抽象类，只有一个具体工厂类如MyFactory，然后MyFactory里面有个工厂方法CreateProduct返回一个基类产品，具体返回什么具体实例通过传入参数然后用case判断。

用手机生产做个例子：

比如Nokia简单工厂就是只有NokiaFactory工厂类，工厂方法就是CreateNokiaPhone，参数是Nokia手机型号，根据不同型号创建不同的Nokia手机（使用case）。很明显的缺点就是Nokia每发明一个新型号的手机都需要修改简单工厂类（增加case判断），违反了封闭修改，开放扩展原则。

工厂方法：该模式有一个抽象基类和若干个派生的具体工厂类，基类定义了一个虚工厂方法返回指定产品类的基类，派生类需要实现该虚方法并创建具体产品类返回。注意工厂方法的每个具体工厂只负责返回一种产品类。

同样以手机生产做例子：

Nokia工厂方法模式有一个工厂基类NokiaFactory，注意此工厂和上面不一样，是抽象的。该类定义一个虚工厂方法CreateNokiaPhone，该方法返回NokiaPhone基类。然后不同型号的手机对应一个该型号的手机工厂，比如N97Factory，注意此工厂派生于NokiaFactory基类，N97Factory实现虚工厂方法，它返回值是具体的Nokia手机类，如new N97Phone。（注意N97Phone是NokiaPhone的派生类）这样的优点就是，新出一个Nokia手机型号，只需派生一个该型号的工厂而无需修改原来的代码。符合封闭修改，开放扩展原则。

抽象工厂：该模式和工厂方法模式很相似，也是一个抽象基类和若干个具体工厂类，不同的是抽象工厂的工厂基类定义了多个虚工厂方法，每个虚工厂方法负责返回一种产品，多个工厂方法返回多种产品，并且这些产品具有某些联系。

抽象工厂就不止生产Nokia手机了，还生产相关的周边产品，首先NokiaFactory基类会定义两个虚方法，一个是CreateNokiaPhone用来生产手机，另一个是CreateNokiaCharger用于生产对应型号的手机充电器（假定不同型号手机使用不同的充电器）。然后派生类N97Factory就要生产两种相关的产品，一个是N97Phone,还有一个是N97Charger，这两个对象是对应的关系，因此封装到抽象工厂来生产一系列相关的对象。

总结：用最简单的话来概括就是，简单工厂只有一个具体工厂类来创建一种基类的多个不同派生类，工厂方法就是有多个派生于一个基类的具体工厂类，每个具体工厂只生产一种基类的一个派生类，抽象工厂也是只有一个工厂基类，但是每个具体工厂生产多个相关基类的各一个派生类。

工厂模式是最重要的模式，因为大多数模式都需要用到工厂模式。如果不能正确的运用工厂模式，那么可以说无法成为合格的架构师。
多数设计模式的内容讲解的都是如何设计接口。
接口如何产生呢？如果在客户代码（类库的使用者称之为客户）中直接使用具体类，那么就失去了接口的意义。因为接口的使用目的，就是要降低客户对具体类的依赖程度。如果在客户代码中直接使用接口，那么就造成了客户对具体类名称的依赖。（客户最终需要以某种方式指明所需要的具体类，如配置文件或代码，但是只需要指出一次，所以说降低对具体类的依赖程度）。要使客户代码不依赖具体类，唯一的方法，就是让客户代码不依赖具体类的部分不知道具体类的名称。知道具体类名称的部分，仅仅是配置部分。（配置文件或者配置代码）。
依赖不可能完全消除，除非二者毫无联系。但是可以将这种依赖的程度降到最低。
既然不能直接创建具体类，那么就需要通过一个创建者类来创建接口的实现类。这样就产生了工厂类。
那么现在已经知道工厂类存在的理由，抽象创建接口的过程。
这样，就可以使用简单工厂。
简单工厂，一般是两级结构。工厂类创建接口。
随着接口创建复杂性的增强，可能在接口创建的过程中，一个创建者类，无法承担创建所有的接口类的职责。
可能会有这样的情况，我们定义了一个接口，有6个实现类分别是123456号。但是，这六个实现类不可能用一个工厂创建出来，因为123号是windows下的实现，而456号是linux上的实现。（假设我们使用的语言不是广大人民群众热爱的java语言），那么这个时候，我还需要客户方用相同的方式来创建这个借口，而不是在代码中到处写
[code:1]if (操作系统=="windows"){
...
}
else{
...
}[/code:1]
那样就太麻烦了。设计模式就是为了减少麻烦，而不是什么别的废话，比如什么太极八卦、天人合一、面向xx之类的。因为怕麻烦，所以搞出设计模式这个咚咚减少麻烦。如果你发现用了设计模式更麻烦了，那么肯定是你用错了。
这个时候为了省事，我就把工厂也抽象成一个接口（因为我有两个相似的工厂，如果只有一个，我还废话什么呢），这样就成了工厂方法。
当然，既然工厂方法成了一个接口，那么当然也需要用一个工厂来创建它。这个时候，创建是三级结构，简单工厂（此时是工厂的工厂）创建工厂接口（本来是个类，现在因为进一步的抽象，成为接口了），工厂接口创建产品。
过了一段时间，随着我们的工厂业务不断发展，我们有了很多产品。
比如，我们有锤子和钉子两种产品。这两种产品都有windows品牌和linux品牌的。我们给锤子和钉子各自定义了一个创建的接口。
[code:1]interface 锤子工厂{
造锤子（）；
}
interface 钉子工厂{
造钉子();
}[/code:1]
可是，我们发现某些用户，用windows的锤子去敲linux的钉子，从而把程序敲出了bug。这当然是我们的错误，因为我们违反了一条金科玉律：
要想使你的程序稳定运行，你假设用户是猪。
所以，我们把锤子和钉子的工厂合并，让一个工厂只能造出配套的锤子和钉子，这样猪就没有犯错误的机会了。
于是我们搞出一个抽象工厂：
interface 铁匠铺{
造锤子（）；
造钉子();
}
当然，这个铁匠铺是个接口，所以同样需要用一个工厂来创建它。所以，这个时候，工厂还是三级结构。
我们的工厂，业务很多，而且产品一般都是配套使用的（这样可以多骗点钱），所以，我们大多数情况下，都是使用抽象工厂和简单工厂。简单工厂用来创建工厂，抽象工厂创建产品。
工厂的作用，就是创建接口。
其实我们不知道什么是设计模式，我们只是怕麻烦。什么是麻烦呢？
我们觉得把同样的代码写两遍就非常麻烦。所以，我们宁可多写几句，也要解决麻烦。猪不怕麻烦，可以日复一日的重复相同的事情，可是我们不是猪。