依赖注入和控制反转都是为了达到相同的解耦效果，Ioc确实不够开门见山，因此业界称进行了广泛的讨论，最终软件界的泰斗级人物Martin Fowler提出了DI的概念用以替代Ioc，即让调用类对某一接口实现类的依赖关系都第三方（容器或协作类）注入，以移除调用类对某一接口实现类的依赖。

ioc主要作用是用来解析类的实例，为什么要解析？而不是直接获得？因为类有其他类的依赖关系。ioc容器可以把多层级的依赖关系全部解析出来。

如果你看的是Laravel框架，可以看看：Service Container（IOC容器）

Don't call me, I will call you

正常流程

你去图书馆借书，但是没有。

于是你回家了。

然后你每个天去一趟图书馆，看你的书到了没有。

如果还没有，那么你回家，继续等……

第二天，再去看，……

一直到有了这本书。

Ioc

你去图书馆借书，但是没有。

于是你登记了一下，就回家了。

回到家，刷刷微博，刷刷sf，撸撸代码。

等书到了，管理员通知你。

你去拿书。

Don't call me, I will call you

建议看看spring框架的原理，就是依赖注册

正常的写法，都是上层调用底层封装好的方法，由底层提供接口，所谓的控制反转指的是，底层的执行逻辑可以由上层来决定，写的是什么，底层就执行什么，它的好处在于灵活、易扩展，就像@bigxu 写的代码一样。

通俗的说，一个项目由各个类组成。一个类在一个项目会被很多地方使用。

如果按照传统的写法就是每个用的地方都需要 new Class()
如果参数很复杂，每个地方都需要new Class(param1, param2, param3, ..)
此时每次修改类的构造函数， 那么每个地方需要跟着修改。工作量大，耦合度高。

但是可以把需要使用的类，初始化一次，放到一个容器中保存起来，其他需要使用的地方，
只需要调用容器的方法Container->getClassINeed()
那么，使用这个类和生成这个类通过中间的容器分开了。
示例可以看Phalcon框架，文档里给的例子，教你一步步搭建自己的容器

一些管理对象生成的设计模式，本身也算一种容器的实现， 例如常见的工厂模式

IOC可以通俗理解：

比如我要去ATM取款，我有一堆银行卡：农行、建行

IOC处理的就是通过ATM的接口（当然也包括系统）去约束卡

比如，卡的大小要求，卡要有磁条，然后得有余额；这些元素都是取款的必备条件。ATM就约束了卡。

IOC的精髓就是：取款操作一致，而卡却不一样。而能使用的卡则依靠中间者（ATM机）去约束