多态是接口回调解耦的底层前提，依赖运行时动态分派；必须用接口类型声明、避免硬编码实现类、禁止 instanceof 判断，否则解耦失效；还需结合生命周期管理（如 isAvailable 或 WeakReference）保障契约完整性。
多态是接口回调能解耦的前提，不是附加效果
没有多态，接口回调就退化成普通函数调用。关键在于：接口变量本身不绑定具体类，callback.onSuccess() 这一行代码在编译期不知道会执行哪个 onSuccess 实现——它依赖运行时传入的对象类型。Java 虚拟机靠虚方法表（vtable）动态分派，这才是解耦的底层支撑。
常见误解是“只要用了接口就自动解耦”，但若调用方硬编码了 new OkHttpCallbackImpl() 或直接强转为实现类，多态就失效，耦合立刻回归。
- 必须用接口类型声明参数和字段，比如
ApiResponseCallback callback，而非OkHttpCallbackImpl callback - 实现类不能在调用链中被显式 new 出来（工厂或 DI 容器注入才安全）
- 避免在回调内部再反向持有调用方引用（如传
this），否则形成双向强依赖
为什么不能只靠继承，而必须用接口
继承解决的是“is-a”关系，接口解决的是“can-do”关系。在回调场景下，你关心的不是对象“是什么”，而是“能做什么”。比如网络请求完成这件事，Activity、ViewModel、Service 完全无关的类都可能需要响应，它们无法共享一个父类，但可以统一实现 ApiResponseCallback。
用抽象类替代接口看似可行，但 Java 单继承限制会让调用方很快撞墙——如果 MyActivity 已继承 AppCompatActivity，就无法再继承你的回调基类。
- 接口支持多实现，一个类可同时处理网络、数据库、传感器等多种回调
- 接口默认方法（
default）能提供通用空实现，减少模板代码 - 函数式接口（如
Consumer）配合 lambda 可进一步弱化语法耦合
回调触发点暴露多态失效风险
多态只在“通过接口引用调用方法”时生效。一旦在被调用方内部做了 instanceof 判断或向下转型，比如：
if (callback instanceof OkHttpCallbackImpl) {
((OkHttpCallbackImpl) callback).extraLog();
}
这段代码就把所有后续扩展锁死在 OkHttpCallbackImpl 上，新增 RetrofitCallbackImpl 就得改这里——解耦彻底失效。
- 被调用方代码里禁止出现任何具体实现类名
- 日志、监控等横切逻辑应通过装饰器模式包装接口，而非侵入实现类
- 若真需区分行为，应把差异上提到接口方法签名里（例如加
boolean isDebug()方法）
Android 场景下最容易忽略的生命周期陷阱
多态保证了类型安全，但不保证对象存活。Activity 销毁后回调仍可能到达，此时 callback 引用的对象可能已不可用，但多态机制照常触发 onSuccess——结果是空指针或更新销毁界面。
这不是多态的问题，而是没把“对象有效性”纳入解耦契约。解决方案不是放弃接口，而是补全约束：
- 回调接口增加
isAvailable()方法，由调用方实现（如检查isFinishing()） - 被调用方在调用前统一校验：
if (callback != null && callback.isAvailable()) { callback.onSuccess(...); } - 更推荐用
WeakReference持有回调，但需配合isEnqueued()等状态标记防重复
真正难的从来不是写对那几行接口定义，而是让所有参与方都承认：接口不只是类型占位符，它是一份运行时契约——包括何时可调、谁负责清理、失败是否重试。
