Joe面对的问题是：鸭子的行为在子类里持续不断的改变，每次升级增加新的子类，不同的子类都要重写积累中这些变化的行为，
麻烦并且混乱，所以让所有的子类都拥有基类的行为是不合适的；而使用文章中接口的方式，当有多个子类时，接口中任何一个方法的改变，
必须重复修改所有子类中的方法，又破坏了代码的重用。
软件开发过程中恒定不变的 是变化本身，所以直面“变化这个事实”才是正道。
第一个设计原则：Identify the aspects of your application that vary and separate them from what stays the same.(找到系统中变化的部分，将变化的部分同其它稳定的部分隔开)。也即：把变化的部分找出来并封装起来，以便以后可以轻易地改动或者扩展此部分，而不影响其他变化的部分。这样，代码变化引起的不经意后果减少，系统变得更具有弹性。
第二个设计原则：Program to an interface, not an implementation.（面向接口编程，而不要面向实现编程。）在本例中，也即提用两个接口代表每个行为，而行为的每个实现（行为类），都将实现对应的接口。
这与我们以前的做法不同，以前的做法是：行为来自超类的具体实现，或是继承某个接口并由子类自行实现。这两种方法都依赖于“实现”。我们现在的做法是：鸭子的子类将使用接口所表示的行为，所以实际的“实现”不会被绑死在鸭子的子类里。
Strategy Class Diagram
Context(应用上下文):
需要使用ConcreteStrategy提供的算法。
内部维护一个Strategy的实例。
负责动态设置运行时Strategy具体的实现算法。
负责跟Strategy之间的交互和数据传递。
Strategy(抽象策略类)：
定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。
ConcreteStrategy(具体策略类)：
实现了Strategy定义的接口，提供具体的算法实现。
应用场景：
多个类只有在算法或者行为上稍有不同（多个ConcreteStrategy）
算法需要自由切换的场景，或者未来还可以扩展新的算法或行为
需要屏蔽算法规则的场景，例如，Duck与具体的算法完全独立
模式优点：
提供了一种替代继承的方法，而且既保持了继承的优点(代码重用)还比继承更灵活(算法独立，可以任意扩展)。
避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。
模式缺点：
策略类数量会增多
策略类均对外暴露