依赖倒置原则要求接口由高层模块主导定义，作为稳定契约，聚焦“做什么”而非“怎么做”，命名体现业务意图，参数返回值限于基础类型或可控抽象，不引入外部具体依赖。

关键不是“怎么设计接口”，而是“为什么这样设计接口”——依赖倒置原则（DIP）要求接口成为高层与低层共同依赖的稳定契约，而不是高层为低层写个“适配壳”。接口设计是否合理，直接决定解耦效果。

接口要描述“做什么”，不暴露“怎么做”

接口名和方法应聚焦业务意图，屏蔽技术实现细节。比如订单完成需通知用户，就定义 NotificationService 接口，只含 send(String content) 方法；不叫 EmailSender，也不在方法签名里带 JavaMailSender 或 String smtpHost 这类具体类型。

• ✅ 好接口：interface PaymentProcessor { boolean process(BigDecimal amount); }
• ❌ 坏接口：interface PaymentProcessor { void processWithAlipaySdk(AlipayClient client, String orderNo); }（绑死了实现、第三方类、参数结构）

接口要窄而稳定，避免大而全

一个接口只表达一类明确协作行为。把“查库存”“扣库存”“回滚库存”全塞进 IInventoryService，不如拆成 IInventoryChecker 和 IInventoryLocker。窄接口更易复用、更难被误改，也便于未来按需组合。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 命名体现职责：用 IOrderValidator 比 IService 清晰，用 FileExporter 比 Exporter 更准确
• 不预留“以后可能用到”的方法，等真实需求出现再扩展——抽象的稳定性来自克制，不是预测

接口不依赖具体类，也不引入外部包

如果接口里 import 了 org.springframework.mail.javamail.JavaMailSender 或 com.fasterxml.jackson.databind.ObjectMapper，那就不是抽象，是具体实现的影子。这会让所有依赖该接口的模块被迫引入无关依赖，破坏隔离性。

• 参数和返回值类型必须是 JDK 基础类型、自定义 DTO，或其它你完全掌控的抽象类型
• 异常类型也应是自定义业务异常（如 PaymentRejectedException），而非 IOException 或 SQLException

接口由使用方（高层）主导定义，不是由实现方（低层）反推

谁调用，谁定义契约。订单服务需要通知能力 → 它声明 NotificationService 接口；邮件团队来实现它，而不是邮件团队先写了 EmailService，再让订单服务去适配。

• 避免“已有实现，再抽接口”：那样容易把实现细节（如重试次数、超时字段）直接搬进接口
• 理想流程：先写业务逻辑伪代码 → 提炼出缺失的抽象角色 → 定义接口 → 再由不同团队并行实现

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