问题原因
其他使用方式
总结
问题原因
关于这个问题,其实答案是存在着广泛的共识的。尤其是在专家学者的研究中,已经有了很多深入的探讨和分析。总的来说,这个问题涉及到的方面比较广泛,包括但不限于经济、政治、社会等方面。因此,需要我们在讨论这个问题的时候,要全面考虑各种不同的因素和角度,以便得出更为准确和合理的结论。
初始化问题
先看一下Java初始化类的顺序:
父类的静态字段 > 父类静态代码块 > 子类静态字段 > 子类静态代码块 > 父类成员变量 > 父类构造代码块 > 父类构造器 > 子类成员变量 > 子类构造代码块 > 子类构造器
而Autowired注入,则要排队到子类构造器以后了,SpringIOC并不会对依赖的bean是否为null做判断,JVM编译时同样也不会有问题,但如果使用不当,运行起来时或许会因为出现空指针异常。
2.对IOC容易依赖过强
@Autowired
由Spring提供,而@Resource
是JSR-250提供的,它是Java标准。前者会警告,而后者不警告,就是因为前者导致了应用与框架的强绑定,若是换成其他IOC框架,则不能够成功注入了。其实对于这方面,我认为在大多数情况时是不会有什么问题的。
3.其他方面
我看到网络上有一些其他方面的总结,比如:依赖过多却不够明显,违反了单一职责原则;不能像构造器那样注入不可变的对象等,这类问题需要结合个人实际开发进行判断。
对于@Autowired
使用方面,它虽然是将业务代码和框架进行了强绑定,但字段注入确实大幅简化了代码。追求完完全全的松耦合其实也过于理想化,应该在实际使用中追求平衡,否则将为了过度追求松耦合而得不偿失。
其他使用方式
除了使用@Autowired
以外,我们其实也有几种好用的方式。使用@Resource
替代@Autiwired
方法是其中一种,只需要改变一个注解,这里就不展示了。
1.set方法
这种方法也使用了@Autowired
注解,但是它是作用于成员变量的Setter函数上,而不是像Fied注入一样作用于成员变量上。
2.构造器
这种方法的好处在于,采用了构造方法注入的方式来创建对象,这种方式对对象创建的顺序有一定的要求,但它可以避免出现循环依赖的问题。使用构造方法注入方式创建对象是最可靠的方法,因为它可以确保对象的正确创建和初始化,从而提高系统的可靠性和稳定性。此外,使用构造方法注入方式创建对象还可以提高系统的可维护性和可扩展性,因为它使得对象之间的依赖关系更加清晰和易于管理,从而使得系统更加容易修改和扩展。
3.构造器的简化版(推荐)
首先,需要引入lombok依赖。
随后,我们将使用@RequiredArgsConstructor注解在创建时帮我们生成构造器,这个注解可以帮助我们避免漏掉final关键字,从而使得代码更加健壮、可靠。此外,对于一些比较复杂的开发场景,我们还可以在构造器中添加一些额外的参数和逻辑,以便更好地实现我们的需求。在实际的开发中,充分利用构造器这一特性可以帮助我们更快速地构建出高质量的代码,并更好地满足我们的业务需求。
我们在使用这些创建方法时,都可以调出IDEA的结构(Structure)面板进行查看,如下图所示。
根据这个类中已经存在的内容,我们可以看到可以注入所需的信息,从而实现我们的目标。不过,如果你需要更详细的信息,你可以在网上搜索相关的博客文章。尽管有一些博主总结了一些表格来帮助理解,但由于这些表格都分散在不同的地方,因此很难确定其原始出处。总体而言,我们需要更全面和详细的理解,这样才能更好地实现我们的目标。
总结
使用构造方法在代码中是非常常见的。在使用构造方法时,我们可以使用lombok来使代码更加简便,减少代码量和重复性。lombok是一个非常实用的工具库,它可以帮助我们自动化生成很多样板代码,如getters和setters,构造方法等等。当我们在代码中使用lombok时,我们可以节省很多时间和重复性的劳动,从而更加专注于代码的核心逻辑。因此,我建议大家在写代码时使用构造方法和lombok来使代码更加简单和易于维护。