UC知道对依赖注入的构造子注入的理解
来源：百度知道 编辑：UC知道 时间：2024/07/02 01:53:56
public class DIByConstructor
{
private final DataSource dataSource;
private final String message;
public DIByConstructor(DataSource ds, String msg)
{
this.dataSource = ds;
this.message = msg;
}
……
}
示例代码相信大家很多都在其他网站上看过。但是我想问的是，这个事例所展示的代码，真的实现了依赖注入吗？其他的类（暂命名为classA）在调用DIByConstructor类的时候，仅仅是调用DIByConstructor的带参数的构造方法，就实现了依赖注入？我不这样认为，其实这样，在classA编译的时候，对DIByConstructor类的依赖不是依然很明显的吗？和我们之前没有用依赖注入的时候有什么区别呢？
{
private final DataSource dataSource;
private final String message;
public DIByConstructor(DataSource ds, String msg)
{
this.dataSource = ds;
this.message = msg;
}
……
}
示例代码相信大家很多都在其他网站上看过。但是我想问的是，这个事例所展示的代码，真的实现了依赖注入吗？其他的类（暂命名为classA）在调用DIByConstructor类的时候，仅仅是调用DIByConstructor的带参数的构造方法，就实现了依赖注入？我不这样认为，其实这样，在classA编译的时候，对DIByConstructor类的依赖不是依然很明显的吗？和我们之前没有用依赖注入的时候有什么区别呢？
其实所谓的依赖注入不是你去调用他的构造方法，而是容器去调用。比如spring容器。
他的原理是，在spring的配置文件中，你可以配置注入的对象（一般来讲需要注入的对象定义的时候用接口定义），然后是 通过容器去得到此对象 ，在你的例子中，就是通过容器得到DIByConstructor，而不是你自己去构造。
所以当你需要注入的对象更换的时候，只需要更改配置文件，就可以注入不同的对象，因为你始终是通过容器得到对象，所以这部分代码也不需要改变，因此耦合就非常低了，因为所有过程中，你只需要更改注入对象的实现以及更改配置文件。
其实你应该结合实际去试试看到底怎么用的，就会非常清楚了。你给的例子什么问题也不能说明，必须将整个代码理解才行。
依赖关系在构造时由容器一次性设定。因此组件在被创建之后即处于相对“不变”的稳定状态，无须担心上层代码在调用过程中执行setter方法对组件依赖关系产生破坏，特别是对于Singleton模式的组件而言，这可能对整个系统产生重大的影响。
同样，由于关联关系尽在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系，对调用者而言，组件中的依赖关系出于黑盒之中，对上层屏蔽不必要的信息，也为系统的层次清晰性提供了保证。
通过构造子注入，意味着我们可以在构造函数中决定依赖关系的注入顺序，对于一个大量以来外部服务的组件而言，依赖关系的获得顺序可能非常重要，比如某个依赖关系注入的先决条件是组件的DataSource及相关资源已经被设定。