接口类已实现方法仍需被强制覆盖的实用场景探讨

问题背景 #

以下是一个包含默认实现方法的Dart接口类示例，实现该接口的类可选择覆盖这个预实现的方法：

interface class Vehicle {
  void moveForward(int meters) {
    // 默认实现逻辑
  }
}

class MockVehicle implements Vehicle {
  @override
  void moveForward(int meters) {
    // 覆盖默认实现的自定义逻辑
  }
}

这类带预实现方法的接口，实用场景主要有以下几种：

• 兼容接口版本迭代：当需要给已有接口新增方法时，提供默认实现能避免所有现有实现类立刻报错。比如原有接口只有核心方法，新增辅助方法时，默认实现可以是空逻辑或基础逻辑，让老代码先正常运行，后续再逐个优化覆盖。

• 简化测试Mock类编写：单元测试中创建Mock实现时，只需覆盖需要验证或自定义的方法，其余方法直接复用接口的默认实现，不用写一堆空方法填充，减少冗余代码。比如示例中的MockVehicle，如果只需要验证moveForward的调用情况，其他接口方法（若有）可直接用默认实现。

• 复用通用逻辑：当多个接口实现类存在重复的基础逻辑时，把这部分逻辑抽到接口的默认实现里，子类只需专注实现差异化业务逻辑。比如所有交通工具的moveForward都需要记录行驶里程，就把记里程的逻辑放到默认实现，子类仅处理动力输出的差异。

• 保证接口契约的最低标准：给接口方法提供符合契约的基础实现，确保即使子类完全不覆盖该方法，也不会出现逻辑断裂。比如一个数据上报接口，默认实现可以把数据打印到控制台，子类可覆盖成上报到服务器，这样即使子类没实现，也能满足“上报”的最低要求。

• 渐进式业务迁移：大型项目中，接口需要调整逻辑但又不能一次性替换所有实现时，默认实现可作为过渡方案。先把新逻辑放到默认实现，让部分子类逐步切换，待所有子类完成覆盖后，再移除默认实现或调整接口规范。

内容的提问来源于stack exchange，提问作者Carlos 2V