策略模式:把会变化的部分取出并封装起来
2016-05-06 20:21
246 查看
我相信大部分程序员在用Java开发的项目中只用到了一种模式:MVC,将项目分成Controller,Service,DAO三层。无论多复杂的业务逻辑都塞进Service层的方法,其结果是造成Service层的方法臃肿无比,里面充满了各种if、switch逻辑判断的分支。时间一长,连开发者自己都忘了在方法里做了什么事。当业务逻辑发生变化时,动手改这块的代码成了一件十分困难,极易出错的事。
不幸的很,业务逻辑是整个项目中变化最频繁的部分,因此我强烈建议将Service层再拆分,举个我在实际项目中遇到的电信产品销售的例子:
电信产品有宽带、号码、话费、流量等很多种,很显然,销售每种产品的业务逻辑是不一样的,比如销售宽带产品时需记录客户的家庭地址、预约上门安装时间;销售话费只需记录客户充值的手机号码等等。且业务逻辑经常会发生变化(经常进行促销活动),这种情况非常适合用策略模式来设计,我就是用策略模式来处理这类问题的。请看图:
ProductService是一个抽象类,代表所有可销售产品的Service,它其中包括一个SellBehavior成员,SellBehavior接口封装产品销售的业务逻辑,例如它的一个实现类SellBroadband是宽带产品销售的业务逻辑。
BroadbandService继承ProductService,是宽带产品的Service,在创建时给sellBehavior成员装配SellBroadband类。
可以看出宽带产品销售的业务逻辑封装在SellBroadband的sell方法里,而其它产品,例如话费销售的业务逻辑封装在SellTelephoneFare的sell方法里。这样使得不同产品的销售方法各自独立不互相影响,业务逻辑清晰易于改变,当需要增加新的产品时,只需增加一个SellBehavior接口的实现类,对已有的类不会有任何影响。
不幸的很,业务逻辑是整个项目中变化最频繁的部分,因此我强烈建议将Service层再拆分,举个我在实际项目中遇到的电信产品销售的例子:
电信产品有宽带、号码、话费、流量等很多种,很显然,销售每种产品的业务逻辑是不一样的,比如销售宽带产品时需记录客户的家庭地址、预约上门安装时间;销售话费只需记录客户充值的手机号码等等。且业务逻辑经常会发生变化(经常进行促销活动),这种情况非常适合用策略模式来设计,我就是用策略模式来处理这类问题的。请看图:
ProductService是一个抽象类,代表所有可销售产品的Service,它其中包括一个SellBehavior成员,SellBehavior接口封装产品销售的业务逻辑,例如它的一个实现类SellBroadband是宽带产品销售的业务逻辑。
BroadbandService继承ProductService,是宽带产品的Service,在创建时给sellBehavior成员装配SellBroadband类。
可以看出宽带产品销售的业务逻辑封装在SellBroadband的sell方法里,而其它产品,例如话费销售的业务逻辑封装在SellTelephoneFare的sell方法里。这样使得不同产品的销售方法各自独立不互相影响,业务逻辑清晰易于改变,当需要增加新的产品时,只需增加一个SellBehavior接口的实现类,对已有的类不会有任何影响。
相关文章推荐
- hdu 5172(RMQ+前缀和)
- Rebase
- 堆排序
- HDU 2102 A计划 (搜索 队列)
- 金蝶软件校园招聘Java开发工程师笔试面试情况分享
- 多线程与线程池总结
- 保存特殊字符到utf8编码的mysql数据库中
- 网络的可靠性
- Eclipse AST 实现一个类信息统计小程序
- linux基础操作
- NYOJ 三点顺序--68
- C经典 函数指针的三种使用方式
- Android studio和eclipse获取当前版本号
- 外部函数(计算圆面积)
- (学习进度表)【第九周】
- 简要描述一下Hadoop, Spark, MPI三种计算框架的特点以及分别适用于什么样的场景
- 数据库(SQLite)
- CentOS6.5服务器端口捆绑
- Hadoop之多行读取数据
- LeetCode-91.Decode Ways