IOC，控制反转，但是从我的角度和理解来看，就是由主动变为被动，举个简单的例子：就是本来我是老大，一切的主动权在我的手里，我来操控一切，后来过来一位比我级别更高的领导，转由他来进行操控，我想这就比较容易理解这个概念了，属于角色互换，控制反转。
控制反转：是一种通过描述（在java中可以通过xml方式和注解的方式）并通过第三方去产生或获取特定对象的方式。
在spring中实现控制反转的ioc容器，其实现方法是依赖注入DI
举个例子：
现实系统开发中，系统的开发者是一个团队，团队由许多开发者组成。如果你负责电商网站负责开发工作，你熟悉商品交易流程，但是对财务并不熟悉，而团队中有些成员对于财务处理十分熟悉，、在交易的过程中，商品交易流程需要调度财务的相关接口，才能得以实现，那么我们的期望应该是：
1.熟悉财务流程的成员开发对应的接口。
2.接口逻辑尽量简单，内部复杂的业务并不需要自己去了解，你只要通过简单的调用就能使用。
3.通过简单的描述就能获取接口实例，且描述尽量简单。
当熟悉财务的同事完成对财务接口模块的开发，就可以将其服务发布到spring ioc的容器里，
这个时候你只需要过程描述得到对应的财务接口，就可以完成对应的财务操作了，而这些
并不需要你去理解，你只需要知道它能完成对应的财务操作可以了。同样的，对于熟悉交易的你，
也把交易接口模块发布Spring ioc容器中，这样财务开发人员就可以通过容器获取交易接口得到交易明细，交易模块如何工作，又依赖于哪些对象，他也是不需要知道的，课件spring ioc容器带来了许多使用的便利。
这就是一种控制反转的理念，虽然这个理念的一个坏处是理解上的困难，但是它最大的好处在于降低对象之间的耦合，在一个系统中有些类，具体如何实现并不需要去理解，只需要知道它有什么
用就可以了，只是这里对象的产生依靠ioc容器，而不是开发者主动的行为。主动创建的模式，
责任归于开发者，而在被动的模式下，责任归于ioc容器。基于这样的被动形式，我们就说对象
被控制反转了。基于降低开发难度，对模块解耦，Spring Ioc容器可以容纳我们所开发的各种Bean，并且我们可以从中获取各种发布在Spring ioc容器里的Bean，并且通过描述可以得到它。