当一个变量只能是两个具体类（如 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;
}
} 定义接口后，调用方代码即可大幅简化：
Listlist = new ArrayList<>(); MyObjectsProvider provider = anotherVar; // 编译期类型即为接口 list.addAll(provider.getAllMyObjects()); // 无需 instanceof，无强制转换
✅ 优势显著：
立即学习“Java免费学习笔记（深入）”；
- 零运行时类型检查：安全、高效、语义清晰；
- 开闭原则友好：新增实现类（如 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 + 强制转换不是“不够简洁”的问题，而是设计信号：当多个类共享行为契约时，正是抽取接口的明确时机。
