依赖注入的存在是为了解决什么问题?

最近喜欢上问自己问题:某某技术的存在是为了解决什么问题?因为只有了解这个技术的产生缘由后,才会对这个技术的理解更加深刻。
那么,今天尝试着来问自己这么一个问题:依赖注入解决了什么问题?之所以会产生这个疑问呢,还是得归咎于了解了Node.js的express框架后,发现相比其他语言的框架(Spring,Laravel),缺少依赖注入这个特色。但是实际使用上,其实还是相当给力的,那么依赖注入的存在是否就无关紧要呢?
那么,首先我们来了解一下依赖注入的定义是什么?

依赖注入(Dependency
Injection),是这样一个过程:由于某客户类只依赖于服务类的一个接口,而不依赖于具体服务类,所以客户类只定义一个注入点。在程序运行过程中,客户类不直接实例化具体服务类实例,而是客户类的运行上下文环境或专门组件负责实例化服务类,然后将其注入到客户类中,保证客户类的正常运行。

嗯,是不是觉得非常深奥和玄乎?什么接口,注入,具体服务类,上下文等名词搞晕了我们大脑,这也就是为什么学习技术是一件痛苦的事情了,类似《Head first》之类的书籍简直是神器。

这么玄奥的话我们是不懂的啦,那么我们来尝试依赖注入产生的动机。

首先,没有依赖注入,我们会频繁的制造创建对象的代码,比如我们要发送邮件:

use AppBundle\Mailer;

$mailer = new Mailer('sendmail');
$mailer->send('ryan@example.com', ...);

比如这种代码,我们可能在很多地方去重复制造。
重复制造有什么问题呢?
个人觉得其实也没有什么问题,大家刚开始编程的时候不都这么写的么。。。哈哈

但是可能有人觉得重复制造不好,比如有可能在一次调用过程中会制造出多个mailer对象,其实明明创建一个就可以了是不?
那么我们在最开始的时候初始化一个对象好不好呢?
比如在每次请求过程开始的时候,初始化一个mailer对象,然后在后面就可以任意次数进行调用了。

但是也有问题,万一这个项目的代码中需要用到成百上千个这样的对象(纯属假设),那我们岂不是要在请求开始的时候创建这么多个对象了。
那么,有更好的解决办法么?
我们可以假设系统中存在一个容器,容器内部放置了这么多个对象,容器内的对象可以直接用来调用。其实容器内被调用的对象都不存在,只有在第一次被调用的时候才会被系统初始化,保存在容器内部。
但是对我们这些调用者来说,容器就相当于存在成百上千个对象等待我们去调用。

这样就大概是依赖注入被制造出来的原因了,只是关于重复制造存在的问题,我还需要思考思考该怎么表述。

给个Node.js依赖注入的例子:http://www.infoq.com/cn/articles/ioc-meet-nodejs

标签: 依赖注入

添加新评论