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

我相信大部分程序员在用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接口的实现类，对已有的类不会有任何影响。