在面向对象编程里，模块之间如果互相直接依赖具体实现，代码就会越改越乱。Java通过接口回调可以把“做什么”和“谁来做”分开，让调用方只认接口不认实现，从而达到解耦。下面用一个常见业务场景来说明具体做法。
一、什么是接口回调
接口回调本质上是一种由被调用方反过来调用调用方逻辑的机制。在Java中，我们先定义一个接口，把某些行为抽象成方法；然后由使用方提供该接口的实现类，并把实现对象传给目标模块；目标模块在合适时机调用接口方法，就完成了回调。
这种方式和直接new一个具体类再调用方法不同。直接调用让模块牢牢记住了另一个模块的类名和结构，而接口回调只要求对方“长什么样能干什么”，不关心“具体是谁”。这也是面向对象中依赖倒置原则的常见落地形式。
二、订单与通知的紧耦合问题
假设有一个订单服务，用户支付完成后需要发短信。如果直接写死调用，订单类就要引入短信工具类，以后想换成邮件或者微信通知，必须改订单服务的源码。下面是一段有问题的代码示例：
// 紧耦合写法：订单服务直接依赖具体短信类
class SmsNotifier {
public void send(String msg) {
System.out.println("发送短信:" + msg);
}
}
class OrderService {
private SmsNotifier notifier = new SmsNotifier();
public void paySuccess(String orderId) {
System.out.println("订单" + orderId + "支付成功");
notifier.send("您的订单" + orderId + "已支付");
}
}
这段代码看起来简单，但OrderService和SmsNotifier绑死了。一旦运营说要接微信模板消息，开发者就得进OrderService改私有成员和调用语句，容易引入回归错误，也不方便单元测试时屏蔽外部通知。
更麻烦的是，如果项目里还有退款、发货等多个环节都要通知，每个服务都各自new通知类，将来统一切换渠道会变成大面积改动。这种散落的依赖正是系统僵化的根源。
三、用接口回调重构实现解耦
我们先声明一个通知接口，把“支付成功后要通知”这件事抽象出来。任何通知方式只要实现这个接口，就能被订单服务使用。代码如下：
// 回调接口：定义支付成功后的通知行为
interface PaidListener {
void onPaid(String orderId);
}
// 短信实现
class SmsPaidListener implements PaidListener {
public void onPaid(String orderId) {
System.out.println("短信通知:订单" + orderId + "已支付");
}
}
// 邮件实现
class EmailPaidListener implements PaidListener {
public void onPaid(String orderId) {
System.out.println("邮件通知:订单" + orderId + "已支付");
}
}
接着修改OrderService，让它持有接口而不是具体类，并允许外部传入实现。这就是回调注册的过程：
class OrderService {
private PaidListener listener;
// 由外部注入回调实现，完成解耦
public void setPaidListener(PaidListener listener) {
this.listener = listener;
}
public void paySuccess(String orderId) {
System.out.println("订单" + orderId + "支付成功");
if (listener != null) {
listener.onPaid(orderId);
}
}
}
使用时，调用方自行决定用哪种通知，订单服务完全不需要知道。示例如下：
public class Demo {
public static void main(String[] args) {
OrderService service = new OrderService();
// 想用短信就注短信，想用邮件就注邮件
service.setPaidListener(new EmailPaidListener());
service.paySuccess("NO123");
}
}
通过setPaidListener方法，我们把具体行为推迟到运行时再绑定。订单模块编译期只依赖PaidListener接口，不依赖任何通知工具，实现了向上层抽象依赖。新增通知方式只需写新实现类，旧代码零改动。
在测试环境，还可以传入一个空实现或者记录日志的假实现，避免真实发送短信，让单元测试跑得又快又稳。这就是解耦带来的直接好处。
四、接口回调与直接调用的对比
为了更直观看到差异，我们把两种方案放在一张表里比较：
| 维度 | 直接调用具体类 | 接口回调 |
|---|---|---|
| 模块依赖 | 依赖具体实现，编译期绑定 | 依赖抽象接口，运行期绑定 |
| 更换实现成本 | 改调用方源码 | 换注入对象，调用方不变 |
| 单元测试 | 难屏蔽外部副作用 | 易用假实现替代 |
| 扩展新行为 | 改旧类或复制粘贴 | 写新实现类即可 |
从表里能看出，接口回调并不是多了几行代码这么简单，而是把系统从“写死”变成“可插拔”。在大型项目里，这种写法能显著降低联调成本。
当然，回调也不是万能。如果接口过多、回调链过长，会让程序流程跳来跳去不好读。实际开发中建议只把真正可能变化的行为抽象成接口，不要过度设计。
五、在真实项目中的落地建议
除了上面说的setter注入，还可以在构造方法里传接口，或者用Spring这类容器直接按类型注入。比如把PaidListener做成Bean，OrderService用@Autowired接收，底层原理还是接口回调，只是绑定动作交给框架。
另外，Java 8之后可以用函数式接口配合lambda简化写法，不用每次都写实现类。例如把接口改成只有一个方法的interface，就能用()->{}直接传行为。但不管语法糖怎么变，核心思想一直是：调用方定义时机，使用方提供实现，双方通过接口契约合作。
当你发现两个类总是互相new、改一个另一个就报错时，就可以考虑抽一个接口，让其中一方回调另一方。慢慢养成这种习惯，代码就会从一团麻变成可替换的零件组合。