首页 > 程序开发 > 软件开发 > 其他 >

策略模式之把会变化的部分取出并封装起来

2017-02-18

策略模式之把会变化的部分取出并封装起来:我相信大部分程序员在用Java开发的项目中只用到了一种模式:MVC,将项目分成Controller,Service,DAO三层。

策略模式之把会变化的部分取出并封装起来:我相信大部分程序员在用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接口的实现类,对已有的类不会有任何影响。

相关文章
最新文章
热点推荐