工厂模式总结

　　前面我们讲解了简单工厂模式，工厂方法模式和抽象工厂模式，这三个模式都是工厂模式。从这三种模式种，我们来谈一些理解和体会。

　　首先，工厂模式涉及到三方面人员：

　　模式设计方：设计产品的规范，工厂类的规范。

　　产品提供方：提供产品实现，工厂类实现。

　　模式使用方：直接调用工厂，获得所需产品。

　　我们在讲解工厂模式时，大都在用其标准模式在做讲解。但是在实际开发中，如果我们生搬硬套标准模式，会让我们的系统显得很笨重。所以，我们要掌握的是设计模式的核心思想，而不是它的实现方式。

　　我在曾经做的一个项目里，有一个请假模块儿，涉及到了请假流程。但是因为系统的主体不是流程类主体，所以，没有采用工作流的方式，而是通过纯代码判断审核流程，一步一步进行审核。大体需求是这样的：

　　某组织有不同的部门，部门里有不同岗位的人员。不同的部门里的不同岗位人员，请假流程都不一样，都有自己的一套请假审批流程。

　　于是，我们的开发人员在代码里，开始判断请假人员的单位和岗位类型是什么，然后根据单位和岗位，写逻辑走不同的审批流程。在一顿劈里啪啦的键盘声中，第一版的请假功能完成了。好景不长，不久后，用户需求变了，岗位类型需要调整，审批流程也需要调整，第一版的逻辑，基本全部推翻了。开发人员的心态都要崩溃。后来，我们经过分析，采用了工厂模式的思维，对代码进行改造。

　　首先，业务代码里，不再进行请假逻辑的判断，业务开发人员只需调用接口方法即可。至于请假走哪个流程，走到哪一步了，业务开发人员完全不关心。这样，无论审批流程再怎么修改，岗位类型再怎么调整，业务代码都不受影响。

　　然后，提供工厂，工厂里调度审批流程和进行到哪一步了。这里，我们采用的是简单工厂模式，因为工厂类需要绑定人员的审核流程，还需要判断进入了哪个审批环节。如果采用工厂方法或者抽象工厂模式，每多一个流程判断，就需要多一个工厂实现类，几个个流程的话，需要几十个工厂实现类，且在业务程序员调用的时候，也要在几十个类里做选择，显然这是不行的。所以，选择简单工厂模式。

　　通过描述，我们可以知道，工厂的产品就是请假。通过调用工厂，绑定请假的流程和请假的审批节点。那么，产品规范是什么呢？产品规范就是请假具体流程和流程与请假人员的映射。这个产品规范如何定义呢？我们采用的是将其写入配置文件的方式，当有新的流程加入或者原有流程改动时，改配置文件即可。工厂类中读取配置文件的流程和映射关系，进行处理。在这里我们可以看到，其实并没有什么产品抽象类和产品实现，而是定义在了配置文件中，但是其思想，就是利用了简单工厂模式的思想。

　　缺点：该应用体现了简单工厂模式的缺点，那就是开闭原则没有完全实现。当我们修改原有流程的时候，直接改配置文件里的流程即可，无需改动代码。但是当我们新增流程的时候，我们需要在工厂类中，新增逻辑，去处理新添加的流程。这就违反了开闭原则。但是综合系统整体而言，采用简单工厂模式，是最适合，改动最小的方式了。