今天,我们在代码中发现了这种模式：
class Foo {
private List虽然代码似乎有效,但这是一个单独的Spring bean,并且它被注入了几个独立的地方,并且bean的使用者认为它们每个都有自己的错误列表.所以这引入了微妙的错误.
显而易见的解决方案是教育开发人员避免这种错误,但我想知道是否有静态或运行时代码分析工具可以找到这种错误.
例如,bean后处理器可以在返回之前分析bean,并查找不是@Autowired的私有字段.
最佳答案
在此之后倾注了更多的大脑(我们和其他人),我们提出了这种方法：
>安装BeanPostProcessor,确保所有单例bean(即bean定义中的作用域为Singleton)在实际bean类型上具有自定义注释@Stateless.
我们选择了自定义注释而不是重用@Singleton,因为我们在其他地方也需要这个功能.
如果缺少注释,则工厂会抛出错误.
>在单元测试中,我们使用带有自定义注释的ClassPathScanningCandidateComponentProvider来定位类路径上的所有类.然后,我们可以进行复杂且昂贵的测试,以确保bean在初始配置后(即自动装配完成后)没有状态发生变化.
如果我们将自动装配的字段移动到构造函数中,第二步可能会变得更容易,但我们不喜欢采用许多参数的方法.如果Java或IDE可以从bean代码生成构建器,那将是很好的.由于情况并非如此,我们坚持使用自动装配的字段和/或设置器.
