转自：http://www.cnblogs.com/mypm/archive/2011/02/09/1950130.html
目录：
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的实现中，代码少之又少
