依赖倒置原则实战：从插座比喻到代码重构，告别模块拆不干净

你先别急着翻定义。我问你一个很生活化的问题：你家墙上的插座，是先有插头，还是先有插座？如果装修时电工只给你留了一个“专门适配某品牌电饭煲”的异形插座，你会不会想打人？但在我们写代码的时候，每天都在干这种事：高层业务模块直接依赖一个具体实现类，换一个数据库、或者换一个短信服务商，整个业务核心全跟着遭殃。顺着这个问题往下想，你就会碰到 DIP、依赖倒置原则。

依赖倒置原则是 SOLID 里最容易被误读的一个。很多人能背出那句话——“高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象”，但真到了项目里，还是不知道接口该放哪边、该谁去实现、依赖倒置到底“倒置”了什么。这篇文章我会从“插座和插头”这个比喻一路拆到真实代码，再讲我怎么用依赖倒置原则重构一个通知模块，最后把我在实战里踩过的坑和判断方法一起整理出来。适合那些写过两年业务代码、总觉得模块拆不干净、一换实现就头疼的开发者。

1. 先把这个比喻拆明白：插座和插头，到底谁定义了谁

1.1 为什么你的直觉在这里是错的

很多人听到“插座定义了插头，还是插头定义了插座”这个问题，第一反应是“先有插座，因为房子装修的时候就得布线、留接线盒”。但你再仔细想想：电工在布线的时候，知道未来会插什么电器吗？完全不知道。今天可能是电饭煲，明年可能是空气炸锅，后年可能是一个没听说过的新设备。他能做的，只是按照一个通用的标准去安装插座，让未来所有符合标准的东西都能插进来。

这里起决定作用的既不是插座厂商，也不是插头厂商，而是双方共同遵守的“接口规范”。你可以把它理解成一份协议：规定了电压、频率、孔距、形状。只要符合协议，无论你是哪家厂商的产品，都能在同一个墙插上工作。

代码世界里的关系其实一模一样。一个高层模块（比如订单服务）需要调用一个底层模块（比如短信发送器），你当然可以像拉专线一样，直接在业务代码里指向那个具体的短信 SDK。但这么做的后果就是：今天用阿里云短信，明天换腾讯云短信，你就要把订单服务打开改一遍；今天存 MySQL，明天切 PostgreSQL，你又要回来改一遍。真正稳定的，不是“订单服务”和“短信实现”中的任何一端，而是它们接口上的共同约定——调用方只关心“能发出去”，实现方只关心“我符合你要求的发送能力”。

所以回到那个问题：既不是插座定义了插头，也不是插头定义了插座，是“标准”定义了双方。放到软件设计里，这段话翻译过来就是：让双方的依赖都指向那个双方认可的抽象。这就是 DIP 的第一层理解。

1.2 谁更稳定，谁才有资格定规则

如果我们逼着插座和插头必须选一个当“主导者”，那你得先看看哪一边更稳定。墙上的插座孔位一旦装好，很少会去重凿墙壁；而插头这一侧，每来一个新电器就多一个新样式，甚至同一个电饭煲在不同国家销售的版本，插头都可能不一样。变化的这一方，必须去适配稳定的那一方。

这个逻辑放进系统里非常有用。你在设计一个模块时，先问自己：这一对依赖关系里，哪一方的变化频率更高？比如“顾客下单后要发通知”，这个业务动作是相对稳定的，它已经沉淀成业务语言了；但“用短信、邮件还是微信小程序订阅消息去通知”，每过半年可能就变一次。显然，发送渠道是变化的一方，通知这个动作是稳定的一方。

于是你就不该让“下单流程”去匹配“短信发送器”，而应该反过来：让短信、邮件、微信这些具体渠道，去适配一个由业务方定义的“通知接口”。用插座的比喻说，下单流程是那面墙，墙上的接口规范由它来定——但注意，它只定义协议，不关心协议背后是谁在实现。这句话理解到位了，依赖倒置的“倒置”就成功了一半。

2. 新手最容易卡住的地方：依赖倒置，到底倒置了什么

2.1 先画一下传统依赖的方向

很多人在没有接触 DIP 之前写代码，是非常“顺着直觉”的。控制器调用服务类，服务类调用仓储类，仓储类去查数据库，这是一条从上往下的单向依赖链。比如下面这个极其常见的片段：

java复制public class OrderService {
    private MysqlOrderRepository repository = new MysqlOrderRepository();
    private SmsSender smsSender = new SmsSender();

    public void createOrder(Order order) {
        orderRepository.save(order);
        smsSender.send("您有一笔新订单：");
    }
}

为什么会这样写？因为你要用它的功能，所以你 import 它的类，让高层源代码依赖底层源代码。这是最符合直觉的编码方式，一开始运行也完全没有问题。

问题在于需求从不安分。有一天产品经理走过来说：“新用户我们不接 MySQL 了，用 MongoDB，订单要存到文档库里。”你打开 OrderService，发现里面 new 的是 MysqlOrderRepository，得改；往下看测试代码，全套都在等一个真实数据库，根本没法跑。等你把 OrderService 里的依赖换掉，以为万事大吉，他又说：“短信也别发了，改发邮件。”你又回来把 OrderService 里的 SmsSender 换掉。这时候你回过味了：业务核心代码为什么一直在跟着外部工具换？这就是高层依赖低层实现带来的苦果。

仅仅因为你“用”它，就把整个业务模块和它的具体实现绑定死了。这个绑定关系在源代码层面表现为：OrderService 直接 import 了具体业务实现类的类型。它把业务代码的稳定性，外包给了底层代码的稳定性。底层一抖，高层跟着抖。

2.2 倒置的本质：依赖箭头反向

DIP 说的“倒置”，倒的不是调用方向——事实上业务层仍然在调用底层实现提供的功能，调用方向没有变。它倒的是“依赖箭头”，也就是源代码里的类型引用方向。

传统写法中，依赖箭头是这样的：

text复制订单服务 OrderService  ------>  MySQL 具体实现类

OrderService 依赖了 MysqlOrderRepository 的具体类型。

重构之后，箭头变成：

text复制订单服务 OrderService  ------>  订单仓储接口 OrderRepository
                                      ^
                                      |
                      MySQL 仓储实现类 MysqlOrderRepository

看清楚区别了吗？OrderService 仍然会调用“保存订单”这个方法，但它不再依赖 MySQL 的类型。订单服务依赖的是一个它自己定义的接口。然后 MySQL 仓储实现类反过来依赖这个接口，去实现接口里的方法。接口放在“中间”还不够，关键是这个接口的归属权：它由谁定义、为谁服务？如果接口是“从底层工具里掏出来的”，那高层的依赖还是没有脱离底层；如果接口是“高层按自己业务语言定义的”，那才真正把两端的依赖方向反转了。

我把这套逻辑应用在工程里时常说一句：倒置的本质，是把“定义权”还给了稳定的一方。你要用什么技术去存储、去通知、去发送，那是细节；而“保存订单”“通知客户”这些词汇，属于业务。业务方说清楚自己要什么，然后让所有技术细节都来满足这个要求。

很多文章喜欢用“高层依赖抽象，底层也依赖抽象”来形容 DIP，这没错，但容易让人忽略一点：如果这个抽象只是把底层的接口原封不动往上提，那你只是给底层换了件马甲。真正的 DIP，要让接口的语义从底层词汇换成高层词汇。从 MYSQL_SAVE 变成 SaveOrder，从 SEND_SMS 变成 NotifyCustomer。这一步换词，比建多少 interface 都重要。

3. 代码演示：把一个“坏味道”模块改成 DIP 风格

3.1 违反 DIP 的版本到底有多痛苦

单讲理论没意思，我们直接看一段可以运行的 Java 代码。我故意把版本写得很“天然”，因为很多同事的代码就是从这里长出来的。

java复制public class OrderService {
    private MysqlOrderRepository orderRepository;
    private SmsSender smsSender;

    public OrderService() {
        // 构造器里直接 new 具体实现
        this.orderRepository = new MysqlOrderRepository();
        this.smsSender = new SmsSender();
    }

    public void createOrder(Order order) {
        if (order == null || order.getTotalPrice() <= 0) {
            throw new IllegalArgumentException("订单不合法");
        }
        orderRepository.save(order);
        smsSender.send("您的订单已创建，金额：" + order.getTotalPrice());
    }
}

这段代码初看没什么问题，甚至结构还挺清晰：校验了订单参数，保存了订单，发了短信。但你要是把它放到真实迭代里，就会发现它把所有变化风险都往自己身上揽。

第一，MysqlOrderRepository 和 SmsSender 是具体类。只要这两个类换了构造方式，比如短信 SDK 升级以后要求传入一个 secretKey，OrderService 的构造器就要跟着改；无论你的业务逻辑有没有变化，这个类都得重新编译、重新测试。第二，因为 OrderService 在构造器里直接 new，你在写单元测试时根本没法绕开真实的 MySQL 和真实的短信网关。想测一下“订单金额非正数时抛异常”，你得先启动一个数据库，再等短信服务商给你返回成功——这不是单元测试，这是集成测试。

这种代码的致命伤也和依赖方向有关：它让一个稳定的业务主体，去依赖一堆频繁变化的第三方 SDK，让订单服务和 MySQL、短信 Sender 的版本号绑在了一起。

3.2 引入接口之后，代码变成什么样

现在按 DIP 的思路重构。核心动作不是把类名改成更抽象的名字，而是调整接口的归属权。业务层需要“保存订单”和“发送通知”，那就让业务层定义这两个能力，然后让具体实现去实现它们。

先定义两个接口，接口放哪一层很关键。在我这个项目的结构里，它们应该放在 OrderService 所在的应用/领域层，而不是数据层：

java复制public interface OrderRepository {
    void save(Order order);
}

public interface OrderNotifier {
    void send(String message);
}

然后改写订单服务，让它只依赖这两个抽象，不再关心背后的实现：

java复制public class OrderService {
    private final OrderRepository orderRepository;
    private final OrderNotifier orderNotifier;

    // 依赖通过构造器从外部传入，不在内部 new
    public OrderService(OrderRepository orderRepository, OrderNotifier orderNotifier) {
        this.orderRepository = orderRepository;
        this.orderNotifier = orderNotifier;
    }

    public void createOrder(Order order) {
        if (order == null || order.getTotalPrice() <= 0) {
            throw new IllegalArgumentException("订单不合法");
        }
        orderRepository.save(order);
        orderNotifier.send("您的订单已创建，金额：" + order.getTotalPrice());
    }
}

再写两个具体实现，让它们去依赖上面定义的接口：

java复制public class MysqlOrderRepository implements OrderRepository {
    @Override
    public void save(Order order) {
        // 这里是 JDBC / MyBatis / JPA 相关代码
    }
}

public class SmsNotifier implements OrderNotifier {
    @Override
    public void send(String message) {
        // 这里是调用短信服务商 SDK 的代码
    }
}

最后在程序入口把实现“注入”给业务类：

java复制OrderRepository repository = new MysqlOrderRepository(dataSource);
OrderNotifier notifier = new SmsNotifier();
OrderService orderService = new OrderService(repository, notifier);

现在看效果：OrderService 里再也不会出现 Mysql、Sms 这类具体工具的名字。它只关心“保存订单”和“通知顾客”这两个业务动作。如果明天把 MySQL 换成 MongoDB，你只需要新增一个 MongoOrderRepository 实现 OrderRepository；如果后天把短信换成微信，你只需要新增一个 WechatNotifier 实现 OrderNotifier。订单服务本身，一行都不用改。

这就是我在前面说的“倒置”：从原来业务类依赖底层实现类，变成底层实现类依赖业务层定义的接口。业务层成了制定协议的那一方，而具体渠道变成了一件件可插拔的“插头”。

这里要特别强调一个常见误区：不要觉得代码里写了 interface 就意味着满足了 DIP。假如你直接从某个 ORM 框架里继承一个 BaseRepository，然后让业务 Service 去依赖它，那接口虽然存在，语义却属于框架，仍然由底层工具在制定规则。真正符合 DIP 的接口，应该像上面的 OrderRepository 一样，根据业务层自己的语言来定义。这个细节，决定了你是在做依赖倒置，还是在给底层实现换个名字。

4. 代码依赖理清了，实例怎么组装：三种注入方式的取舍

4.1 构造函数注入、Setter 注入、字段自动注入的对比

把依赖收敛到接口还不够，你还需要解决一个问题：这个接口的实现，到底由谁创建、在哪里创建、什么时候传给 OrderService？这就涉及依赖注入的落地姿势。我见过不少团队从一开始就把依赖注入理解成“用 Spring 的 @Autowired 给字段打注解”，却从没想过这种写法带来的隐性成本。选择哪一种方式，不只是一件“框架习惯”的事。

三种方式适用面完全不同，先看一张对比表：

构造函数注入为什么最推荐？因为 Java 这类语言的构造函数是对象创建的必经入口。你在构造函数参数里声明依赖，就像在对象门口立了一道“不给我这些，你就不许进来”的关卡。OrderService 少了 OrderRepository，编译期直接报错，不会给你运行到一半才发现字段是 null 的机会。更重要的是，构造函数让依赖关系完全可见，任何人看一眼签名，就知道这个类依赖哪些抽象。

Setter 注入适合什么场景呢？最常见的是某个类有一个“锦上添花”的可选依赖，比如一个审计日志上报器，核心流程跑通了，你可以选择给它注入一个日志实现，也可以不注入。这时候如果强行走构造函数，调用方每次 new 都得传一个可能永远用不到的参数，反而很啰嗦。用 Setter 之前心里要有数：对象可能处于“部分装配”状态，调用方忘记 set 就会在运行期遇到空指针，所以你要么用 Optional 包装，要么在方法的注释里把这一点写清楚。

至于字段自动注入，代码确实最简洁，但它有一个很严重的问题：把依赖关系从类的“官方接口”里抹掉了。一个类依赖了别人，可你从构造器和 Setter 上什么都看不出来，只能去扫字段里的注解。项目一大了，代码阅读成本会直线上升。Spring 官方文档其实也推荐构造函数注入，不是没有原因的。我个人的铁律是：业务核心类里，能用构造函数注入就用构造函数注入；把它当成默认项。

4.2 组合根：把 new 集中到唯一的入口

依赖倒置之后，立刻会蹦出一个新问题：既然 OrderService 不在内部 new 依赖了，那 MysqlOrderRepository 和 SmsNotifier 到底谁来 new？这些“具体实现的选择”总得有一个地方负责。这个地方在干净架构里有个专门的名字——组合根（Composition Root）。

组合根通常位于系统最外层，可以是一个 main 方法、一个配置类、一个启动模块。它的职责很简单：知道所有具体实现，把这些实现实例化，然后沿着依赖链一层层注入进去。以上面的例子来说：

java复制public class Application {
    public static void main(String[] args) {
        // 组合根：初始化基础设施
        DataSource dataSource = createDataSource();
        SmsGateway smsGateway = new SmsGateway("appKey", "secretKey");

        // 组合根：装配业务依赖
        OrderRepository orderRepository = new MysqlOrderRepository(dataSource);
        OrderNotifier notifier = new SmsNotifier(smsGateway);

        // 组合根：启动真正要跑的东西
        OrderService orderService = new OrderService(orderRepository, notifier);
        orderService.start();
    }
}

组合根这个东西很容易被忽略，因为很多人用 Spring 的时候，把装配工作交给了 IoC 容器，就不再关心“依赖是在哪里被组装起来的”了。我曾经接手过一个项目，业务代码里到处都是 @Autowired 的字段注入，看起来每个类都成功做到了“不自己 new 依赖”，但整个系统的装配关系散落在每一个类文件里，你根本不知道一个服务跑起来的时候，背后用的是哪个实现。

更麻烦的是，这种写法会让 IoC 容器变成了掩盖架构问题的遮羞布。真正健康的做法是：哪怕用了容器，也要明确一个组合根的位置，让容器只在这个根上做关联解析，而不是允许所有类全都直接向容器要依赖、直接在字段上打注解。使用 Spring 等框架时，也应在启动类或配置类里显式地声明 Bean，让“用哪个实现”的决策集中在一处。

用那个电器的比喻来说：墙内的电线回路，是由电工在安装时统一接好的；而不是每台电器自己装修时偷偷往墙里拉一根专线。你在业务类里 new 一个具体实现，就等于从业务代码里偷偷拉了一根直通短信服务商的专线，这就在绕过你刚建好的“插座协议”。

5. 实战一次完整重构：从“短信 + 邮件”到“多渠道通知”

5.1 这个场景我从业务里见过太多次了

讲一个我实际参与过的案例。当时是一个商城项目的订单模块，用户下单之后要发送通知。第一版很简单，就发一条短信。于是大家顺着直觉把代码写成了下面这样：

java复制public class OrderService {
    private final SmsService smsService;

    public OrderService(SmsService smsService) {
        this.smsService = smsService;
    }

    public void createOrder(Order order) {
        // 1. 校验商品库存
        // 2. 扣减库存
        // 3. 保存订单
        // 4. 通知用户
        smsService.sendSms(order.getUserPhone(), "您的订单已创建，单号：" + order.getOrderNo());
    }
}

此时 SmsService 是从一个旧的工具类里拿出来的，代码看起来也不算太糟。但半年后，产品经理提出了一个新需求：不仅下单选短信，还要同时给用户发一封订单邮件。于是 OrderService 里多了一个 MailService 依赖，方法体里多了一行邮件发送代码，构造函数参数也多了一个。

再过半年，微信小程序上线，需要把通知推到微信订阅消息；又过了一年，运营要求“短信发送失败时不能阻塞下单主流程，要进入重试队列”。到了这一步，OrderService 里已经塞了 SmsService、MailService、WechatService、RetryQueueService 四个依赖，发送逻辑的下标变成了 if-else 和 try-catch 的混合体。我去看那一段代码时，整个方法已经有八十多行，没人敢动，因为它覆盖了下单主路径最核心的部分。

问题出在哪？出在设计订单服务时，团队直接依赖了具体的通知渠道。他们把“发短信”“发邮件”“发微信”当作一个个内部对象去调用，而不是把它们看作一个统一的“客户通知”能力。订单流程其实并不关心用户是通过短信看到消息，还是通过邮件看到消息。它只关心一件事：订单创建后，应当触发一次客户通知。这条业务规则，才是真正稳定的。

5.2 按 DIP 重构后的核心代码

重构的第一步，就是给“客户通知”这个业务动作定义一个接口。注意，它不叫 SmsSender，也不叫 MailSender，而是反映稳定业务语义的 OrderNotifier：

java复制public interface OrderNotifier {
    void notifyCustomer(OrderCreatedEvent event);
}

然后所有渠道都实现这个接口，各自封存自己的细节：

java复制public class SmsOrderNotifier implements OrderNotifier {
    @Override
    public void notifyCustomer(OrderCreatedEvent event) {
        // 调用短信渠道，sendSms...
    }
}

public class MailOrderNotifier implements OrderNotifier {
    @Override
    public void notifyCustomer(OrderCreatedEvent event) {
        // 发送订单邮件
    }
}

public class WechatOrderNotifier implements OrderNotifier {
    @Override
    public void notifyCustomer(OrderCreatedEvent event) {
        // 通过小程序订阅消息通知
    }
}

很多团队这时候会以为，让 OrderService 直接注入一个 OrderNotifier 就结束了。但如果运行环境要求三种渠道同时发送，你就需要一个组合通知器。这其实是组合模式加 DIP 的配合，很常见：

java复制public class CompositeOrderNotifier implements OrderNotifier {
    private final List<OrderNotifier> notifiers;

    public CompositeOrderNotifier(List<OrderNotifier> notifiers) {
        this.notifiers = notifiers;
    }

    @Override
    public void notifyCustomer(OrderCreatedEvent event) {
        for (OrderNotifier notifier : notifiers) {
            try {
                notifier.notifyCustomer(event);
            } catch (Exception e) {
                // 记录日志，但不要阻塞主流程
            }
        }
    }
}

最后在组合根的位置把各种渠道装进去：

java复制OrderNotifier notifier = new CompositeOrderNotifier(List.of(
    new SmsOrderNotifier(smsGateway),
    new MailOrderNotifier(mailClient),
    new WechatOrderNotifier(wechatApi)
));
OrderService orderService = new OrderService(orderRepository, notifier);

做完这一步，整个订单流程对通知机制的依赖，就只剩下一行：orderNotifier.notifyCustomer(event);。后续再引入 App 推送渠道，或者要把某个渠道的发送改成异步任务，你只需要新增实现类，或者在组合根里调换列表，完全不需要打开 OrderService。

重构之后最大的收益，不是代码变短了，而是变动的范围被牢牢限制住了。需求变化时，改的是“实现”而不是“核心”这一点，会直接体现在你提交的代码 diff 上。产品看着整齐的业务代码，开发也轻松得多。

5.3 分层架构里，依赖方向比依赖多寡更重要

把上面的订单案例放大到整个应用，你会发现很多架构模式的底层逻辑都在说同一件事：让稳定的上层不要去依赖不稳定的下层。传统三层架构里，如果 Controller 层直接调用 Mapper 层，Service 层也直接调用第三方 SDK，那么任何底层替换都会像瘟疫一样向上传染。

DIP 在分层架构中的实践，一般是这样：上层模块定义自己需要的接口，下层模块去实现这个接口，源代码的依赖箭头永远指向业务侧。领域层只声明 Repository 接口，不引用任何具体数据库；应用层只定义通知端口，不直接引短信 SDK；基础设施层去实现这些接口。稍大一点的项目会很自然地演进出这种六边形结构，核心思想就是 DIP。

但必须强调，架构分层里的 DIP 是给核心业务区域用的，不是让所有类都互相抽象一遍。我只在“稳定业务规则”和“易变技术细节”之间设接口，剩下的普通内部协作可以直接用具体类。道理其实不复杂：插座标准是因为“墙上那端稳定、电器那端常换”才值得约定，如果你的上下游变化频率差不多，硬加一层抽象只会增加理解成本。

6. 实战中反复踩的坑：DIP 的错误用法与避坑清单

6.1 以为“多建接口”就等于依赖倒置

我见过太多人对 DIP 的第一反应是：给每个实现类配一个接口。于是项目里出现了 UserService / UserServiceImpl、OrderService / OrderServiceImpl，仿佛没有这层“接口-实现”结构就不符合业界规范。真实情况是，如果接口和实现永远一比一、且不存在多个实现的需求，那这套接口设计大多是纯装饰，它只是把代码从“类少一点”改成了“文件多一倍”，没有带来任何可替换性收益。

什么时候需要接口？通常是有两个或更多现成实现，或者你非常确定短期内会出现第二个实现。比如同一套订单逻辑需要同时发给真实短信网关和测试用 FakeSender，接口就很有价值。如果只是追时髦，那建议先删掉接口，把类对类写好，等真的出现替换需求时再提取也不迟。我甚至可以说，想理解 DIP，靠的不是多写接口，而是多做“把依赖方向反转”的重构练习。

6.2 把方向搞反，接口做成了底层工具的马甲

这个坑比较隐蔽。很多代码里也有 Repository 接口，也有 Service 注入接口，看起来挺合理。但你翻进去看，那个 Repository 接口其实是 MyBatis 的 Mapper，方法参数又跟数据库表字段一一对应。这时候业务层虽然依赖的是接口，但接口的语义完全由底层数据表驱动。底层一改表结构，这个“接口”的签名就得跟着改，业务层依然会被波及。

真正的 DIP 要求接口语义以高层业务为准。OrderRepository 的方法应该叫 save(Order)，而不是叫 insertIntoOrderTable，FindUnpaidOrders 而不是 selectSpuByTransactionStatus。设计时，不妨假设你面前没有 MyBatis、没有 Redis，你按脑子里 “这个业务需要什么能力” 去定义接口。接口定义好之后，再考虑怎么让技术框架去实现它。顺序一反过来，接口自然就从“底层马甲”里摆脱出来了。

6.3 容器用得很爽，依赖关系却更乱了

Spring 这类依赖注入容器确实让 DIP 的落地变得轻松，但容器本身不会替你判断接口方向。我见过不少项目，代码里每个字段都用 @Autowired 或 @Resource 注入，看起来一个 new 都没有，可实际上整个项目的依赖关系完全失控了。

失控的原因很简单：容器把装配的权力分散到了所有类身上，大家都可以直接从容器里捞依赖。今天想在 A 服务里用一下 UserService，就在类里加一个字段注入；明天想在 B 服务里用 RedisTemplate，也直接注入。没有组合根这个概念去收敛“具体实现的选择”，项目就从“顺序清晰的对象组装”退化成“一堆类的随机关联”。DIP 解决的是依赖方向，DI 容器解决的是装配方式，两者别混为一谈。如果条件允许，做一个显式的配置类或者工厂方法，把所有基础设施实现集中注册进去，你再看依赖关系，会比翻几百个字段注入清爽得多。

6.4 哪些场景不值得强行上 DIP

DIP 不是银弹，它解决的是“稳定业务与易变实现”之间的耦合问题。如果一个模块只有一个实现，而且未来两三年看不到第二个实现，那你在它和调用方之间强行加接口，就是在给项目添乱。比如一个简单的金额计算工具，或者某个内部只会用一种算法的加密工具，直接调用具体类完全可以。

我的建议是先从观察痛苦入手，而不是从“设计原则”入手。当你真的因为更换一个底层实现而被迫修改了大量上层代码，或者因为没法注入 mock 而难以测试，那一刻才说明你与 DIP 的距离产生了。否则，过早抽象经常和过早优化一样，制造出一堆没人维护得动的中间层。

6.5 DIP 相关的常见问题速查表

为了方便你在具体代码评审或重构时快速定位，我整理了一张问题速查表。遇到类似信号，可以按下面的思路处理：

这张表解决的是“要不要抽象、在哪抽象”的判断问题。真到了代码层面，比如构造器循环依赖这种问题，处理方式不是继续加接口，而是回到设计层面重新梳理接口粒度。循环依赖常常是接口切错了边，拆掉其中一层的“互相依赖”，往往比调注入方式更有效。你在用 DIP 做重构时如果遇到循环依赖，先别急着换注入方式，看看是不是接口抽得过于细碎，把不该拆开的关系拆断了。

最后说几句实在话

我刚开始学依赖倒置原则时，犯过一个特别典型的错误：以为把项目里所有地方都加上 interface 就安全了，结果一个报表模块被我抽象出了六七层接口，最后连我自己都说不清每个接口存在的理由。真正开窍是在给订单模块做通知重构那一次。原来 OrderService 换一次通知渠道要改三个文件、跑两天回归；改成 DIP 风格以后，新增一个通知渠道只需要加一个类、改一行组装代码。看到这个对比我才明白，依赖倒置不是为了让你显得很会架构，而是为了让“稳定的东西”不被“易变的东西”拖着走。

如果你也想验证 DIP 有没有用，我不建议直接看书或者背结论。你可以从自己项目里挑一个变化很频繁的模块，比如某个发短信/发消息的地方，做一个快速重构：先定义一个业务侧的接口，再让旧实现去实现它，最后把组合根的 new 集中到入口。重构前记录一下“替换一种发送渠道需要改动几个文件”，重构后再记录一次。我敢说，对比出来的数字比任何理论都直观。

最后再分享一个很小但很实用的经验：判断抽象位置是否正确，有一个口诀——接口的名字应该像业务词汇，而不是像框架 API。OrderNotifier 像业务词，SmsSenderApi 像框架词。只要你能遵守这一条，DIP 就不会跑偏太多。下一步，你可以把它和接口隔离、以及组合模式配合起来，慢慢你会发现代码里的变化不再东一拳西一脚，而是会沿着你预设的缝隙老老实实裂开。