大话设计模式之工厂模式(factory pattern)

 很多关于设计模式的书里都会提及工厂模式，大致分为简单工厂模式、方法工厂模式和抽象工厂模式，第三种是我最想吐槽的，名字足够具体同时也足够晦涩，记得大学有本叫马克思主义哲学的书里有个词叫形而上学，我一直就没搞明白过，直到很久以后机缘巧合下才真的理解，无非就是对辩证法取反而已，这些搞理论的前辈们总是喜欢故作高深，其实虎头蛇尾。

同理，对工厂模式的理解也不能局限于概念，之前在知乎上读过一篇文章，我觉得解释得比较到位：工厂模式的本质就是对获取对象过程的抽象。

       如何理解这句话呢？一个系统想要运转起来一定会涉及到很多对象的实例化，如果这个过程分散在各个业务逻辑之中，那么整个系统的可维护性、可扩展性都会比较差，这也违背了软件设计的开闭原则。所以为了解决这个问题，就可以将创建对象这个过程单独抽离，这样的方式就是工厂，所以工厂要解决的问题就是：希望创建一个对象，但创建过程比较复杂，想要对外影藏这些细节。

简单工厂模式

该模式其实是实现对象管理最简单的方式，只实现了对不通类型对象的简易封装，工厂对外提供一个类型，便于向client端返回指定的对象。

方法工厂模式（Factory Method）

方法工厂模式是对简单工厂模式的升级，简单工厂模式是将对象的生产过程集中在一起，其实这样带来的问题是显而易见的，当类型过多时，整个工厂就会变得很错乱，代码健壮性和可维护性极差。所以工厂方法模式将生产对象的过程下沉到具体的产品工厂，即每种类型都有属于自己的工厂，当用户想要新增类型时，新增一个工厂即可，与原工厂无关。

抽象工厂模式

以上两种都是针对同一种产品，即不同的工厂生产同一类产品，一个很简单的业务场景：小米和苹果公司，都生产手机。当业务场景升级以后：即产品类型逐渐增多，小米和苹果公司都同时生产手机和iPad以及PC电脑。这个时候方法工厂模式以同样的方式copy一遍同样也可以实现，但系统过于冗余且不够优雅。抽象工厂模式就应运而生了。

UML图

工厂-产品关系图