为什么@Autowired 在属性上被警告，在 setter 方法上不被警告

在 Spring 开发中，@Autowired 注解常用于实现依赖注入。它可以应用于类的 属性、构造器 或 setter 方法 上。然而，当 @Autowired 注解在 属性 上使用时，IntelliJ IDEA 等 IDE 会给出 Field injection is not recommended 的警告，而在 setter 方法 上使用 @Autowired 时却不会出现这个警告。

1. 为什么 @Autowired 在属性上被警告？

1.1 隐式依赖注入

当 @Autowired 注解应用于类的 属性 上时，Spring 会直接注入该属性，而不通过构造函数或 setter 方法显式地传递依赖项。这种注入方式称为 字段注入（Field Injection）。

字段注入 的缺点主要体现在以下几个方面：

1. 隐式依赖：

   • 通过字段注入，类的依赖关系是隐式的，无法在类的构造器或方法中显式地看到这些依赖。相对而言，构造器注入 和 setter 注入 可以使依赖关系更加明确。
   • 由于字段依赖是隐式注入的，开发者很难在不查看容器配置的情况下，快速了解一个类的所有依赖项。

2. 难以进行单元测试：

   • 字段注入的属性是隐式注入的，无法通过构造函数或 setter 方法显式传递。在单元测试中，手动注入模拟（mock）对象时，需要通过反射或者测试框架自动注入，这增加了测试的复杂性。
   • 与此相比，构造器注入和 setter 注入会使依赖关系显式可见，能够更方便地进行 单元测试。

3. 违反依赖倒置原则（DIP）：

   • 在 依赖倒置原则 中，依赖关系应该通过 接口 或 抽象 进行注入，而不应该在类内部直接依赖于具体的实现。字段注入使得类的依赖更加隐式，可能会增加代码的耦合性。

1.2 IDE 的警告：Field injection is not recommended

IntelliJ IDEA 等 IDE 会根据这些设计缺点发出警告，提示 @Autowired 注解不推荐使用在属性上。字段注入的方式可能会导致代码的可维护性差，容易出现一些潜在问题（如不清晰的依赖关系和难以测试的代码）。

---

2. 为什么 @Autowired 在 setter 方法上不被警告？

当 @Autowired 用于 setter 方法 时，Spring 会通过 setter 注入 方式将依赖项注入到对象的属性中。与字段注入不同，setter 注入方式具有以下优势：

2.1 显式依赖注入

• 显式依赖关系：使用 setter 方法注入，开发者可以明确看到类所依赖的组件。通过查看类的 setter 方法，其他开发者可以轻松理解该类的依赖关系。

  public class MyService {
      private MyRepository repository;
      
      @Autowired
      public void setRepository(MyRepository repository) {
          this.repository = repository;
      }
  }
  

• 符合依赖注入的设计原则：通过构造函数或 setter 方法注入依赖项，可以使类的依赖关系更加清晰，符合面向对象设计中的 依赖注入 和 单一职责原则。

2.2 可选的依赖注入

• setter 注入适用于一些 可选依赖 的场景。如果某个依赖是可选的，可以通过 setter 方法来灵活注入，而不需要在构造器中强制要求依赖项的传入。

  @Autowired
  public void setOptionalDependency(Optional<Dependency> dependency) {
      this.dependency = dependency.orElse(null);
  }
  

2.3 易于测试

• 由于 setter 方法可以手动设置对象的依赖，因此它可以使单元测试变得更简单。你可以通过 setter 方法为对象注入模拟（mock）依赖项，而不需要通过反射等复杂手段。

  MyService myService = new MyService();
  myService.setRepository(mockRepository);
  

---

3. 构造器注入 vs 字段注入 vs Setter 注入

3.1 构造器注入（推荐）

构造器注入 是 最推荐的依赖注入方式，它具有以下优势：

• 强制依赖关系：通过构造器传递依赖项，可以确保所有的依赖项在对象创建时就已经被正确地注入。
• 不可变性：构造器注入使得依赖项在对象创建时就被初始化，避免了运行时更改依赖项。
• 易于测试：构造器注入使得所有的依赖项在构造时就显式提供，便于进行单元测试。

public class MyService {
    private final MyRepository repository;
    
    @Autowired
    public MyService(MyRepository repository) {
        this.repository = repository;
    }
}

3.2 Setter 注入（次推荐）

Setter 注入 是一个灵活的选择，适用于依赖关系较为可选或后期可更改的场景。它具有以下特点：

• 灵活性：可以在对象创建后修改依赖项。
• 适用于可选依赖：如果某些依赖项是可选的，setter 注入能够方便地管理。

public class MyService {
    private MyRepository repository;

    @Autowired
    public void setRepository(MyRepository repository) {
        this.repository = repository;
    }
}

3.3 字段注入（不推荐）

字段注入 是最简单的注入方式，但并不推荐使用，原因已在前面提到。字段注入具有以下缺点：

• 不清晰的依赖关系：依赖项通过字段注入，难以通过构造器或 setter 明确看到类的依赖。
• 难以测试：无法通过构造函数直接注入模拟对象，增加了单元测试的难度。

public class MyService {
    @Autowired
    private MyRepository repository;
}

---

4. 总结

• 字段注入不推荐，因为它将依赖关系隐藏在字段中，难以清晰表达依赖项，增加了测试的复杂性。
• 推荐使用构造器注入，它提供了最强的类型安全性和不可变性，增强了代码的可维护性和测试性。
• Setter 注入适用于可选依赖，但在依赖较多时容易导致依赖关系变得模糊，因此需要谨慎使用。

总体而言，使用构造器注入和 setter 注入能够使代码更清晰、易于维护，同时支持更好的单元测试。如果 IDE 提示 Field injection is not recommended，这意味着你可以考虑改用构造器注入或 setter 注入，以便提升代码质量。 🚀