简单工厂模式、工厂方法模式、抽象工厂模式之间的对比

男娘i 2022-05-28 12:19 141阅读 0赞

# 简单工厂模式、工厂方法模式、抽象工厂模式 之间的对比 #

原创  2016年06月23日 20:10:45

*  2038

先看各自的结构：

简单工厂模式（SimpleFactory Mode）：

简单工厂模式的思路是，首先我们把一些共性的东西（算法）拿出来，进行抽象，比如加减乘除。然后我们在定义一个类作为工厂类，工厂类的作用就是根据传过来的字符串或者其他Key值给返回一个相对应的算法的实体。

![Center][]

优点：

方便扩展算法，比如增加一个开根号的功能，我们只要继续继承运算类就行了，同时客户端也就是使用者不知道具体的实现细节，只要给出相关标示符，工厂函数就马上给他创建一个他想要的实体就行了。减少了使用者和功能开发者之间的耦合度。

缺点：

比较明显，在进行扩展的时候，我们要更改工厂函数里面的那个分支语句Switch，这样便破坏了OCP，而且当有多级结构继承的时候，简单工厂就会因为只能对应平行一层记得继承，不得不使得好多类继承同一个接口，然后得到A\*B这么多的工厂实体可能，工厂函数很难维护。

工厂方法模式（Factory Method）：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

![Center 1][]

优点：

算法实体的创建被延迟到了工厂子类里，我们不在工厂里直接创建对象，而是直接封装一个一个的小工厂，每个工厂负责创建自己的子类，这样就不存在switch的情况，也就不存在扩展不满足OCP的这个问题。

缺点：

如果算法种类很多，那么继承抽象工厂的子类也就会很多，不是很好维护，同时不支持产品切换，比如我们要开发PC，分为多个系统，那么我们可以把所有的系统都抽象出来（类似上面的加减乘除），然后我们在抽象出来工厂，但是如果这个时候我们有两个硬件呢，PC和Phone，虽然我们可以保证只有这两个硬件了，但是如果用基本的抽象工厂去实现的话还是很别扭。

抽象工厂模式（Abstract Factory）：

提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们具体的类。

![Center 2][]

优点：

首先是满足OCP的，而且可以满足产品切换，能实现的前提是比如A和B两个产品，它们有1和2两个方法接口（类），现在我们在增加新的产品C（假设也是只有1和2两个方法接口），我们要做的只是增加一个产品类再增加一个工厂类就行了，如果是简单工厂或者是工厂方法的的话通常都是增加两个算法类C.1,C.2，简单工厂需要修改switch增加两个语句，工厂方法是在增加两个工厂类。可见抽象工厂的优点。

缺点：

显而易见，太重了。

对比：

简单工厂实现简单，扩展也很容易，但是不满足OCP，不满足OCP的代价就是难维护，在维护的时候容易引发新的BUG，相比之下，工厂方法则是把对象的实例化延迟到了继承的子类里面，这样可以量或的扩展工厂。扩展的是时候满足OCP，但是不支持产品切换，也就是只能满足一层的产品（算法）抽象，而抽象工厂则是继续把产品进行再次抽象，最后得到一个可以支持产品切换的结构，但问题是太重了，过于复杂，不过还好，很多支持反射的语言，我们可以直接通过反射技术来优化这个“过重”的缺点。当然，也可以用反射来优化前面两个工厂结构（但是抽象工厂和工厂方法相比，两者也都只是支持一个地方的可扩展而已，不要误解为抽象工厂可以扩展两个地方）。

进化：

优化满足OCP        ；        优化满足产品切换

简单工厂 \--------------------------->  工厂方法  \--------------------------------> 抽象工厂

退化：

增加了和客户端之间的耦合度（客户端需要知道各种工厂）；变得太重了

简单工厂 \--------------------------->  工厂方法  \--------------------------------> 抽象工厂

[Center]: /images/20220528/6ad01caaacd24a7c8a6d233a75fd74e6.png
[Center 1]: /images/20220528/8be43ac4501c497d8f671147043f9d4c.png
[Center 2]: /images/20220528/b27e048bfb9f4d10a8c120e16f3ce2e8.png