java:控制反转(IoC)的两种方式：依赖查找(DL)、依赖注入(DI)

原创于 2025-09-21 14:02:18 发布 · 679 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言

首先，理解控制反转（IoC）的核心思想

控制反转是一种设计原则，用于解耦程序组件。它的核心是将对象的创建、依赖装配和生命周期的控制权从应用程序代码中“反转”给一个外部容器或框架。

传统控制流程（正转）：在普通程序中，当对象A需要依赖对象B时，A会主动地通过 new B() 来创建和管理B的生命周期。控制权在A手中。
控制反转（IoC）：对象A不再负责创建或查找其依赖的对象B。它只需要声明“我需要一个B”。由一个IoC容器来负责创建B的实例，并在合适的时机（比如在创建A时）将它“注入”给A。控制权从A反转到了IoC容器。

现在，我们来看它的主要实现方式。

控制反转（IoC）的两种主要实现方式

IoC是一个原则，它主要通过两种模式来实现：依赖查找（DL） 和 依赖注入（DI）。其中，依赖注入是目前绝对的主流和首选方式。

1. 依赖查找 (Dependency Lookup, DL)

依赖查找是IoC的一种实现方式，但它是一种更主动的模式。对象需要依赖时，会主动向一个“容器”或“注册表”发起请求来查找它所依赖的对象。

它可以进一步分为两种类型：

依赖拉取 (Dependency Pull)：这是最常见的一种查找方式。应用程序在启动或需要时，从一个全局可访问的注册中心（容器）中“拉取”它所需要的依赖。
- 例子：Java 的 JNDI (Java Naming and Directory Interface) 就是典型的依赖拉取。代码需要数据源时，主动去JNDI上下文中查找。
- 代码示例：
- ```
// 1. 初始化容器上下文（通常在应用启动时完成一次）
Context ctx = new InitialContext();
// 2. 应用程序主动从容器中“拉取”依赖
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myDataSource");
```
- 特点：代码主动参与了依赖的获取过程，与控制反转“被动接受”的理念有些相悖，因此现在较少使用。
上下文依赖查找 (Contextualized Dependency Lookup, CDL)：对象通过其自身的上下文环境来查找依赖，而不是全局上下文。它实现了某种程度的IoC，因为对象不需要知道查找的具体细节，但它仍然包含查找的逻辑。

小结：依赖查找是一种更古老、更繁琐的方式，需要代码主动参与，会产生对容器API的依赖，污染了代码。

2. 依赖注入 (Dependency Injection, DI) - 主流方式

依赖注入是IoC最流行、最彻底的实现方式。在DI模式下，对象是被动地接收其依赖项，而不是自己去查找或创建。容器负责在创建对象时，自动将其所依赖的实例“注入”给它。

依赖注入主要有三种常见的实现方式：

a) 构造函数注入 (Constructor Injection)

通过类的构造函数将依赖项传入。

优点：
- 可以保证依赖不可变（使用 final 关键字）。
- 可以保证依赖完全初始化，在构造完成后即可使用（对象状态完整）。
- 易于测试，因为你可以通过构造函数直接传入模拟对象（Mock）。
代码示例：

java

public class UserService {
    // 依赖
    private final UserRepository userRepo;
    
    // 容器通过构造函数注入依赖
    public UserService(UserRepository userRepo) {
        this.userRepo = userRepo;
    }
    
    public void doSomething() {
        userRepo.findUser(...); // 直接使用依赖
    }
}

b) Setter方法注入 (Setter Injection)

通过类的Setter方法将依赖项传入。

优点：
- 灵活性高，允许在对象创建后重新注入依赖（但需谨慎使用）。
- 更适合可选依赖。
缺点：
- 对象可能在某个时间段内处于不完整状态（因为依赖可能事后才被注入）。

代码示例：

public class UserService {
    private UserRepository userRepo;
    
    // 容器通过Setter方法注入依赖
    public void setUserRepository(UserRepository userRepo) {
        this.userRepo = userRepo;
    }
    
    public void doSomething() {
        userRepo.findUser(...);
    }
}

c) 字段注入 (Field Injection)

通过直接给类的字段赋值来注入依赖（通常利用反射机制）。

优点：
- 代码非常简洁，没有多余的代码。
缺点：
- 不易测试：你必须使用反射来注入依赖，或者依赖IoC容器来初始化对象进行测试。
- 破坏了封装性（字段通常是 private 的，但被容器通过反射强制设置）。
- 无法声明不可变字段（final）。
- 容易导致空指针异常（如果容器配置错误，字段可能是 null）。

代码示例（通常由注解驱动）：

public class UserService {
    @Autowired // Spring的注解，表示让容器自动注入这个字段
    private UserRepository userRepo;
    
    public void doSomething() {
        userRepo.findUser(...);
    }
}

最佳实践：优先使用构造函数注入，因为它能产生更安全、不可变且完全初始化的对象，并且非常利于测试。Setter注入用于可选依赖。字段注入虽然方便，但应尽量避免在正式项目中使用。

现实世界中的IoC容器

上述的依赖注入需要有“人”来执行，这个“人”就是 IoC容器（也称为DI容器）。它的主要职责是：

创建和管理对象：这些对象在容器中通常被称为 Bean 或组件。
配置依赖：根据配置（XML、注解或Java代码），将依赖注入到需要它们的对象中。
管理生命周期：负责调用初始化方法和销毁方法。

著名的IoC容器实现包括：

Spring Framework：最著名的Java IoC容器，其 ApplicationContext 就是核心容器。
Google Guice：一个轻量级的、基于注解的DI框架。
Jakarta CDI (Contexts and Dependency Injection)：一个Java企业级标准（用于Jakarta EE/Java EE），如 Weld 是其参考实现。
** .NET Core 内置的DI容器**：在.NET生态中同样广泛使用。

总结

实现方式	描述	优点	缺点
依赖查找 (DL)	对象主动向容器请求依赖	相对传统方式有一定解耦	代码依赖容器API，不够纯粹，已不常用
依赖注入 (DI)	容器主动将依赖注入到对象中	彻底解耦，代码纯净，易于测试	-
┣ 构造函数注入	通过构造函数传入依赖	推荐首选。保证不可变和完全初始化	参数过多时构造函数会很长
┣ Setter注入	通过Setter方法传入依赖	灵活，适合可选依赖	对象状态可能暂时不完整
┗ 字段注入	通过反射直接给字段赋值	代码非常简洁	不推荐。不易测试，不安全

简单来说，控制反转（IoC）是一种思想，而依赖注入（DI）是实现这种思想的最主流、最有效的方法。在现代Java开发中，当你提到IoC，基本上就是在指代基于依赖注入的设计模式。