那，控制反转和依赖注入这俩词吧，听着挺唬人的，其实大部分研发是用不到的，因为这些设计通常已经被框架实现了。
但是呢，不说一下吧，显得很不上进的样子，最主要最近博客没啥文章可写了，就水一篇文字说明好了。
以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)
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。
留言