【注解使用】使用@Autowired注解警告Field injection is not recommended

简介: 【注解使用】使用@Autowired注解警告Field injection is not recommended

Field injection is not recommended(不再推荐使用字段注入)

一、背景描述

最近升级了Idea工具,然后在写代码时,突然发现报波浪线,说明这个地方不严谨,于是就找解决办法。

二、出现原因

查阅了相关文档了解了一下,原来这个提示是spring framerwork 4.0以后开始出现的,spring 4.0开始就不推荐使用属性注入,改为推荐构造器注入和setter注入。

由于此注入方式是三种依赖注入方式中的一种,它是基于字段的依赖注入,spring 4.0以后发现使用此注解有很多缺陷,例如:

2.1 不允许声明不可变域

基于字段的依赖注入在声明为final/immutable的字段上不起作用,因为这些字段必须在类实例化时实例化。声明不可变依赖项的惟一方法是使用基于构造器的依赖注入。

2.2 容易违反单一职责设计原则

在面向对象的编程中,五大设计原则SOLID被广泛应用,(国内一般为六大设计原则),用以提高代码的重用性,可读性,可靠性和可维护性

S在SOLID中代表单一职责原则,即即一个类应该只负责一项职责,这个类提供的所有服务都应该只为它负责的职责服务。

使用基于字段的依赖注入,高频使用的类随着时间的推移,我们会在类中逐渐添加越来越多的依赖项,我们用着很爽,很容易忽略类中的依赖已经太多了。但是如果使用基于构造函数的依赖注入,随着越来越多的依赖项被添加到类中,构造函数会变得越来越大,我们一眼就可以察觉到哪里不对劲。

有一个有超过10个参数的构造函数是一个明显的信号,表明类已经转变一个大而全的功能合集,需要将类分割成更小、更容易维护的块。

因此,尽管属性注入并不是破坏单一责任原则的直接原因,但它隐藏了信号,使我们很容易忽略这些信号。

2.3 与依赖注入容器紧密耦合

使用基于字段的依赖注入的主要原因是为了避免getter和setter的样板代码或为类创建构造函数。最后,这意味着设置这些字段的唯一方法是通过Spring容器实例化类并使用反射注入它们,否则字段将保持null。

依赖注入设计模式将类依赖项的创建与类本身分离开来,并将此责任转移到类注入容器,从而允许程序设计解耦,并遵循单一职责和依赖项倒置原则(同样可靠)。因此,通过自动装配(autowiring)字段来实现的类的解耦,最终会因为再次与类注入容器(在本例中是Spring)耦合而丢失,从而使类在Spring容器之外变得无用。

这意味着,如果您想在应用程序容器之外使用您的类,例如用于单元测试,您将被迫使用Spring容器来实例化您的类,因为没有其他可能的方法(除了反射)来设置自动装配字段。

2.4 隐藏依赖关系

在使用依赖注入时,受影响的类应该使用公共接口清楚地公开这些依赖项,方法是在构造函数中公开所需的依赖项,或者使用方法(setter)公开可选的依赖项。当使用基于字段的依赖注入时,实质上是将这些依赖对外隐藏了。

三、解决方案

我一般比较懒,在项目中由@Autowired直接改为@Resource注解了,方法简单粗暴,哈哈

3.1 使用@Resource

将@Autowired注解改为@Resource注解,即可解决这个问题

3.2 使用于构造函数的依赖注入

下图中使用的是lombok注解的方式添加构造函数。

下图中使用的是显示的 方式添加构造函数。

3.3 使用于Setter的依赖注入

基于Setter的DI是由容器在调用无参数构造函数或无参数静态工厂方法实例化bean后,在bean上调用Setter方法来完成的。

下面的示例显示了一个只能使用纯setter注入进行依赖注入的类。这个类是传统的Java。它是一个POJO,不依赖于特定于容器的接口、基类或注释。

public class SimpleMovieLister {
    // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;
    // a setter method so that the Spring container can inject a MovieFinder
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
    // business logic that actually uses the injected MovieFinder is omitted...
}

3.4 个人总结

我们已经看到,基于字段的注入应该尽可能地避免,因为它有许多缺点,无论它看起来多么优雅。推荐的方法是使用基于构造函数和基于setter的依赖注入。对于必需的依赖,建议使用基于构造函数的注入,设置它们为不可变的,并防止它们为null。对于可选的依赖项,建议使用基于sett的注入。对于这一点Spring官方文档也给出了相关的说明:Constructor-based or setter-based DI?

四、参考文档

1、Field injection is not recommended – Spring IOC:Field injection is not recommended – Spring IOC - Marc Nuri

3、Field injection is not recommended(不再推荐使用字段注入):Field injection is not recommended(不再推荐使用字段注入) - 知乎

完结!


相关文章
|
2月前
|
XML Java 数据格式
@Configuration配置类注解的理解
@Configuration配置类注解的理解
@Configuration配置类注解的理解
|
Java 开发者 Spring
Configuration注解一定要加吗?
Configuration注解一定要加吗?
119 0
|
Java 数据库连接 API
java参数校验(@Validated、@Valid)使用详解
java参数校验(@Validated、@Valid)使用详解
3792 0
|
缓存 Java Spring
配置类为什么要添加@Configuration注解?(2)
配置类为什么要添加@Configuration注解?(2)
140 0
配置类为什么要添加@Configuration注解?(2)
|
Java Spring 容器
配置类为什么要添加@Configuration注解?(1)
配置类为什么要添加@Configuration注解?(1)
124 0
配置类为什么要添加@Configuration注解?(1)
@Configuration和@Component注解的区别
1.@Configuration和@Component注解的源码如下 (1)Configuration注解源码如下:
|
Java Spring 容器
@Configuration注解
@Configuration注解
122 0
|
Java Spring
自定义@Validated参数注解
Spring Validated参数校验
315 0
|
JSON 前端开发 Java
Validated、Valid 、Validator,他们的区别你知道几个
Validated、Valid 、Validator,他们的区别你知道几个
556 0
Validated、Valid 、Validator,他们的区别你知道几个
|
Java Spring 容器
@Autowire 和 @Resource 注解使用的正确姿势,别再用错的了!!
@Autowire 和 @Resource 注解使用的正确姿势,别再用错的了!!
111 0
@Autowire 和 @Resource 注解使用的正确姿势,别再用错的了!!