当变量只可能属于两个具体类且需调用同名方法时，应避免冗余的 instanceof 判断和强制类型转换，转而定义公共接口并让两类实现该接口，从而以多态方式简洁、安全地调用方法。
在 Java 中，面对“变量必为 Class1 或 Class2 之一，且两者均提供 getAllMyObjects() 方法”这一场景，反复使用 instanceof + 强制转换不仅冗长、易出错，也违背面向对象的设计原则。更优雅、可维护的解法是引入抽象层——即定义一个公共接口。
✅ 推荐方案：使用接口实现统一契约
首先，声明一个接口，明确约定行为：
interface MyObjectsProvider {
Collection<MyObjects> getAllMyObjects();
}接着，让两个已有类分别实现该接口（无需修改原有逻辑，仅添加 implements 和重写方法）：
class Class1 implements MyObjectsProvider {
@Override
public Collection<MyObjects> getAllMyObjects() {
return this.myObjectsList; // 替换为实际返回逻辑
}
}
class Class2 implements MyObjectsProvider {
@Override
public Collection<MyObjects> getAllMyObjects() {
return Collections.unmodifiableList(this.objects); // 示例：可含不同实现细节
}
}此时，调用代码可大幅简化为：
List<MyObjects> list = new ArrayList<>(); MyObjectsProvider provider = anotherVar; // 编译期即保证类型安全（若 anotherVar 类型可推导） list.addAll(provider.getAllMyObjects());
✅ 优势显著：
- 零条件判断：消除 if-else 分支，逻辑扁平清晰；
- 开闭原则友好：未来新增 Class3 只需实现 MyObjectsProvider，无需修改现有调用逻辑；
- 类型安全增强：编译器自动校验 anotherVar 是否满足接口契约（IDE 与编译期双重保障）；
- 语义明确：MyObjectsProvider 清晰表达了“能提供 MyObjects 集合”的职责，提升可读性与协作效率。
⚠️ 兼容性补充：若 anotherVar 类型无法静态限定为接口
例如 anotherVar 是 Object 或泛型 ? 类型，无法直接赋值给 MyObjectsProvider，则保留一次类型检查即可（仍比重复 cast 更健壮）：
Object anotherVar = getDynamicValue();
if (anotherVar instanceof MyObjectsProvider provider) { // Java 14+ 模式匹配语法，推荐
list.addAll(provider.getAllMyObjects());
} else {
throw new IllegalArgumentException("Unsupported type: " + anotherVar.getClass().getName());
}? 提示：Java 14 起支持 instanceof 模式匹配（if (obj instanceof InterfaceType var)），可同时完成类型检查与变量抽取，进一步精简代码。
❌ 不推荐的替代思路说明
- variable = (Class1 | Class2) anotherVar 是无效语法 —— Java 不支持联合类型（Union Types）；
- 使用反射或 MethodHandle 过度复杂，丧失编译期检查与性能优势；
- 创建工具方法封装 instanceof 逻辑（如 getObjects(Object o)）虽略改善，但未解决根本设计问题，且仍隐含运行时风险。
总结：接口不是“额外负担”，而是对共性行为的显式建模。它将分散的类型判断收敛为单一契约，让代码更短、更稳、更易演进。从今天起，遇到“二选一但行为一致”的场景，请优先思考：“它们共同承诺了什么？——那就把它定义成接口。”
