依赖关系是类间“使用但不拥有”的弱耦合联系，体现为方法参数、局部变量、静态调用或返回值，不通过字段持有实例，区别于关联、组合与继承；Spring通过依赖注入解耦，提升可测试性与可替换性。
Java中的依赖关系，本质是类与类之间“使用但不拥有”的弱耦合联系——一个类在运行时需要另一个类的服务，但不持有其引用，也不控制其生命周期。它是最轻量、最常见的一种UML关系，在OOP设计中既是灵活性的来源，也常是隐性耦合的温床。
依赖关系怎么写？看代码就明白
依赖通常体现在方法参数、局部变量、静态方法调用或返回值中，不通过字段（成员变量）持有对方实例：
- 方法参数传入： void process(OrderService service) —— OrderService 是当前类的依赖
- 方法内创建： List list = new ArrayList() —— ArrayList 是临时依赖（JDK类也算依赖）
- 静态调用： Collections.sort(items) —— Collections 是工具类依赖
- 返回值类型： public UserService getUserService() —— 调用方会依赖返回的 UserService
依赖 ≠ 关联/组合/继承，别混淆
关键区别在生命周期和结构强度：
-
依赖：临时、单向、无存储；比如Controller里new一个DTO，用完即弃
-
关联：有字段引用，可能长期存在；比如User类里有个 private Address address
-
组合/聚合：强整体-部分关系，涉及对象创建与销毁责任；比如Order包含多个OrderItem，Order销毁时Item通常也销毁
-
继承：is-a关系，编译期绑定；依赖是use-a，运行期才确定
为什么Spring特别强调“依赖注入”？
传统硬编码依赖（如直接 new ServiceImpl()）会导致测试难、替换难、复用差。Spring的DI把“谁来提供依赖”这件事从类内部剥离：
- 你只声明“我需要一个DataSource”，Spring负责找、创建、注入
- 测试时可轻松换为H2内存库；生产环境换成MySQL连接池
- 依赖变成配置项或注解（@Autowired），而非new语句——这是解耦的核心动作
哪些场景必须建模依赖？实际开发中很常见
不是所有依赖都要显式画UML图，但以下情况建议识别并管理：
-
跨层调用：Controller依赖Service，Service依赖Mapper —— 这是分层架构的骨架
-
策略切换：支付模块依赖PaymentStrategy接口，运行时根据渠道注入WechatPay或Alipay实现
-
第三方SDK集成：短信服务调用阿里云SMS SDK，SDK版本升级时若强依赖具体类，就容易出错
-
事件处理：OrderCreatedEvent发布后，多个监听器（库存服务、积分服务）依赖该事件对象 —— 事件就是典型的依赖媒介
基本上就这些。依赖关系看着简单，但它决定了代码能不能轻松测试、替换和演进。写代码时多问一句：“这个new/参数/调用，将来会不会变？我是不是把它写死了？”——答案往往是重构的起点。
