通过面向接口编程和依赖注入，将具体实现解耦，OrderProcessor 依赖 NotificationService 接口而非具体类，新增 SMSNotification 等实现无需修改原有代码，提升可维护性与扩展性。
在Java开发中，对象间的侵入式依赖会降低代码的可维护性、可测试性和扩展性。要解决这个问题，关键在于合理运用抽象，将具体实现从调用方解耦出来。核心思路是依赖于接口或抽象类，而不是具体的类。
使用接口定义行为契约
通过接口来声明对象应具备的能力，而不是直接依赖某个具体类。这样调用方只关心“能做什么”，而不关心“谁来做”和“怎么做”。
例如，有一个订单处理系统，需要发送通知：
interface NotificationService {void send(String message);
}
class EmailNotification implements NotificationService {
public void send(String message) {
System.out.println("邮件发送: " + message);
}
}
class OrderProcessor {
private NotificationService notificationService;
public OrderProcessor(NotificationService service) {
this.notificationService = service;
}
public void process() {
notificationService.send("订单已处理");
}
}
这样，OrderProcessor 不依赖任何具体的通知方式，只依赖抽象。未来添加短信、推送等通知方式时，无需修改原有代码，只需新增实现类即可。
立即学习“Java免费学习笔记（深入）”；
依赖注入降低耦合
避免在类内部直接 new 具体实现，而是通过构造函数或setter方法传入依赖。这使得对象之间的关系更加灵活，也便于单元测试中替换模拟对象（Mock）。
上面例子中，通过构造函数传入 NotificationService 实例，就是典型的依赖注入方式。
- 调用方控制依赖的创建，而非被调用方自行决定
- 可以在运行时切换不同实现，比如测试环境用 MockNotification，生产环境用 EmailNotification
- 配合Spring等框架可实现自动装配，进一步简化管理
面向抽象编程，避免硬编码
在设计阶段就优先考虑抽象层次，把变化的部分封装到实现类中。常见做法包括：
- 方法参数使用接口类型，如 List 而不是 ArrayList
- 返回值也尽量返回抽象类型，增强调用方的灵活性
- 工厂模式封装对象创建逻辑，对外只暴露抽象结果
例如：
Listreturn new ArrayList(); // 返回具体类型，但接口接收
}
调用方拿到的是 List 接口，后续可自由替换为 LinkedList 等其他实现，不影响业务逻辑。
利用多态提升扩展能力
抽象的价值不仅在于解耦，更在于支持多态行为。同一操作在不同实现上有不同表现，而调用方无需修改代码。
比如增加一个 SMSNotification 实现：
class SMSNotification implements NotificationService {public void send(String message) {
System.out.println("短信发送: " + message);
}
}
只需要在初始化 OrderProcessor 时传入新的实现：
new OrderProcessor(new SMSNotification());原有逻辑完全不变，系统自然支持新功能。
基本上就这些。合理运用抽象，配合依赖注入和接口隔离，就能有效减少对象间的侵入式依赖，让代码更健壮、更易维护。关键是养成“面向接口编程”的习惯，把稳定的部分留给上层，把变化的部分交给实现。不复杂但容易忽略。
