17370845950

Java中依赖关系指类在方法中临时使用另一类对象，用完即弃，不持有其引用；典型写法有方法参数、局部变量和静态调用，核心特征是无成员变量、不管理生命周期。

Java 中的依赖关系，就是“我用你，但不养你”——一个类在某个方法里临时用到另一个类的对象，用完即弃，不持有、不管理生命周期。

依赖关系怎么写？看这三种典型写法

依赖不是靠字段存着，而是靠“当场调用”体现。它最轻量，也最容易被误当成关联或组合。

• 方法参数：最标准的依赖形式，比如 public void send(EmailService service) —— 调用时才传入，类本身没存这个 service

• 

  局部变量：方法内部 new 出来就用，比如 List list = new ArrayList()，ArrayList 就是当前方法对 JDK 类的临时依赖
• 静态调用：比如 Collections.sort(items)，Collections 是工具类，没实例化，只借它的静态方法一用

为什么依赖容易被混淆？关键看“有没有字段引用”

很多人把 private EmailService emailService; 也叫依赖，其实那是关联（甚至可能是聚合/组合）。真正的依赖必须满足：没有成员变量、不控制对方生命周期、用完就丢。

• ✅ 依赖：void process(Order order, PaymentGateway gateway) —— 参数传入，无字段
• ❌ 不是依赖：private PaymentGateway gateway = new AlipayGateway(); —— 这是硬编码关联，耦合已升高
• ⚠️ 注意：Spring 的 @Autowired 注入字段，表面像依赖，实际是框架替你做了“解耦后的关联”，不能反推为语言层面的依赖关系

依赖关系在 UML 和 Spring 中的意义完全不同

UML 里的依赖（虚线箭头）强调设计时的弱耦合意图；而 Spring 说的“依赖注入”，其实是把原本硬编码的关联关系外移，让它可配置、可替换。两者语义错位，但目标一致：降低修改成本。

• UML 依赖：画图时标出“这里会用到”，不承诺谁创建、谁销毁
• Spring 依赖：运行时由容器决定给哪个实现，比如测试时注入 MockEmailService，生产用 SmtpEmailService
• 坑点：过度依赖 @Autowired 字段注入，会让类失去无容器环境下的可测试性——构造器注入才是更贴近“依赖”本意的做法

class UserService {
    private final NotificationService notifier; // 构造器注入，明确表达“我需要一个通知服务”
    public UserService(NotificationService notifier) {
        this.notifier = notifier; // 不 new，不 static，不 null 默认值
    }
    public void register(User user) {
        notifier.sendWelcome(user); // 这里才是真正的“使用”，即依赖行为
    }
}

真正难的不是识别依赖，而是判断“该不该让它只是依赖”。比如日志对象 Logger，几乎每个类都用，但它既不该被 new，也不该被注入字段——它属于基础设施，应通过 SLF4J 静态获取，这才是符合依赖本质的用法。