先看各自的结构：
简单工厂模式（SimpleFactory Mode）：
Key值给返回一个相对应的算法的实体。
优点：
方便扩展算法，比如增加一个开根号的功能，我们只要继续继承运算类就行了，同时客户端也就是使用者不知道具体的实现细节，只要给出相关标示符，工厂函数就马上给他创建一个他想要的实体就行了。减少了使用者和功能开发者之间的耦合度。
缺点：
Switch，这样便破坏了OCP，而且当有多级结构继承的时候，简单工厂就会因为只能对应平行一层记得继承，不得不使得好多类继承同一个接口，然后得到A*B这么多的工厂实体可能，工厂函数很难维护。
工厂方法模式（Factory Method）：
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
优点：
switch的情况，也就不存在扩展不满足OCP的这个问题。
缺点：
PC，分为多个系统，那么我们可以把所有的系统都抽象出来（类似上面的加减乘除），然后我们在抽象出来工厂，但是如果这个时候我们有两个硬件呢，PC和Phone，虽然我们可以保证只有这两个硬件了，但是如果用基本的抽象工厂去实现的话还是很别扭。
抽象工厂模式（Abstract Factory）：
提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们具体的类。
优点：
OCP的，而且可以满足产品切换，能实现的前提是比如A和B两个产品，它们有1和2两个方法接口（类），现在我们在增加新的产品C（假设也是只有1和2两个方法接口），我们要做的只是增加一个产品类再增加一个工厂类就行了，如果是简单工厂或者是工厂方法的的话通常都是增加两个算法类C.1,C.2，简单工厂需要修改switch增加两个语句，工厂方法是在增加两个工厂类。可见抽象工厂的优点。
缺点：
显而易见，太重了。
对比：
OCP，不满足OCP的代价就是难维护，在维护的时候容易引发新的BUG，相比之下，工厂方法则是把对象的实例化延迟到了继承的子类里面，这样可以量或的扩展工厂。扩展的是时候满足OCP，但是不支持产品切换，也就是只能满足一层的产品（算法）抽象，而抽象工厂则是继续把产品进行再次抽象，最后得到一个可以支持产品切换的结构，但问题是太重了，过于复杂，不过还好，很多支持反射的语言，我们可以直接通过反射技术来优化这个“过重”的缺点。当然，也可以用反射来优化前面两个工厂结构（但是抽象工厂和工厂方法相比，两者也都只是支持一个地方的可扩展而已，不要误解为抽象工厂可以扩展两个地方）。
进化：
OCP ； 优化满足产品切换
简单工厂 ---------------------------> 工厂方法 -------------------------------->
抽象工厂
退化：
增加了和客户端之间的耦合度（客户端需要知道各种工厂）；变得太重了
简单工厂 ---------------------------> 工厂方法 -------------------------------->
抽象工厂