在Head First Design Patterns中，它通过使用Duck示例讲授策略模式，其中可以在运行时为Duck的不同子类分配特定的行为。根据我的理解，策略模式的目的是在运行时更改单个对象的行为，但是他们使用Duck的继承来更改各种Duck的行为。
Duck的上下文继承是否与策略模式无关，或者是改变Duck类型并改变其行为也是采用策略模式的充分理由吗？您需要同时改变两者的情况是否构成使用策略模式的充分理由？他们为何将其作为策略模式示例？
我是否可以仅使用Duck类（没有派生类）来进一步简化此示例？然后，在实现一个鸭子对象时，可以根据不依赖于其自身对象类型的某些情况为其分配不同的行为。例如：FlyBehavior根据天气而变化或QuackBehavior根据一天中的时间或鸭子的饥饿程度而变化。我意识到这将解决与书中提出的问题不同的问题，但是我正在寻找的是可以依靠的相关策略模式示例。
我上面的例子也会构成战略模式吗？
我成功找到了两个更简单的策略模式示例，它们更严格地只是没有上下文继承的策略模式：Hunter.java和Solver.py。
Answers:
是的，我认为您的做法正确。使用策略模式的类不必是子类。战略模式是代码重用的继承的替代方法。这回到了继承与构成的更广泛的比较。
从设计模式：可重用的OOP元素中，您将使用策略模式来
如果使用继承来实现Quack和Fly行为，则所有这些子类都将代表行为的所有组合。
子类太多了，很难维护，这就是为什么在这种情况下偏爱策略模式的原因。您只需要封装Flyability和Quackability的两个属性，就可以在不创建新类的情况下对其进行混合和匹配。
您还已经提到了运行时的好处，即由于天气原因，如果天气变化，鸭子的Fly属性可以替换为NoFly对象。
这与在可能的情况下偏向于继承而非继承的建议相一致。
我是否可以仅使用Duck类（没有派生类）来进一步简化此示例？然后，在实现一个鸭子对象时，可以根据不依赖于其自身对象类型的某些情况为其分配不同的行为。
当然。为了获得灵感，请看《面向对象的分析与设计》。有一个“里克的吉他”，展示了（乐器）乐器子类的爆炸式增长。为了解决所有这些问题，将变化的行为包装在“规范”类中，并遵守封装变化的原理。
抽象工厂-基于上下文的构造
这是模式。顺便说一句，请注意它使用策略本身。
关注概念而不是实现...您可能有一个“ WeatherFactory”，它根据晴天或多雨等条件构建规范对象。
您可以拥有“工厂工厂”来构建那些“ NoFlyInFogQuackableMallard”事物。的确，这就是抽象工厂模式的含义。因此，也许是一个DuckFactory来创建一般的鸭子类型，然后是一个WeatherFactory来给它提供特定于鸭子类型的有雾天气行为。