上周一个看似无害的邮件发送模块调整，让订单服务整个没跑起来。这不是运气差，是依赖方向出了问题。我是老李，今天聊聊设计模式里的依赖倒转原则。很多人一听就想到接口，但真到写代码时还是高层直接抓着低层实现不放。为什么现在要讲？因为系统越复杂，依赖方向的错误代价越大，早改早轻松。

## 01、痛点

假设你在写一个订单服务，业务逻辑里需要发通知。最自然的写法是直接 new 一个 EmailSender 然后调用。代码长这样：

```java
public class OrderService {
    private EmailSender sender = new EmailSender();

    public void placeOrder(Order order) {
        // 保存订单逻辑
        sender.send("订单已创建");
    }
}
```

表面看没问题，但隐患很大。EmailSender 的任何构造参数调整、方法签名变化，OrderService 都要跟着改。更糟的是，产品说再加个短信通知，你只能改 OrderService 内部加 if-else。测试时没法替换成假发送器，只好连真实邮件服务器。

```
高层 OrderService
      │ 直接依赖（new）
      ▼
低层 EmailSender
```

这就是传统依赖：高层依赖低层，低层的细节变化会向上传导，整个系统变得僵化。

## 02、是什么

依赖倒转原则（Dependency Inversion Principle，DIP）是 SOLID 中的 D。核心有两点：第一，高层模块不该依赖低层模块，二者都应该依赖抽象；第二，抽象不应该依赖细节，细节应该依赖抽象。简单说，倒转的是依赖方向：原来从上到下直接抓实现，现在中间插入一个接口，让两边都面对接口。

```
    OrderService
         │
         ▼
   MessageSender 接口
         ▲
         │
EmailSender / SmsSender
```

在 Java 里，抽象通常用 interface 或 abstract class 表达。这里的 MessageSender 就是抽象，具体类通过 implements 实现接口。注意，DIP 不是消灭依赖，而是让依赖指向稳定层。

很多人把 DIP 和依赖注入、控制反转混为一谈。其实 DIP 是一条设计原则，解决“依赖应该指向谁”；依赖注入是实现手段，解决“依赖怎么给”；控制反转是更宽泛的思想，解决“控制权归谁”。三者有关系，但不是同一件事。

## 03、为什么

为什么要这么干？因为需求总会变。通知方式会变，数据存储会变，第三方服务会变。如果高层代码依赖具体实现，每一个变化都会被迫修改核心业务逻辑。一旦引入抽象，变化被隔离在接口的另一侧。

```
无抽象：  业务逻辑 ──变化──> 核心代码被迫修改
有抽象：  业务逻辑 ──抽象──> 稳定，实现可替换
```

从 Java 实践看，依赖抽象让单元测试变得轻松：你可以写一个 FakeMessageSender，把消息收集到 List 里断言，不用真的连邮件服务器。可测试性直接决定代码质量。其次，它让系统满足开闭原则：新增 SmsSender 不需要改 OrderService，只要加一个新实现。可扩展性大幅提升。最后，它让团队成员并行开发：定义好接口后，上层写业务，下层写实现，互不阻塞。

## 04、架构

在架构层面，DIP 决定了依赖的方向。传统分层架构中，上层直接依赖下层，逐层向下。倒转之后，抽象通常被放在高层或者单独的内层包中，依赖从外层指向内层。

```
传统：         UI → Service → Repository
倒转后：       UI → Service → Repository 接口
                         ↑
                Repository 实现（MySQL/Redis）
```

典型的包结构可以这样组织：domain 包定义接口，infrastructure 包提供实现。例如：

```
com.example.order.domain.MessageSender
com.example.order.infrastructure.EmailSender
```

MessageSender 接口属于业务域，EmailSender 属于基础设施层。依赖方向从 infrastructure 指向 domain，而不是反过来。这也和端口与适配器架构、整洁架构的核心思想一致：业务核心不依赖外部细节，外部细节通过实现接口接入。

## 05、实战

下面用完整 Java 例子走一遍。还是订单通知场景。第一步，定义抽象接口：

```java
public interface MessageSender {
    void send(String message);
}
```

第二步，写两个具体实现：

```java
public class EmailSender implements MessageSender {
    @Override
    public void send(String message) {
        System.out.println("发送邮件：" + message);
    }
}

public class SmsSender implements MessageSender {
    @Override
    public void send(String message) {
        System.out.println("发送短信：" + message);
    }
}
```

第三步，让高层 OrderService 只依赖 MessageSender：

```java
public class OrderService {
    private final MessageSender sender;

    public OrderService(MessageSender sender) {
        this.sender = sender;
    }

    public void placeOrder(Order order) {
        // 保存订单逻辑
        sender.send("订单已创建");
    }
}
```

第四步，装配具体实现：

```java
public class Main {
    public static void main(String[] args) {
        MessageSender sender = new EmailSender();
        OrderService service = new OrderService(sender);
        service.placeOrder(new Order());
    }
}
```

如果改用 Spring，构造器注入会自动完成：

```java
@Component
public class OrderService {
    private final MessageSender sender;

    public OrderService(MessageSender sender) {
        this.sender = sender;
    }
}
```

当一个接口有多个实现时，可以用 @Primary 指定默认实现，或用 @Qualifier 精确选择。

再看一个数据库访问的例子。业务服务依赖 UserRepository 接口，而不是 JdbcUserRepository 具体类：

```java
public interface UserRepository {
    User findById(Long id);
    void save(User user);
}

@Service
public class UserApplicationService {
    private final UserRepository repository;

    public UserApplicationService(UserRepository repository) {
        this.repository = repository;
    }
}
```

以后从 JDBC 切到 MyBatis，只需要写一个 MyBatisUserRepository 实现并替换配置，业务服务零改动。

单元测试时写假实现：

```java
class FakeMessageSender implements MessageSender {
    private final List<String> messages = new ArrayList<>();

    @Override
    public void send(String message) {
        messages.add(message);
    }
}
```

测试中不用真实网络。

```
定义抽象 → 实现抽象 → 构造注入 → 测试替身
```

## 06、洞见

DIP 最难的不是写接口，而是判断哪些依赖值得倒转。不是所有类都需要接口。给每个类都抽接口，代码会变得碎片化，这就是过度设计。判断标准通常是：这个依赖未来会不会有多个实现？或者它是否属于外部细节，比如数据库、消息队列、第三方服务？如果是，就应该倒转。纯业务实体、值对象不必强行抽象。

```
变化实现（外部细节） ──> 抽象
稳定领域对象 ──> 不强行抽象
```

另一个常见误区：接口应该由谁定义？很多人从具体类中抽取接口，比如先写 EmailSender，再提取出 MessageSender。这样接口天然带着 Email 的痕迹。正确的是由高层模块来定义接口，因为高层最清楚自己要什么。低层只是实现者。

注意依赖注入容器不是 DIP 的证明。用 Spring 不等于依赖就倒转了。如果你在业务代码里通过容器拿到具体实现再强转，依赖仍然指向低层。真正的倒转是面向接口编程，容器只是帮你完成装配。

还有，接口隔离原则和 DIP 不能混。接口隔离关注接口的粒度，DIP 关注依赖方向。两者配合，但侧重点不同。

## 07、行动

落地可以分五步：第一，揪出变化点：哪些外部依赖可能会换？第二，由业务层定义接口，写在核心包，别放在实现包。第三，业务代码只通过接口调用，不直接 new 具体实现。第四，用构造器注入传递依赖，保证依赖显式可见。第五，测试时用假实现，不要把单元测试和真实外部资源绑在一起。

```
识别变化 → 定义接口 → 面向接口 → 构造注入 → 测试替身
```

团队里可以定一个简单规则：凡是跨层调用，一律依赖接口；同一层内部调用，允许直接依赖具体类。这样既不失控，又避免过度设计。

## 08、小结

依赖倒转不是让你倒立写代码，而是让依赖方向从易变的低层指向稳定的抽象。高层模块不再跪舔低层实现，系统就获得了呼吸感。转型的成本不高，但收益会随项目时间持续放大。

金句：稳定依赖抽象，变化依赖实现，方向倒转天地宽。

## 09、链接与概念说明

DIP 是 SOLID 五原则之一：单一职责原则（SRP）、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则（ISP）、依赖倒转原则（DIP）。控制反转（IoC）是更上位的思想，依赖注入（DI）是实现 IoC 的常见方式，构造器注入是当前主流。Java 标准库中也有 DIP 的体现：JDBC 的 Driver、Connection 是接口，具体驱动由厂商实现，客户端依赖接口，扩展不同数据库时无需修改业务代码。延伸阅读推荐《架构整洁之道》中依赖规则章节、《Java设计模式》相关论述。注意 DIP 与接口隔离原则的区别：前者管方向，后者管接口大小。

上周一个看似无害的邮件发送模块调整，让订单服务整个没跑起来。这不是运气差，是依赖方向出了问题。我是老李，今天聊聊设计模式里的依赖倒转原则。很多人一听就想到接口，但真到写代码时还是高层直接抓着低层实现不放。为什么现在要讲？因为系统越复杂，依赖方向的错误代价越大，早改早轻松。

依赖倒转原则：Java 代码从牵一发动全身到抽象定乾坤

高层模块不再跪舔低层模块，依赖倒转原则用 Java 实例讲透：接口抽象、构造器注入、测试替身，让系统告别僵化。

架构师

编程语言

后端

架构设计

依赖倒转原则（DIP）指导高层模块与低层模块依赖抽象而非具体实现，能隔离需求变化，提升系统可测试性与可扩展性。通过定义MessageSender接口、构造器注入及测试替身，Java业务代码实现稳定架构。判断标准是变化点或外部细节依赖，避免过度设计，由业务层定义接口。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

依赖倒转原则：Java 代码从牵一发动全身到抽象定乾坤-腾讯云开发者社区-腾讯云

依赖倒转原则：Java 代码从牵一发动全身到抽象定乾坤

依赖倒转原则：Java 代码从牵一发动全身到抽象定乾坤

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐