鸭子-策略模式.docVIP

鸭子-策略模式（Strategy） 前言 万事开头难，最近对这句话体会深刻！这篇文章是这个系列正式开始介绍设计模式的第一篇，所以肩负着确定这个系列风格的历史重任，它在我脑袋里默默地酝酿了好多天，却只搜刮出了一点儿不太清晰的轮廓，可是时间不等人，以后再多“迭代”几次吧！在前面的随笔里，我已经提到了，这个系列准备以《Head First Design Patterns》的结构为主线，所以每个模式的核心故事都是取材于此书，在此再次声明一下。不管怎样，宗旨是为了跟大家一起循序渐进地去认识设计模式。 上一篇：模式和原则，得到很多朋友的支持和鼓励，这里再次深表感谢。这里我还是想呼吁一下，希望大家看过后多提宝贵意见，反对意见更好，关键是我们在互动中可以共同进步，因为经验告诉我讨论(争论更甚)出来的火花，总是印象最深刻的。 其实策略模式是一个很简单的模式，也是一个很常用的模式，可谓短小精悍。我在介绍这个模式的同时，为了加深大家对OO的理解，还会反复强调前面讲过的设计原则和GRASP模式。这个系列的文章前后多少会有一些关联的连续性，但是单独一篇文章针对单一模式也一定是独立的，所以不论大家想从前往后连续看也好，还是挑喜欢的跳着看，都没有问题。 “罗嗦了这么多，太唐僧了吧，快点开始吧…”(烂西红柿和臭鸡蛋从四面八方飞来) 模拟鸭子 Joe是一名OO程序员，他为一家开发模拟鸭子池塘游戏的公司工作，该公司的主要产品是一种可以模拟展示多种会游泳和呷呷叫的鸭子的游戏。这个游戏是使用标准的面向对象技术开发的，系统里所有鸭子都继承于Duck基类,系统的核心类图如下： 如图所示，在Duck基类里实现了公共的quack()和swim()方法，而MallardDuck和RedheadDuck可以分别覆盖实现自己的display()方法，这样即重用了公共的部分，又支持不同子类的个性化扩展。从目前的情况看，这是一个很好的设计，哈！?? 但是，商场如战场，不进则退。Joe的公司最近的日子不好过，盗版泛滥，再加上竞争对手的围追堵劫，已经拖欠好几个月工资了。因此，公司高层在一次集体“腐败”后，决定一定要给系统增加一些超玄的功能，以彻底击垮竞争对手。经过董事会讨论，最终觉得如果能让鸭子飞起来，那么一定可以给对手致命一击。于是Joe的上司对董事们拍着胸脯说：“这没有问题，Joe是一个OO程序员，这对他来说太简单了！我们保证一周内结束战斗。” 接到任务的Joe丝毫不敢怠慢，研究了上级的指示以后，发现只要在Duck里增加一个fly()方法就可以搞定了，这样所有继承Duck的鸭子就都拥有了会飞的能力，哈！这回奖金有盼头啦！改进后的系统类图如下： ??? Joe的上司很高兴，带着新产品给董事们演示去了……?? …… Joe的上司：“我正在给董事们演示你会飞的鸭子，但是怎么有很多橡皮鸭子也在四处乱飞呢？你在耍我吗？你还想不想混啦？！”(此处省略粗话100字) Joe被吓坏了，到手的奖金泡汤了！冷静下来的Joe发现，原来在Duck类里增加的方法，也同样被继承于Duck的RubberDuck类继承了，所以就有了会飞的橡皮鸭子，这是严重违反该系统“真实模拟各种鸭子”的原则的！那么该怎么办呢？Joe很郁闷！他突然想到：如果在RubberDuck类里把fly()方法重写一下会如何？在RubberDuck类的fly()里让橡皮鸭子什么都不做，不就一切OK了吗！那以后再增加一个木头鸭子呢？它不会飞也不会叫，那不是要再重写quack()和fly()方法，以后再增加其它特殊的鸭子都要这样，这不是太麻烦了，而且也很混乱。 最终，Joe认识到使用继承不是办法，因为他的上司通知他，董事会决定以后每6个月就会升级一次系统，以应对市场竞争，所以未来的变化会很频繁，而且还不可预知。如果以后靠逐个类去判断是否重写了quack()或fly()方法来应对变化，显然混不下去！ （Joe这时很迷惑，为什么屡试不爽的继承，在系统维护升级的时候，无法很好地支持重用呢？） 那么使用接口怎么样？我可以把fly()方法放在接口里，只有那些会飞的鸭子才需要实现这个接口，最好把quack()方法也拿出来放到一个接口里，因为有些鸭子是不会叫的。就像下面这样： Joe的上司知道后怒了：“你这样做难道是希望所有需要quack()和fly()方法的鸭子都去重复实现这两个方法的功能吗？就这么几个鸭子还好说，但是我们有几十、上百个鸭子的时候你怎么办？如果某个方法要做一点修改，难道你要重复修改上百遍吗？你是不是疯啦？” 呵呵！如果你是Joe，你该怎么办？ 我们知道，并不是所有的鸭子都会飞、会叫，所以继承不是正确的方法。但是虽然上面的使用Flyable接口的方法，可以解决部分问题(不再有会飞的橡皮鸭子)，但是这个解决方案却彻底破坏了重用，它带来了另