类图
为什么要将飞行和呱呱叫行为算法提取出来?
这些行为是容易变化的，将它们提取出来后续行为的具体实现方式发生变化不会对duck类产生任何影响，只需要修改具体行为实现类自身的逻辑。（即为封装变化）
很多鸭子类型其实并不需要飞行，如橡皮鸭，死鸭子等，如果将飞行和叫行为放在duck父类中，所有的duck实现类都必须实现该方法，不需要该方法行为的鸭子在实现时就只能override该方法后空着不实现具体逻辑，这样会导致产生很多重复无用代码。将这两种行为作为duck的类变量，所有的飞行和呱呱叫都会委托具体行为去执行，则可以清除这些无用代码。（个人另外看法，对于无用代码来说，可以把fly和quack方法座位duck类的普通方法，不要定义为抽象方法就可以了，不需要实现该方法的鸭子不要重写该方法就好了）(组合代替继承)
<b>个人看来最最最重要的一点，也是策略模式的核心功能：运行时可动态改变行为策略</b>，通过duck类暴露setter方法的方式，调用方可随时根据需求更换duck类的行为策略，这也是在我看来<b>策略模式跟模版方法模式最大最大的区别</b>
策略模式在实际开发中的应用
首先，我在百度上搜到了好多展示自己如何运用策略模式重构自己代码的例子，看完都发现其实完全不是那么回事，大多数案例都是以if else或者switch case这种代码为切入点，说根据策略模式可以去掉这些难看的层层判断，他们基本采用的方式是维护了一个map，客户端调用时通过map找到对应的策略，然后执行策略方法....从本质上看这和if else没有任何本质的区别吧，只是把判断具体用哪个策略的方法从if else改善成用map查找了而已。
个人觉得策略模式要想用好，必须反映出运行时动态改变策略的能力。不然即使使用了策略模式，也就是模版方法模式的变种而已!!!
另外，关于运行时动态改变策略，应该是每一次改变是全局性的改变，只要改变了之后这个context类在下一次被修改策略前都要保持以现在的策略响应请求。(就是说改变不是临时改变,。。。不知道怎么形容)
在非单机的环境中，策略模式可能需要依靠消息中间件同步各服务器同时响应策略修改，在分布式web开发中，策略模式使用场景目前我狭隘的眼光看来还比较难用上，稍微可以想到的可能是一些容灾方案上面的，全局的策略变更也必须通过消息中间件或者分布式数据库缓存等来实现，且要考虑一些容灾逻辑。
下面是自己想到的一些可以运营策略模式的场景：
- head first中提到的游戏中更换游戏角色的武器
- 实时翻译程序中点击切换语言按钮时更换翻译策略
