IOC和工厂模式联合使用简化工厂模式

目录：

1：应用场景

2：传统工厂模式

3：传统工厂模式实现1中应用场景的弊端

4：IOC和工厂模式连合使用实现1中描述的场景

1：应用场景

    在MYPM的工作流业务中，有三种业务对像可以走工作流，分别为：文档，项目和工作任务；这三种业务对像在走工作流时，具体处理业务是有差别的，工作流引擎要根据不同的业务对像(文档，项目和工作任务)，调用不同的处理器.

2：传统工厂模式

（1）简单工厂模式

用法：客户端利用SimpleFactory产生一个具体产品（用AbstractProduct引用），当然这需要客户端传参，但判断逻辑位于SimpleFactory中（如switch语句）。

扩展：若需要增加具体产品E，则须添加ConcreteProductE类，同时修改SimpleFactory。

修改：若需要修改具体产品A，则只需修改ConcreteProductA类。

（2）工厂方法模式

用法：客户端根据需要的产品选择工厂（实例化具体工厂A，用AbstractFactory引用），再用该工厂制造产品（用AbstractProduct引用）。

扩展：若需要增加具体产品E，则须添加ConcreteProductE类和ConcreteFactoryE。

修改：直接修改相应产品。

（3）抽象方法模式

用法：客户端根据需要的产品选择工厂（实例化具体工厂A，用AbstractFactory引用），再用该工厂制造产品（用AbstractProduct引用）。相比而言，抽象工厂模式的好处是易于转换产品的系列（如由A系列转换为B系列）。

扩展：若需要增加产品3A和3B，则除了要增加3个类外还要修改FactoryA和FactoryB。若需要增加产品系列C，除了增加相应的类外，还要增加FactoryC类。

修改：直接修改相应的类。

3：传统工厂模式实现1中应用场景的弊端

应用场景

  在MYPM的工作流业务中，有三种业务对像可以走工作流，分别为：文档，项目和工作任务；这三种业务对像在走工作流时，具体处理业务是有差别的，工作流引擎要根据不同的业务对像(文档，项目和工作任务)，调用不同的处理器.

    在1中所描述场景，用简单工厂模式实现代码中会有很多if else 或是switch语句；用工厂方法模式或抽象方法模式实现时，会增加类。且看下面IOC和工厂模式连合使用后三种工厂模式（简单工厂模式、工厂方法模式、抽象方法模式）合并成简单工厂模式使用且代码中无任何if else 或是switch语句

4：IOC和工厂模式连合使用业实现1中描述的场景

     思路其实很简单:

    在工厂中持有一map（通过IOC注入），key 为简单工厂中要传入的参数，value为实现了处理器接口   WorkFlowTaskHandler的具体实现。取出具体的“产品”，即场景中的处理器

  在工作流引擎中中调用方式如下

//getHanerByTask 方法中传入要处理的工作流任务类型

WorkFlowTaskHandler handler = taskHandlerFactory.getHanerByTask(dto.getTask().getTaskType());

getHanerByTask方法中，根本不用else if 判断 因为dto.getTask().getTaskType() 的值一定是map中某个key，因为有这个约定：
map 的key 0,1,2, KEY本身就作为表示业务对像类型的值 如果再加入一个业务对像，其类型值为5 那map中再注放一个key为5 value 为实现处理器接口的bean

//handleWfTask为处理器接口WorkFlowTaskHandler中定义的接口

handler.handleWfTask(dto);

下面请看具体实现

4.1 先看IOC配置，如下图所示taskHandlerFactory中持有workFlowHanderHold，workFlowHanderHold就是一个map

workFlowHanderHold中注入了 三个处理器，如有必要还可以继续注入实现了WorkFlowTaskHandler接口的任意类

    4.2 工厂类，所下两图所示，TaskHandlerFactoryImpl的实现中，代码少之又少