策略模式

一）先聊聊那只鸭子
大家还记得F4写的那本《设计模式》么。那里的第一章介绍的便是策略模式。那个会飞的鸭子可谓是说明策略模式的经典。深入浅出的阐述了策略模式的使用场景和使用方法。这里我不过是再简略的介绍下书里的策略模式，在最后加上的点个人实践中对此模式的感悟罢了。

二）何为策略模式
先来看看不用策略模式时候的代码：

[img]http://dl.iteye.com/upload/attachment/0062/6546/897c9a66-0f9c-3a25-92e2-c0ba0bb27e6f.png[/img]

这样做的缺点有：
1 代码在子类中多有重复。那些没有fly()行为的子类，必须显示的置空fly(){}
2 改变牵一发而动全身。假设要增加dance()行为，所以的子类都有改变。

所以，来看看策略模式是怎么做的：


[img]http://dl.iteye.com/upload/attachment/0062/6548/18834c57-f60f-3574-9b4f-a37854157a82.png[/img]


[img]http://dl.iteye.com/upload/attachment/0062/6550/9c5efa0f-d2cc-3fcd-a6cd-d472e3310b22.png[/img]


[img]http://dl.iteye.com/upload/attachment/0062/6552/71826d7d-fa39-3274-955d-219170cc7f1b.png[/img]

它将变化无穷的fly属性剥离出来，单独作为一类对象处理。利用interface提高其代码的灵活性。同样，以后如果有dance,quack 等变化多端的行为时，都可以在duck类中新“有”一个接口类型。这样的策略面对需求的改变可以使代码的变动做到最小。

三）策略模式的使用
学会策略模式并不难，但要用好它，掌握其精髓却也并非易事。本人就曾遇到一个使用策略模式的项目，但其将“变化”剥离的策略导致了interface种类繁多，而每个interface下却都只有一个实现类。每次遇到新需求的变更往往还是需要新增一种interface,然后在这interface下新增唯一的一个实现类来解决。面对这样的结果，策略模式更像是一种累赘了。
而以我自己的经验，使用策略模式有两点可能比较重要：
1 [b]是否需要使用策略模式。[/b]无可否认，策略模式的灵活性无论如何都要优于普通的继承。但这种灵活的代价是代码的结构更加复杂，易读性降低。所以，在比较确定不太会改变的简单的逻辑代码面前，先使用一般的继承方式倒未尝不可。如果以后真的“很不幸”需要改变，我们还有重构么，是吧。
2 [b]仔细推敲剥离“变化”的策略。[/b] 即，按什么规则逻辑去设定分类那些interface。这一点非常重要。你对“变化”如何理解决定了你采用何种策略划分，划分的优劣决定了后期interface的简易程度。而且策略制定的时间越长，越难以再纠正，所以在设计伊始一定要谨慎推敲。一般而言，这些“变化”都会是动词。
以上是一些个人的感悟，班门弄斧，还请各位高手不吝赐教~~