利用依赖倒置原则重构高耦合的遗留代码时常见的隐蔽陷阱

一、依赖倒置到底是什么，为什么会踩坑

想象一下你家的插座。墙上的插座不会管插在上面的是电风扇、手机充电器还是空气净化器，只要它们都使用同一个标准的插头，插座就能供电。这就是一种“倒置”：原本电器要直接接到墙里的电线上，现在中间多了一个插座标准，电器的实现反倒要遵守这个标准才能用上电。

代码里的依赖倒置原则也是这么回事。所谓的“高层模块”比如订单服务，它就相当于那个插座；“底层模块”比如邮件发送器、短信发送器，相当于各种电器。高层不应该自己去创建一个具体的电器，而应该面向一个抽象的插头标准编程。这样将来从邮件换成短信，只是换一个电器插上去，订单服务那面墙根本不用动。

不过，很多人在重构高耦合的遗留代码时，只记住了“抽个接口”这一招，结果不但没解开，反而挖出更多坑。下面这些坑，每一个我都见过有人在生产环境里踩过。

二、最常见的陷阱：接口抽了，依赖还在原地

2.1 抽了个寂寞：接口里藏着具体实现

先看一段很典型的遗留代码。订单服务里直接创建了一个邮件发送器，下单之后发一条邮件通知。

// 技术栈：Java 8+

// 邮件发送器，负责往指定地址发邮件
class EmailSender {
    public void send(String message) {
        System.out.println("发送邮件：" + message);
    }
}

// 订单服务，这里直接依赖了 EmailSender 这个具体类
public class OrderService {
    private EmailSender emailSender = new EmailSender();

    public void placeOrder(String orderId) {
        // 这里还省略了下单的各种业务操作...
        emailSender.send("订单【" + orderId + "】已创建");
    }
}

这里的问题很明显：订单服务和邮件发送器绑死了。如果有一天你想把通知方式换成短信，你得去改订单服务的代码，甚至可能改动几十个类似的地方。按照依赖倒置的“药方”，先定义一个发送器接口。

// 技术栈：Java 8+

// 定义一个抽象的通知接口
public interface MessageSender {
    void send(String message);
}

然后让邮件发送器实现它。看起来一切顺利，但是如果你把订单服务改成这样，那就掉进第一个坑了：

// 技术栈：Java 8+

// 邮件发送器实现接口
class EmailSender implements MessageSender {
    public void send(String message) {
        System.out.println("发送邮件：" + message);
    }
}

// 看起来用了接口，但内部还是直接创建了一个具体发送器
public class OrderService {
    private MessageSender sender = new EmailSender(); // 依赖根本没被倒置

    public void placeOrder(String orderId) {
        sender.send("订单【" + orderId + "】已创建");
    }
}

这里字段类型是接口，可它依然自己创建了一个具体发送器。这意味着订单服务仍然绑死了邮件发送器，只是给变量换了一张皮。真正的依赖倒置，应该是把具体实现交给外部，自己只认接口。最推荐的方式是构造函数注入：

// 技术栈：Java 8+

public class OrderService {
    private final MessageSender sender;

    // 依赖由外部传入，OrderService 不再自己创建
    public OrderService(MessageSender sender) {
        this.sender = sender;
    }

    public void placeOrder(String orderId) {
        sender.send("订单【" + orderId + "】已创建");
    }
}

这样改完，订单服务就彻底不关心发送器是谁了。你传一个邮件发送器它就发邮件，传一个短信发送器它就发短信。这就是“控制反转”里常说的那句话：别打电话给我们，我们会打给你。对象不再自己去找依赖，而是等着外部把依赖递给它。

2.2 接口拆得太碎，反倒被细节绑架

顺着“面向接口”的思路，有些同学会用力过猛。比如想把邮件和短信分开，于是定义了两个接口：

// 技术栈：Java 8+

// 专门发邮件的接口
public interface EmailSendable {
    void sendEmail(String message);
}

// 专门发短信的接口
public interface SmsSendable {
    void sendSms(String message);
}

然后订单服务为了既能发邮件又能发短信，被迫同时依赖这两个接口：

// 技术栈：Java 8+

public class OrderService {
    private final EmailSendable emailSender;
    private final SmsSendable smsSender;

    public OrderService(EmailSendable emailSender, SmsSendable smsSender) {
        this.emailSender = emailSender;
        this.smsSender = smsSender;
    }

    public void placeOrder(String orderId) {
        // 业务逻辑被迫知道“邮件”和“短信”的细节
        emailSender.sendEmail("订单【" + orderId + "】已创建");
        smsSender.sendSms("订单【" + orderId + "】已创建");
    }
}

这就是第二个坑：接口的粒度不该跟着底层实现走，而该跟着高层调用的意图走。订单服务其实只想要“通知一下用户”，它并不需要知道这个消息是邮件还是短信。如果你把接口拆成两个，那么以后新增一个“飞书通知”，你还要去改订单服务，再塞一个接口进来，这就不叫解耦，这叫换一种方式耦合。正确做法还是保留一个抽象的通知接口，不同实现自己决定怎么发：

// 技术栈：Java 8+

// 高层只依赖这个抽象
public interface MessageSender {
    void send(String message);
}

// 邮件实现
class EmailSender implements MessageSender {
    public void send(String message) {
        System.out.println("发送邮件：" + message);
    }
}

// 短信实现，想加就加，OrderService 不用动
class SmsSender implements MessageSender {
    public void send(String message) {
        System.out.println("发送短信：" + message);
    }
}

所以，接口不是越细越好，而是越符合“调用者意图”越好。

三、依赖该从哪里来：注入方式的几个坑

解决了接口问题，下一个问题是：既然不能在自己内部创建依赖，那依赖从哪里来？很多人不引入容器，选择手动创建并传入。于是踩到第三个坑。

3.1 手动注入变成到处复制粘贴

假设你已经在主程序里手动组装了一个订单服务：

// 技术栈：Java 8+

public class Main {
    public static void main(String[] args) {
        MessageSender sender = new EmailSender();
        OrderService service = new OrderService(sender); // 手动注入
        service.placeOrder("A001");
    }
}

目前只组装了一次，你觉得挺好。但遗留代码里，可能有好几个入口都需要这个订单服务，比如老的接口类、定时任务、消息监听器。每个入口都得把订单服务和新发送器绑在一起重新创建一遍。等到通知方式换成短信，你就要满项目地找这些散落的组装代码。说到底，手动注入需要搭配一个“组装中枢”。最简单的做法是先做一个工厂方法：

// 技术栈：Java 8+

// 用一个工厂类来集中管理依赖的组装
public class ServiceFactory {
    public static OrderService createOrderService() {
        MessageSender sender = new EmailSender();
        return new OrderService(sender);
    }
}

之后所有入口都去调用工厂里的创建方法，换实现的时候只改这一个工厂就够了。这是一种非常轻量的“控制反转”，虽然没有 Spring 那么智能，但对于中小型遗留项目来说，够用且好懂。

3.2 循环依赖，一启动就完蛋

如果你幸运地用上了容器，或者干脆手动构造，还可能碰到循环依赖。两个类互相需要对方，这在遗留代码里很常见。看这个例子：

// 技术栈：Java 8+

// A 需要 B
public class A {
    private final B b;
    public A(B b) {
        this.b = b;
    }
}

// B 需要 A
public class B {
    private final A a;
    public B(A a) {
        this.a = a;
    }
}

你试图创建 A 时，需要先创建 B；创建 B 时，又需要先创建 A。这就成了死循环。有些同学会选择用 setter 注入来绕开：

// 技术栈：Java 8+

public class A {
    private B b;
    public void setB(B b) {
        this.b = b;
    }
}

public class B {
    private A a;
    public void setA(A a) {
        this.a = a;
    }
}

// 手动绕开构造器死循环
A a = new A();
B b = new B();
a.setB(b);
b.setA(a);

这确实能让程序启动起来，但我要提醒你：循环依赖本身就是一种坏味道。你用 setter 绕过，等于把故障从启动阶段推迟到运行阶段。一旦某个 setter 忘了调用，运行时就是空指针。这个时候应该停下来想想，A 和 B 是不是可以拆出一份公共的部分，让它们都依赖那份公共代码，而不是互相依赖。依赖倒置要解决的从来不是“怎么把循环依赖注入成功”，而是“怎么让高层内部不再乱成一团”。

四、藏在角落里的依赖：静态方法和全局访问

就算你把构造函数、工厂都理顺了，遗留代码里还藏着一些“钉子户”式的依赖。它们不通过构造函数、不通过接口，直接藏在方法体内部。

4.1 静态方法这个钉子户

最典型的就是静态工具类。看看这段代码：

// 技术栈：Java 8+

// 支付工具类，所有方法都是静态的
public class PaymentUtils {
    public static void charge(String orderId, double money) {
        // 调用支付网关的代码省略...
        System.out.println("扣款：" + money);
    }
}

// 订单服务虽然注入了 MessageSender，但支付还是走的静态方法
public class OrderService {
    private final MessageSender sender;

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

    public void placeOrder(String orderId, double money) {
        PaymentUtils.charge(orderId, money); // 隐藏依赖
        sender.send("订单" + orderId + "支付成功");
    }
}

这段代码里，订单服务的行为被那个支付工具类控制着。你想测试它，只能在测试里去 mock 静态方法，或者真的连上支付网关。你想换一个支付宝支付，发现得去改订单服务的源码。这就是隐藏依赖的威力。要消除它，就得把静态方法包装成实例接口：

// 技术栈：Java 8+

// 把支付也定义成接口
public interface PaymentService {
    void charge(String orderId, double money);
}

// 微信支付的实现
class WeChatPayService implements PaymentService {
    public void charge(String orderId, double money) {
        System.out.println("微信支付扣款：" + money);
    }
}

// 改造后的 OrderService 只依赖接口
public class OrderService {
    private final MessageSender sender;
    private final PaymentService payment;

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

    public void placeOrder(String orderId, double money) {
        payment.charge(orderId, money);
        sender.send("订单" + orderId + "支付成功");
    }
}

这样，支付渠道也能和邮件一样随插随拔了。注意，静态方法本身不是坏味道，但当你需要做依赖倒置时，它就是那只躲在墙角的蟑螂——必须揪出来。

4.2 服务定位器换汤不换药

有人为了省去到处传依赖，搞一个全局的“服务定位器”，所有依赖都从里面取。看起来优雅，实际上是用一个更大的隐藏依赖替换了原来的具体依赖：

// 技术栈：Java 8+

// 一个简单的服务定位器，里面保存了一个发送器
public class ServiceLocator {
    private static MessageSender sender = new EmailSender();

    public static MessageSender getSender() {
        return sender;
    }
}

// 订单服务从定位器里取依赖
public class OrderService {
    public void placeOrder(String orderId) {
        MessageSender sender = ServiceLocator.getSender(); // 依赖从天而降
        sender.send("订单" + orderId + "已创建");
    }
}

这样看起来订单服务没有直接创建具体发送器，但它依赖了服务定位器这个全局变量。这个全局变量是真正意义上的共享状态，多线程环境下一不小心就会被破坏。而且测试时，如果你忘了重置它，测试之间还会互相传染。服务定位器模式并不是不能用，但在重构依赖倒置的语境下，它会让依赖变得隐蔽。我建议把它当作临时跳板，不要当终点。

五、重构后为什么还是乱？

把静态方法和全局变量都清理干净，你以为完事了？还有两个坑藏在更深处。

5.1 生命周期不匹配，数据变“串台”

依赖注入解决的是“谁创建谁”的问题，但它解决不了“依赖应该活多久”的问题。看这个发送器实现：

// 技术栈：Java 8+

// 一个有状态的发送器，保存了一条“上一次消息”
public class LongLiveSender implements MessageSender {
    private String lastMessage; // 有状态

    public void send(String message) {
        this.lastMessage = message;
        System.out.println("发送：" + message);
    }

    public String getLastMessage() {
        return lastMessage;
    }
}

如果你的容器把这个发送器当成单例，全局只有一个实例，那么两个线程同时调用发送方法的时候，那个保存消息的字段就会互相覆盖。订单 A 刚发送完，订单 B 马上把这个字段改成了自己的内容。这看起来像“串台”，实际上是生命周期不匹配。正确做法是根据依赖的用途决定作用域：像发送器这种如果内部没有可变状态，做成单例没问题；但如果它确实有状态，那就该按请求创建。遗留代码重构时，要特别留意那些带着成员变量的“服务”，别因为注入了就忽略了它们的存活范围。

5.2 测试时过度Mock，测了个寂寞

依赖倒置带来的一个好处是测试方便。但有些人把方便变成了“滥用”——所有依赖全部 mock，连真实的逻辑都不测了。比如下面这个测试：

// 技术栈：Java 8+ / JUnit 5 / Mockito

import static org.mockito.Mockito.*;

class OrderServiceTest {
    @Test
    void placeOrder_shouldChargeAndSend() {
        PaymentService payment = mock(PaymentService.class);
        MessageSender sender = mock(MessageSender.class);
        OrderService service = new OrderService(sender, payment);

        service.placeOrder("A001", 99.0);
    }
}

这个测试跑完，只是验证了订单服务没有抛异常，但如果里面某个业务逻辑写错了，比如金额没算对，这个测试是发现不了的。建议的姿势是：单元测试里不要 mock 所有东西，只 mock 那些访问外部资源的依赖，比如网络、数据库、文件系统；其他尽量使用真实实现。你甚至可以给订单服务配上假的发送器，但假的发送器要有真实的行为，而不是一个只会被调用的空壳。测试的目的是守住业务，不是凑覆盖率。

六、什么时候适合做这种重构？优缺点和注意事项

到这里，我们已经把最常见的几个隐蔽陷阱都过了一遍。最后来说说这个重构本身。

6.1 应用场景

不是所有代码都值得做依赖倒置。如果你项目里只有几个类，而且不会怎么变化，硬套这个原则反而会拖慢开发速度。比较适合做依赖倒置重构的场景有三类：第一，遗留代码里有一个高层逻辑被多个具体实现纠缠，团队每次改需求都害怕碰哪里；第二，系统需要支持多种外部渠道，比如短信、邮件、支付渠道，而且经常要加新的；第三，你正在写单元测试，但发现根本没法绕开那些具体依赖。这三种情况下，依赖倒置能帮上大忙。

6.2 技术优缺点

优点非常直观：高层业务逻辑变得稳定，底层实现可以任意替换；代码的可测试性提高，依赖可以被桩或者替换；所有对象的组装集中在一个地方，整个系统的依赖图更清晰。缺点也不能忽视：类变多了，接口变多了，新同学看代码要翻很多文件；如果接口设计得不好，反而不容易看懂程序的真实逻辑；另外，如果团队没有形成统一规范，很容易出现接口满天飞或者接口形同虚设两个极端。

6.3 注意事项

总结出几个具体的注意点，给想动手重构的人一些参考。第一，接口从调用方的真实需求出发，不要从现有实现的方法列表里抄。第二，构造函数注入优先于 setter 注入，尽量避免依赖在运行中被偷偷替换。第三，遇到循环依赖，先想办法拆结构，别用 setter 掩盖问题。第四，静态方法和全局变量要专项清理，别只把表面上的创建语句改掉就完事。第五，认真思考依赖对象的生命周期，有状态的依赖不要无脑设为单例。第六，测试时保持理性，mock 不是越少越好，也不是越多越好，关键是让测试真正验证到业务规则。

七、总结

依赖倒置原则，说白了就是让高层模块不要低头盯着底层模块的实现，而要抬头看着抽象来设计代码。但重构遗留代码时，光会抽接口远远不够。接口可能只是一个空壳，依赖可能藏在静态方法里，对象的生命周期可能引起数据串台，测试可能因为过度 mock 而失去意义。这些问题每一个都够让一个认真写代码的朋友头疼一阵子。希望你在未来的重构路上，能一眼认出这些坑，绕过去，把代码改得干净、踏实。