Java 中如何优雅处理多类型共用方法

当一个变量只能是两个具体类（如 Class1 或 Class2）的实例，且两者都提供相同语义的方法（如 `getAllMyObjects()`）时，应通过提取公共接口消除重复类型判断，提升可读性与可维护性。

在 Java 中，面对“变量必为 A 或 B 类型之一，且需调用同名同行为方法”的场景，硬编码 instanceof 分支不仅冗余，还违背面向对象的设计原则——它将类型逻辑暴露在业务代码中，增加耦合、阻碍扩展（例如未来新增 Class3 时需修改所有类似判断）。

最佳实践是引入公共接口：

interface MyObjectsProvider {
    Collection getAllMyObjects();
}

class Class1 implements MyObjectsProvider {
    @Override
    public Collection getAllMyObjects() {
        // 返回 Class1 特定的 MyObjects 集合
        return this.myObjectsList;
    }
}

class Class2 implements MyObjectsProvider {
    @Override
    public Collection getAllMyObjects() {
        // 返回 Class2 特定的 MyObjects 集合
        return this.cachedObjects;
    }
}

定义接口后，调用方代码即可大幅简化：

List list = new ArrayList<>();
MyObjectsProvider provider = anotherVar; // 编译期类型即为接口
list.addAll(provider.getAllMyObjects());   // 无需 instanceof，无强制转换

✅ 优势显著：

• 零运行时类型检查：安全、高效、语义清晰；
• 开闭原则友好：新增实现类（如 Class3）无需修改现有调用逻辑；
• 利于测试与模拟：可轻松注入 MockMyObjectsProvider 进行单元测试；
• IDE 支持完善：自动补全、重构（如重命名方法）全局生效。

⚠️ 注意事项：

• 若 anotherVar 的编译时类型无法直接声明为 MyObjectsProvider（例如来自泛型集合或遗留 API），仍可保留一次安全类型检查，但仅需一次、且语义明确：

  if (anotherVar instanceof MyObjectsProvider provider) { // Java 14+ 模式匹配
      list.addAll(provider.getAllMyObjects());
  } else {
      throw new IllegalArgumentException("Unsupported type: " + anotherVar.getClass());
  }

• 避免使用 Object 强转或反射等“技巧”替代接口抽象——它们牺牲类型安全与可维护性，得不偿失。

归根结底，instanceof + 强制转换不是“不够简洁”的问题，而是设计信号：当多个类共享行为契约时，正是抽取接口的明确时机。