工厂模式总结
前面我们讲解了简单工厂模式,工厂方法模式和抽象工厂模式,这三个模式都是工厂模式。从这三种模式种,我们来谈一些理解和体会。
首先,工厂模式涉及到三方面人员:
模式设计方:设计产品的规范,工厂类的规范。
产品提供方:提供产品实现,工厂类实现。
模式使用方:直接调用工厂,获得所需产品。
我们在讲解工厂模式时,大都在用其标准模式在做讲解。但是在实际开发中,如果我们生搬硬套标准模式,会让我们的系统显得很笨重。所以,我们要掌握的是设计模式的核心思想,而不是它的实现方式。
我在曾经做的一个项目里,有一个请假模块儿,涉及到了请假流程。但是因为系统的主体不是流程类主体,所以,没有采用工作流的方式,而是通过纯代码判断审核流程,一步一步进行审核。大体需求是这样的:
某组织有不同的部门,部门里有不同岗位的人员。不同的部门里的不同岗位人员,请假流程都不一样,都有自己的一套请假审批流程。
于是,我们的开发人员在代码里,开始判断请假人员的单位和岗位类型是什么,然后根据单位和岗位,写逻辑走不同的审批流程。在一顿劈里啪啦的键盘声中,第一版的请假功能完成了。好景不长,不久后,用户需求变了,岗位类型需要调整,审批流程也需要调整,第一版的逻辑,基本全部推翻了。开发人员的心态都要崩溃。后来,我们经过分析,采用了工厂模式的思维,对代码进行改造。
首先,业务代码里,不再进行请假逻辑的判断,业务开发人员只需调用接口方法即可。至于请假走哪个流程,走到哪一步了,业务开发人员完全不关心。这样,无论审批流程再怎么修改,岗位类型再怎么调整,业务代码都不受影响。
然后,提供工厂,工厂里调度审批流程和进行到哪一步了。这里,我们采用的是简单工厂模式,因为工厂类需要绑定人员的审核流程,还需要判断进入了哪个审批环节。如果采用工厂方法或者抽象工厂模式,每多一个流程判断,就需要多一个工厂实现类,几个个流程的话,需要几十个工厂实现类,且在业务程序员调用的时候,也要在几十个类里做选择,显然这是不行的。所以,选择简单工厂模式。
通过描述,我们可以知道,工厂的产品就是请假。通过调用工厂,绑定请假的流程和请假的审批节点。那么,产品规范是什么呢?产品规范就是请假具体流程和流程与请假人员的映射。这个产品规范如何定义呢?我们采用的是将其写入配置文件的方式,当有新的流程加入或者原有流程改动时,改配置文件即可。工厂类中读取配置文件的流程和映射关系,进行处理。在这里我们可以看到,其实并没有什么产品抽象类和产品实现,而是定义在了配置文件中,但是其思想,就是利用了简单工厂模式的思想。
缺点:该应用体现了简单工厂模式的缺点,那就是开闭原则没有完全实现。当我们修改原有流程的时候,直接改配置文件里的流程即可,无需改动代码。但是当我们新增流程的时候,我们需要在工厂类中,新增逻辑,去处理新添加的流程。这就违反了开闭原则。但是综合系统整体而言,采用简单工厂模式,是最适合,改动最小的方式了。