当前位置: 首页 > news >正文

使用Autowired为什么会被IDEA警告,应该怎么修改最佳


问题原因

关于这个问题,其实答案相对统一,实际上用大白话说起来也容易理解。

  1. 初始化问题

    先看一下Java初始化类的顺序:父类的静态字段 > 父类静态代码块 > 子类静态字段 > 子类静态代码块 > 父类成员变量 > 父类构造代码块 > 父类构造器 > 子类成员变量 > 子类构造代码块 > 子类构造器。

而Autowired注入,则要排队到子类构造器以后了,SpringIOC并不会对依赖的bean是否为null做判断,JVM编译时同样也不会有问题,但如果使用不当,运行起来时或许会因为出现空指针异常

  1. 对IOC容易依赖过强

    @Autowired由Spring提供,而@Resource是JSR-250提供的,它是Java标准。前者会警告,而后者不警告,就是因为前者导致了应用与框架的强绑定,若是换成其他IOC框架,则不能够成功注入了。其实对于这方面,我认为在大多数情况时是不会有什么问题的。

  2. 其他方面

    我看到网络上有一些其他方面的总结,比如:依赖过多却不够明显,违反了单一职责原则不能像构造器那样注入不可变的对象等,这类问题需要结合个人实际开发进行判断。

对于@Autowired使用方面,它虽然是将业务代码和框架进行了强绑定,但字段注入确实大幅简化了代码。追求完完全全的松耦合其实也过于理想化,应该在实际使用中追求平衡,否则将为了过度追求松耦合而得不偿失



其他使用方式

除了使用@Autowired以外,我们其实也有几种好用的方式。使用@Resource替代@Autiwired方法是其中一种,只需要改变一个注解,这里就不展示了。

  1. set方法
@RestController
public class TestController2 {ITestService testService;/** 基于set注入* */@Autowiredpublic void setTestService(ITestService iTestService) {this.testService = iTestService;}@GetMapping("/status2")public Result<?> status() {return testService.status();}
}

这种方法也使用了@Autowired注解,但是它是作用于成员变量的Setter函数上,而不是像Fied注入一样作用于成员变量上。


  1. 构造器
@RestController
public class TestController1 {ITestService testService;/** 基于构造方法的注入* */public TestController1(ITestService iTestService) {this.testService = iTestService;}@GetMapping("/status1")public Result<?> status() {return testService.status();}
}

它的好处在于,采用了构造方法注入,这种方式对对象创建的顺序会有要求,它将避免循环依赖问题。是最可靠的方法。


  1. 构造器的简化版(推荐)
    首先,需要引入lombok依赖。
<dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><version>1.18.2</version>
</dependency>

随后,我们在创建时就可以使用@RequiredArgsConstructor注解,它将帮我们创建构造器,final关键字必不可少

@RestController
@RequiredArgsConstructor
public class TestController3 {/** 用@RequiredArgsConstructor注解,这个使用方式也可以应用于service层* */private final ITestService testService;@GetMapping("/status3")public Result<?> status() {return testService.status();}
}

我们在使用这些创建方法时,都可以调出IDEA的结构(Structure)面板进行查看,如下图所示。

在这里插入图片描述
可以看到,在这个类中,已经存在我们所需要注入的内容。

在网上有博主总结了一张表,但因为到处能看到,不知原来出处是哪里。

注入方式可靠性可维护性灵活性循环关系检测性能
Field注入不可靠灵活不检测启动快
构造方法可靠不灵活检测启动慢
set方法不可靠灵活不检测启动快


总结

在使用中,使用构造方法是比较可行的,加上lombok,其实也可以到达非常简便。

http://www.lryc.cn/news/4772.html

相关文章:

  • 面向对象(中)
  • 【云原生】promehtheus整合grafana实现可视化监控实战
  • Linux 内核定时器实验
  • 喜欢大屏电视?那就选择酷开系统,实现智能生活享受
  • PMP应该如何备考?
  • AcWing《蓝桥杯集训·每日一题》—— 3956.截断数组
  • Docker的数据管理
  • RxJS处理异步数据流
  • IP地址与用户行为
  • 底层逻辑2
  • TCP报头详解及TCP十种核心机制(一)
  • Linux用户的添加、修改和删除以及相关配置文件:useradd、passwd、usermod、userdel、相关配置文件
  • 进程地址空间
  • 数楼梯(加强版)
  • MySQL-数据类型
  • 剑指 Offer 32 - II. 从上到下打印二叉树 II(java解题)
  • C#网络爬虫开发
  • Fastjson 总结
  • 文件路径模块os.path
  • Kerberos简单介绍及使用
  • DOM编程-全选、全不选和反选
  • C++11可变模板参数
  • Linux多线程
  • Webpack5 环境下 Openlayers 标注(Icon) require 引入图片问题
  • Zookeeper安装部署
  • Cow Acrobats ( 临项交换贪心 )
  • MySQL:为什么说应该优先选择普通索引,尽量避免使用唯一索引
  • Spring Cloud alibaba之Feign
  • 零信任-Google谷歌零信任介绍(3)
  • Numpy基础——人工智能基础