《Head First设计模式》中为何用FlyNoWay而非省略飞行行为？

• 遵循依赖倒置与接口一致性：鸭子类的核心设计是依赖FlyBehavior抽象接口而非具体实现，所有鸭子实例都得持有这个接口的实现类。要是跳过飞行行为处理，像Java这类强类型语言里，鸭子类调用fly()方法时会直接报编译错误；就算是弱类型语言，也可能出现运行时行为缺失的问题。FlyNoWay作为空实现，既满足了接口的实现要求，又让所有鸭子类保持依赖抽象的一致性，不用在鸭子类里加一堆“有没有飞行行为”的判断分支。

• 保证开闭原则与可扩展性：万一以后要给橡皮鸭加飞行能力（比如装了小马达的橡皮鸭），直接替换它的FlyBehavior实现类就行，完全不用改橡皮鸭本身的代码。如果之前没处理飞行行为，现在就得动鸭子类的结构，这就违反了“对扩展开放、对修改关闭”的设计原则。

• 明确表达行为意图：FlyNoWay的存在是在代码里明明白白说清楚“这只鸭子不会飞”，而不是让飞行行为凭空消失。其他开发者一看就懂这只鸭子的飞行特性，不会因为代码里没飞行相关逻辑而摸不着头脑，能提升代码的可读性和维护性。

• 避免运行时异常：鸭子类设计里会持有FlyBehavior的引用，要是不初始化这个引用，调用fly()方法时肯定会触发空指针异常。FlyNoWay是合法的实现类，能确保引用始终有效，调用时不会出错，同时用空操作清晰传达“没有飞行行为”的逻辑。

内容的提问来源于stack exchange，提问作者Hank