《Head First设计模式》中单方法Java接口的使用合理性及场景疑问

首先明确：《Head First设计模式》两个章节的表述不存在矛盾，作者反对的不是「单方法接口」本身，而是没有实际多态价值、仅为了强制实现方法引入的冗余单方法接口，两种场景的核心差异如下：

Strategy模式章节的反例是给Duck继承体系下的子类强行定义Fly、Quack这类单方法接口，最终导致大量子类重复实现相同的飞行/叫的逻辑，代码冗余度极高，且上层代码并没有大量以Fly接口为参数做统一调用的场景，这种接口的引入只有成本没有收益，是作者反对的核心场景。
而Observer模式中的Display接口是典型的行为契约：所有观察者的展示逻辑完全独立，不存在通用的默认实现，且主题侧需要统一触发所有观察者的展示动作，不需要感知具体观察者的类型，用单方法接口刚好符合接口隔离原则，是完全合理的用法。

单方法接口的适用边界 #

满足以下任意场景时，使用单方法接口都是合理的：

• 需要为多个差异极大的实现类定义统一的行为契约，且该行为没有可复用的公共实现，上层代码需要以该接口为类型做统一调用
• Java 8及以上版本的函数式编程场景：给单方法接口标注@FunctionalInterface后，可以直接用Lambda表达式、方法引用快速构造实现，不需要额外编写匿名内部类或独立实现类，代码简洁度提升明显，JDK自带的Runnable、Consumer、Callable都是这类设计的典型代表
• 接口职责完全单一，不会强制实现类依赖任何自身不需要的方法，符合接口隔离原则

不适合使用单方法接口的场景及替代方案 #

如果不符合上述适用场景，可以根据实际需求选择更优的实现方式：

• 场景1：对应方法存在可复用的公共实现，大部分子类都不需要重写逻辑
  替代方案：Java 8及以上可以给接口添加default方法实现公共逻辑，有特殊需求的子类再单独重写；也可以直接改用抽象类，把公共逻辑放到抽象类的普通方法中，避免所有子类重复编码
• 场景2：仅需要强制子类实现某个方法，没有上层统一调用的多态需求
  替代方案：直接把父类定义为抽象类，声明对应的抽象方法即可，不需要单独抽取冗余的接口
• 场景3：纯函数式调用场景，不需要额外的语义标识
  替代方案：优先复用JDK自带的函数式接口，比如Observer模式中的Display接口完全可以用Runnable代替，减少自定义接口的冗余；如果需要明确的业务语义区分，自定义@FunctionalInterface接口也完全没问题

内容的提问来源于stack exchange，提问作者Garri Sumalapao Farol