精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
---|---|
作者 | 正文 |
发表时间:2011-02-10
最后修改:2011-02-11
内容来源于本人博客园博客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 为简单工厂中要传入的参数(KEY本身就作为表示业务对像类型的值),value为实现了处理器接口 WorkFlowTaskHandler的具体实现。取出具体的“产品”,即场景中的处理器 在工作流引擎中中调用方式如下 //getHanerByTask 方法中传入要处理的工作流任务类型 WorkFlowTaskHandler handler = taskHandlerFactory.getHanerByTask(dto.getTask().getTaskType()); //handleWfTask为处理器接口WorkFlowTaskHandler中定义的接口 handler.handleWfTask(dto); 下面请看具体实现 4.1 先看IOC配置,如下图所示taskHandlerFactory中持有workFlowHanderHold,workFlowHanderHold就是一个map workFlowHanderHold中注入了 三个处理器,如有必要还可以继续注入实现了WorkFlowTaskHandler接口的任意类 4.2 工厂类,所下两图所示,TaskHandlerFactoryImpl的实现中,代码少之又少 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-02-11
感觉你使问题复杂化了,既然已经使用spring了,handler的命名也符合一定的规范,为什么不直接通过一种规范简化掉这些东西,我觉得使用0,1,2再封装到一个map里面去不太靠谱,因为你在代码里面取的时候还要判断0,1,2分别代表那种类型。
|
|
返回顶楼 | |
发表时间:2011-02-11
最后修改:2011-02-11
你看最后一个图,我在代码中根本没有else if 或是swich 来判断了,getHanerByTask方法中,根本不用在判断 因为dto.getTask().getTaskType() 的值一定是map中某个key,因为有这个约定:
map 的key 0,1,2, KEY本身就作为表示业务对像类型的值 如果再加入一个业务对像,其类型值为5 那map中再注放一个key为5 value 为实现处理器接口的bean 下面是从工厂中取handler WorkFlowTaskHandler handler = taskHandlerFactory.getHanerByTask(dto.getTask().getTaskType()); |
|
返回顶楼 | |
发表时间:2011-02-12
其实这样做是把if else或switch的判断逻辑用Map来取代了。 事先在Map中约定好类型和对应的工厂类。运行时通过类型码(0,1,2)来找到相应的Handler。
你这里把Spring搬上来,最主要的作用就是在Map中定义了这个约定关系。一定程度上,还是达到了简化的目的。 |
|
返回顶楼 | |
发表时间:2011-02-18
楼主贴的都是图片,我按照思路实现了一遍,发现楼主做了很多重复工作,Spring本身就是一个工厂,配置文件已经是MAP的形式了。能根据bean id 拿到对应的实例
|
|
返回顶楼 | |
发表时间:2011-02-18
zq3062211015 写道 楼主贴的都是图片,我按照思路实现了一遍,发现楼主做了很多重复工作,Spring本身就是一个工厂,配置文件已经是MAP的形式了。能根据bean id 拿到对应的实例
好学生。 |
|
返回顶楼 | |
发表时间:2011-03-02
过度设计了
|
|
返回顶楼 | |
浏览 8971 次