那,控制反转和依赖注入这俩词吧,听着挺唬人的,其实大部分研发是用不到的,因为这些设计通常已经被框架实现了。

但是呢,不说一下吧,显得很不上进的样子,最主要最近博客没啥文章可写了,就水一篇文字说明好了。

以PHP为例,我们假设背景是这样的:

你有两个类,一个自写的类,一个数据库类,自写类中要用数据库类,怎么用?

小白写法:自写类里面new一个数据库类,然后使用。

然后问题来了,某一天这个数据库类初始化的变量数量有变动,你咋办?你只能改自写类的代码,把new的数据库类相关代码调整了。换句话说,你这个自写类,依赖着数据库类。后者的变更都要干扰你的代码,这多麻烦,太蠢了简直。

进阶写法:我呢,new自写类之前,new个数据库类,然后把数据库类这个对象插入自写类。这样,数据库类的变动也不会变动我自写类的代码。你看,现在这个情况呢,就是自写类不再对数据库类有所依赖,这个进阶写法呢,就是把数据库类的依赖,通过提前new之后以对象的方式注入到了自写类中。呕吼,如此,就实现了依赖注入这个概念。

其实吧,代码写多了,多少都会考虑类似的实现减少代码的复杂度的,只不过人家有专有名词:依赖注入。

回到小白的写法,你有没有发现,自写类是对数据库类有控制权的,自写类里面决定new什么样参数的数据库类。到了进阶写法呢,自写类不管数据库类了,这个数据库类的控制放在了自写类new之前,控制权从内部转向了外部,至此,又引入了另一个概念:控制反转

你要说依赖注入和控制反转不是相同的实现代码吗?是的没错,其实核心是一个意思,只不过一个是从控制权角度,一个是从依赖角度的描述而已。

那既然都提到框架了,就说说框架中一般把这俩概念用到什么地方吧。你框架里调用的数据库对象呢,通常是调用的时候使用框架的方法获取对象,倒追这个获取数据库对象方法,你翻源码,你仔细翻,会发现,其中会检测有没有数据库这个类,能不能new,这里就用到了反射这个方法。

能new的话,new一个对象,然后传回给你调用,当然,这个对象通常会使用单例模式(一种常见的设计模式,没啥卵用,就是避免你new 10个数据库对象连接数爆炸而已)。

反射的高端玩儿法呢,还能自动检测参数,对完成相关数据库的初始化参数传入。

你看,到这里,框架就帮你做了很多繁琐的事情了。其实你可以将自己写的代码理解为框架中一个容器内的应用,而框架中帮你实现这些繁琐事情的对象就叫做IOC容器。

IOC是啥?IOC(inversion of control)控制反转模式。DI是啥?DI(dependency injection)依赖注入模式。

通常对于框架的使用,我们实际上只实例化了一个框架的IOC容器实例而已,内部调用框架的类,都是通过IOC容器通过反射自动初始化好给你的,如此你就不用关心深层次的调用初始化细节了。

基本上就这些,都是文字,没代码,理解不了无所谓的,随着编码量增多,研发的深入,这些概念你都会刻在灵魂中,虽然,有可能你不知道这些术,有这样的专有名词。


参考资料

想看代码实现的,这里有更精细的说明:PHP控制反转(IOC)和依赖注入(DI)

谈谈php依赖注入和控制反转


如您从本文得到了有价值的信息或帮助,请考虑扫描文末的二维码对我进行赞赏和鼓励。

与《控制反转和依赖注入》相关的博文:


发布时间 09/06/2021 06:56:33所属栏目 Software.所属标签 .

留言

avatar
😀
😀😁😂😅😭🤭😋😘🤔😰😱🤪💪👍👎🤝🌹👌