• 为什么Spring不建议使用基于字段的依赖注入

    • 在我们通过IDEA编写Spring的代码的时候，假如我们编写了如下代码：

    • IDEA会给我们一个warning警告：

    • 翻阅官方文档；我们会发现：

    • 大意就是强制依赖使用构造器注入，可选依赖使用setter注入
    • 那么这是为什么呢？使用字段注入又会导致什么问题呢？
    • 单一职责问题
    • 我们都知道，根据SOLID设计原则来讲，一个类的设计应该符合单一职责原则，就是一个类只能做一件功能，当我们使用基于字段注入的时候，随着业务的暴增，字段越来越多，我们是很难发现我们已经默默中违背了单一职责原则的
    • 但是如果我们使用基于构造器注入的方式，因为构造器注入的写法比较臃肿，所以它就在间接提醒我们，违背了单一职责原则，该做重构了

    • 可能产生NPE
    • 对于一个bean来说，它的初始化顺序为：
    • 静态变量或静态语句块 -> 实例变量或初始化语句块 -> 构造方法 -> @Autowired
    • 所以，在静态语句块，初始化语句块，构造方法中使用Autowired表明的字段，都会引起NPE问题

    • 相反，用构造器的DI，就会实例化对象在使用的过程中，字段一定不为空
    • 隐藏依赖
    • 对于一个正常的使用依赖注入的Bean来说，它应该“显式”的通知容器，自己需要哪些Bean，可以通过构造器通知，public的setter方法通知，这些设计都是没问题的
    • 但是对于private的filed来说，从设计的角度来讲，外部的容器是不应该感知到bean内部的private内容的，所以理论上，private的filed是没办法通知到容器的（不考虑反射，单从设计角度理解），所以从这个角度来看，我们不能通过字段注入
    • 不利于测试
    • 很明显，使用了Autowired注解，说明这个类依赖了Spring容器，这让我们在进行UT的时候必须要启动一个Spring容器才可以测试这个类，显然太麻烦，这种测试方式非常重，对于大型项目来说，往往启动一个容器就要好几分钟，这样非常耽误时间
    • 不过，如果使用构造器的依赖注入就不会有这种问题，或者，我们可以使用Resource注解也可以解决上述问题
    • Spring支持哪些注入方式
    • 1. 字段注入

    • 2. 构造器注入

    • 3. setter注入

    • 使用构造器注入可能有哪些问题
    • 如果我们两个bean循环依赖的话，构造器注入就会抛出异常：

    • 如果两个类彼此循环引用，那说明代码的设计一定是有问题的
    • 如果临时解决不了，我们可以在某一个构造器中加入@Lazy 注解，让一个类延迟初始化即可

  • 相关阅读:
    sql：SQL优化知识点记录（九）
    C Primer Plus(6) 中文版 第2章 C语言概述 2.9 关键概念 2.10 本章小结
    【云原生进阶之PaaS中间件】第一章Redis-1.5.1安装配置
    iOS 添加震动效果
    数字逻辑·组合逻辑设计【续】
    访问Apache Tomcat的虚拟主机管理页面
    Leetcode226.翻转二叉树
    keil4工程创建并进行流水灯实验
    [oeasy]python0014_二进制_binary_bin
    [附源码]SSM计算机毕业设计影院售票系统JAVA
  • 原文地址：https://blog.csdn.net/weixin_59624686/article/details/133555608