@Autowired警告:Field injection is not recommended

在IDEA升级2017版后,发现以前使用的 @Autowired 出现了个警告 Field injection is not recommended

@Autowired的三种使用方式

@Controller

public class Controller{

    //通过构造器注入

    private final DependencyA dependencyA;

    private final DependencyB dependencyB;

    @Autowired

    public Controller(DependencyA dependencyA,DependencyB dependencyB){

        this.dependencyA = dependencyA;

        this.dependencyB = dependencyB;

    }

    //通过set方法注入

   private DependencyA dependencyA;    

    private DependencyB dependencyB; 

    @Autowired

    public void setDependencyA(DependencyA dependencyA){

        this.dependencyA = dependencyA;

    }

    @Autowired

    public void setDependencyB(DependencyB dependencyB){              

        this.dependencyB = dependencyB;    

    }   

    //通过field注入

    @Autowired

    private DependencyA dependencyA;

    @Autowired

    private DependencyB dependencyB; 

}

单一职责原则

当你使用构造器方式注入,构造器参数的数量就会变得太多以至于很容易出现错误。拥有太多的依赖通常意味着你的类要承担更多的责任,明显违背了单一职责原则和关注点分离,这是一个很好的现象,表明该类需要进一步检查和重构。在直接注入filed时,没有这样的危险信号,因为这种方法可以无限扩展。

依赖隐藏

使用DI容器意味着类不再对依赖负责,获取依赖的职责从类中抽离出来,DI容器会帮你装配,当类不再负责获取依赖时,它应该使用方法或构造器去了解类本身需要什么,以及它是可选的(setter方法)还是强制的(构造器)。

DI Container Coupling

One of the core ideas of the DI frameworks is that the managed class should have no dependency on the DI container used. In other words, it should be just a plain POJO, which can be instantiated independently, provided you pass it all the required dependencies. This way you can instantiate it in a unit test without starting the DI container and test it separately (with a container that would be more of integration test). If there is no container coupling, you can use the class either as managed or non-managed or even switch to a new DI framework.

对上面英文段的解释:

受DI容器管理的类只是一个普通的java对象,是能够被独立实例化的。通过这种方式,可以在单元测试中实例化它,而不需要启动DI容器去实例化它。如果没有DI容器耦合,不管有没有被DI容器管理,都可以实例化这个类,甚至切换到新的DI框架。简而言之,就是可以脱离spring的管理去操作这个类。

有一种方式(调用默认构造器)来创建对象就是使用new关键字,但是当这个对象缺少一些必要的依赖,调用的时候就会出现空指针异常。

这样的类不能在DI容器(测试、其他模块)之外重用,因为除了反射之外,没有其他方法向它提供所需的依赖项。

举个例子:

public class DependencyA {

    public void a(){

        System.out.println("dependencyA");

    }

}


public class POJO {

    @Autowired

    private DependencyA dependencyA;

    public void execute(){

        dependencyA.a();

    }

}


public class Test {

    public static void main(String[] args) {

        POJO pojo = new POJO();

        pojo.execute();

    }

}

当你执行execute()方法时就会报空指针异常,是因为DependencyA没有被创建,使用这种方式(@Autowired)也不会强制你去创建类所需的依赖,所以当使用者调用的方法的时候就可能会出现空指针异常。

不变性

与构造函数不同,字段注入不能用于向final字段指定依赖,从而有效地实现可变的对象。

Setters

setter注入适合于可选依赖项

Constructors

构造函数注入适合于强制依赖

结论:

Field注入应该尽可能地去避免使用,构造器注入更适合强制性的注入旨在不变性,Setter注入更适合可变性的注入。

参考:Field Dependency Injection Considered Harmful | Vojtech Ruzicka's Programming Blog

最后编辑于 :
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 137,342评论 19赞 139
  • 1.1 spring IoC容器和beans的简介 Spring 框架的最核心基础的功能是IoC(控制反转)容器,...
    simoscode阅读 6,943评论 2赞 22
  • 1.1 Spring IoC容器和bean简介 本章介绍了Spring Framework实现的控制反转(IoC)...
    起名真是难阅读 2,743评论 0赞 8
  • 三十万可能对于一些人来说是小钱,但是对于普通人来说,我相信还是一笔重要的资金。 怎样在短时间内借到一笔钱。话说两三...
    2ea7dac0fd80阅读 6,230评论 0赞 5
  • 每一名优秀的教师,真的都是让教育浸润在爱中的。做一个老师首先得做一个有爱的人,善良的人。薛岳娥老师亲身经历的故事,...
    令令子阅读 705评论 0赞 1

友情链接更多精彩内容