Java接口回调机制是通过定义接口、实现接口并传入实例，将行为作为参数传递，实现调用方与业务逻辑解耦；核心在于依赖倒置，使ApiClient只关注“何时回调”，具体行为由外部注入。
Java 中接口本身不是回调函数，但可以通过定义接口 + 实现类 + 传入对象的方式，模拟回调机制，从而实现业务逻辑与调用方的解耦。核心在于“把行为（而不是数据）作为参数传递”，让调用方不关心具体怎么执行，只负责触发；被调用方专注实现细节。
定义回调接口：声明你要委托出去的行为
先设计一个只含一个抽象方法的接口（也叫函数式接口），比如处理完成后的通知：
public interface DataCallback {
void onSuccess(String result);
void onError(String errorMsg);
}
这个接口就是“回调契约”——它不做事，只约定“成功或失败时，你得提供这两个方法”。谁实现它，谁就负责具体响应逻辑。
在业务类中接收并调用接口：把控制权交给使用者
在需要解耦的类里（比如网络请求工具、异步任务处理器），不写死处理逻辑，而是接收一个 DataCallback 实例，并在适当时机调用它的方法：
立即学习“Java免费学习笔记（深入）”；
public class ApiClient {
public void fetchData(String url, DataCallback callback) {
// 模拟异步操作
new Thread(() -> {
try {
String data = "real_data_from_server";
callback.onSuccess(data); // 主动“回调”
} catch (Exception e) {
callback.onError("Network failed");
}
}).start();
}
}
这里 ApiClient 不依赖任何具体业务类，它只依赖接口。谁传进来的 callback，谁就决定 success 后弹 Toast、更新 UI 还是存数据库。
调用方按需实现：解耦的关键落地点
使用方不再继承或修改工具类，而是现场实现接口（可用匿名内部类、Lambda 或独立实现类）：
// 方式1：Lambda（最常用，简洁）
apiClient.fetchData("https://api.example.com",
(result) -> System.out.println("Success: " + result),
(error) -> System.err.println("Error: " + error)
);
// 方式2：如果接口有多个方法，用匿名类更清晰
apiClient.fetchData("...", new DataCallback() {
@Override
public void onSuccess(String result) {
updateUi(result);
}
@Override
public void onError(String errorMsg) {
showErrorMessage(errorMsg);
}
});
- UI 层、Service 层、测试代码可以各自传入不同实现，互不影响
- 单元测试时可传入 Mock 回调，验证是否正确触发 onSuccess / onError
- 后续新增回调类型（如 onProgress）只需扩展接口（配合 default 方法）或定义新接口，不影响旧调用
对比传统写法：为什么这叫“解耦”？
如果没有接口回调，常见写法是：
- 在 ApiClient 里直接写
Toast.makeText(...)→ 紧耦合 Android SDK，无法复用于 Java SE - 用 if-else 判断业务类型再分支处理 → 每加一个业务就要改 ApiClient，违反开闭原则
- 通过继承重写模板方法 → 子类爆炸，且父类必须预设扩展点
而接口回调把“做什么”和“谁来做”彻底分开：ApiClient 只管“何时做”，具体行为由外部注入。这不是语法糖，是面向对象里“依赖倒置”的典型实践。
