接口在依赖倒置原则中起桥梁作用，将“用什么功能”与“谁来提供”彻底分离；高层模块面向接口编程，底层实现专注兑现契约，依赖通过外部注入实现解耦。

接口在依赖倒置原则中起桥梁作用，关键在于它把“用什么功能”和“谁来提供这个功能”彻底分开。高层模块只面向接口编程，不感知底层实现；底层实现只负责兑现接口承诺，不反向牵扯业务逻辑。这种分离让替换、测试、扩展都变得轻量直接。

接口定义清晰的行为契约

一个好接口只聚焦一类可替换的能力，命名体现意图，方法表达动作，不含无关职责：

• ✅ PaymentProcessor：只含process()、refund()，不掺杂日志或配置加载
• ✅ UserRepository：只声明findById()、save()，不指定MySQL或Redis实现细节
• ❌ 避免SystemService这类大而全的接口——它模糊边界，削弱可替换性，也违背单一职责

高层模块通过接口声明依赖

业务类（如OrderService、UserService）所有对外依赖都用接口类型表达，不碰具体实现：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 字段声明为private final NotificationSender notifier;，而非SmsNotifier或EmailNotifier
• 构造函数接收接口参数：public OrderService(PaymentProcessor processor)
• 方法参数和返回值也用接口：public List findActiveUsers(UserQuery query)，不用ArrayList或JdbcUserQueryResult

底层实现专注兑现契约，不反向依赖高层

具体类（如WeChatPayService、RedisUserRepository）只做一件事：实现接口，且保持单向依赖：

• 它implements PaymentProcessor，但不import、不调用OrderService
• 内部不写new、不硬编码业务类，也不包含流程控制逻辑
• 所有行为围绕接口方法展开，比如WeChatPayService.process()只封装微信API调用，不判断订单状态

依赖由外部注入，不自己创建

解耦效果最终靠注入机制落地，接口是注入的“类型锚点”：

• 测试时传入MockPaymentProcessor，验证OrderService是否正确调用process()
• 生产环境由Spring容器注入AliPayService或WeChatPayService，无需改OrderService代码
• 手动组装时也只需new新实现+传入构造函数，不侵入原有逻辑

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南