《设计模式》读书笔记:策略模式

《设计模式》我从头开始看了好几遍,老是因为这事那事打断,还是通过写博客来强迫自己读完吧.

第一章就是策略模式(Strategy).

最开始的时候,Joy上班的公司,设计了一个模拟鸭子的游戏:SimUDuck.游戏中会有各种各样的鸭子.

首先,基于面向对象的想法,在该游戏中,设计了一个鸭子的超类Duck.

Duck拥有quack(),swim(),display()三个成员函数,而其子类则自己重写display来实现不同的显示,这是很普通的继承的使用.

在公司的业务进入到一个新阶段,现在需要给鸭子添加上fly()的功能,于是,Joy在超类Duck中添加上了fly()方法.

这个时候,问题出现了,除了野鸭,红头鸭这些子类正常地飞了起来,现在连澡堂里的橡皮玩具鸭也飞起来了.

为了修正这个错误,Joy只好在RubberDuck(橡皮鸭)中重写了fly方法,将其实现为一个空函数,这样,橡皮鸭子就不能飞了.

这个时候,老板提出再添加一个诱饵鸭(就是个靶子)的需求,诱饵鸭不会飞,也不会叫,似乎重写fly()和quack()方法,就解决了这个问题.

但是,随着需求越来越多,每个子类的行为方式不同,,难道都需要子类重写?无非会造成更多的重复代码.对于程序员来说,添加这种代码,也是极其无聊的.

这个时候,Joy提出了一种想法.

他将fly()从超类中取出来,放进一个Flyable的接口(interface),将quack()放进Quackable接口.

其实,这样做,并没有改善上面使用继承而产生的问题,对于每种有某个行为的鸭子,你都需要去实现接口中的方法.很显然,其中的代码也无法重用.

至此,问题的需要回到面向对象的软件设计原则上:找出可能需要变化的之处,把它们独立出来,不要将其和那些不需要变化的代码混在一起.

从上面例子中,我们知道Duck中quack()和fly()方法会随着鸭子的不同而有不同的实现.我们将它们从Duck中独立出来,并创建新的FlyBehavior和QuackBehavior类来表示这两个行为.

FlyBehavior拥有一个fly()的方法.

针对不同的fly()实现,我们创建了FlyBehavior的子类:FlyWithWings和FlyNoWay.并重写其各自的fly()方法.

此外,在Duck超类中加入FlyBehavior flyBehavior,QuackBehaviorquackBehavior两个类成员,和perfomFly(),performQuack()两个方法.

这样改动之后,对于所有通过翅膀能飞的鸭子,flayBehavior指向一个FlyWithWings对象,所有不能飞的鸭子,flayBehavior指向一个FlyNoWay对象.在通过performFly调用flyBehavior成员的fly()方法,就能很方便的实现其行为.

同时,这样的改动,还能在运行时改变的鸭子对象的行为.

"有一个"可能比"是一个"更好.