依赖注入和控制反转在业界算是顶顶大名了，其实还是有很大一部分人不知道吧，这个就是进阶高级工程师必学的理念，让你脱离简单的业务实现进阶中高级工程师。
关于这两个东西其实和爱情是一样的，感觉的到但是说不清道不明，一千个程序员就有一千个依赖注入和控制反转，每个人的理解都各有不同。其实他们简述的是一个东西，我是这么理解的，他们的代码实现其实相对比较简单，所以我们就从概念开始吧。
IoC，直观地讲，就是容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在。控制权由应用代码中转到了外部容器，控制权的转移是所谓反转。IoC还有另外一个名字——“依赖注入（Dependency Injection）”。从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象地说，即由容器动态地将某种依赖关系注入到组件之中。
概念还是主要靠自己理解，我们今天讲一个实际例子，也属于笔者工作中常用的实际操作的例子进行讲解，我们公司做支付业务就是这么来实现的。
首先要理解为什么要控制反转，什么是控制反转？ 我们都知道我们应用层的类需要依赖不论框架底层类也好还是自己封装类也好，只要有使用就有这个的概念。谁控制谁，谁操控谁呢，这个就是一个比较有意思的问题了。我们一般在初学阶段永远都习惯按照自己逻辑来编程，这是所有初学者都知道的一个问题：就是上层要依赖底层，使用层要依赖封装层，但是有时候我们并不知道我们后续还可能加什么新的类型进入代码，很多人就习惯将封装层写死，很容易被经验所局限，控制反转这里是指将主导权交给应用层，底部封装只用关心你的调用，而不需要关心业务的多少个类型。
实际上我们的人类没写全，还有男孩，老头，老太等，就和我们实际工作一样，不可能所有的场景你都能想的到，看到这里你可能就会发现一定的局限性了：如果有个男孩进入的话，可能就要修改封装类库。
应用层呢就是决定你是哪一类的人。
这就是很多新手封装的，其实很多老手也会比较犯此类错误，我见过很多。
此时的依赖注入关系：应用类依赖人类，人类注入到类中应用。那此刻我们如何实现控制反转呢。
1.首先将封装类业务理清楚，假设我要说明进入的人的姓名（或者如同支付一般：我有支付，退款，提现，这些业务上的东西其实很好理清楚，但是如果今天我们有支付宝，微信，到后面我们要扩充的是什么呢，可能是亚马逊或者苹果支付，这个就不同了）
2.建立中间类，降低耦合，将应用和封装直接分开
2.此段代码注释有点问题，是我们一般会定义接口管理中间类，由中间类去继承统一接口实现逻辑，并不是封装底层类。
3.此处应用层我们直接去调用就好了，你会发现应用类此时并不依赖于底层了，此时就达成了我们的控制反转或者说是依赖注入了，仔细一点你就会发现之前我们想通过方法调用打印：我是男孩，此刻你就必须修改底层封装类，一般频繁的修改底层封装类是很不好的习惯，如果一个地方改错了基本上整个线上服务就会崩溃，一个底层地方出错，所有支付都调用不起，你就可能担心自己会被炒鱿鱼然后越改越错。用第二种方法呢，我们只需要建立一个男孩的中间类，去实现接口中的方法，调用封装类中的name方法就好了，不会影响其他的类的服务。
通俗易懂的解释：将对象作为方法参数进行传递，本篇文章讲持续更新，后续我将会在本篇文章中讲解thinkphp的依赖注入的内部实现
