spring ioc基本概念和理解

IOC，控制反转，但是从我的角度和理解来看，就是由主动变为被动，举个简单的例子：就是本来我是老大，一切的主动权在我的手里，我来操控一切，后来过来一位比我级别更高的领导，转由他来进行操控，我想这就比较容易理解这个概念了，属于角色互换，控制反转。

控制反转：是一种通过描述（在java中可以通过xml方式和注解的方式）并通过第三方去产生或获取特定对象的方式。

在spring中实现控制反转的ioc容器，其实现方法是依赖注入DI

举个例子：

现实系统开发中，系统的开发者是一个团队，团队由许多开发者组成。如果你负责电商网站负责开发工作，你熟悉商品交易流程，但是对财务并不熟悉，而团队中有些成员对于财务处理十分熟悉，、在交易的过程中，商品交易流程需要调度财务的相关接口，才能得以实现，那么我们的期望应该是：

1.熟悉财务流程的成员开发对应的接口。

2.接口逻辑尽量简单，内部复杂的业务并不需要自己去了解，你只要通过简单的调用就能使用。

3.通过简单的描述就能获取接口实例，且描述尽量简单。

当熟悉财务的同事完成对财务接口模块的开发，就可以将其服务发布到spring ioc的容器里，

这个时候你只需要过程描述得到对应的财务接口，就可以完成对应的财务操作了，而这些

并不需要你去理解，你只需要知道它能完成对应的财务操作可以了。同样的，对于熟悉交易的你，

也把交易接口模块发布Spring ioc容器中，这样财务开发人员就可以通过容器获取交易接口得到交易明细，交易模块如何工作，又依赖于哪些对象，他也是不需要知道的，课件spring ioc容器带来了许多使用的便利。

 

这就是一种控制反转的理念，虽然这个理念的一个坏处是理解上的困难，但是它最大的好处在于降低对象之间的耦合，在一个系统中有些类，具体如何实现并不需要去理解，只需要知道它有什么

用就可以了，只是这里对象的产生依靠ioc容器，而不是开发者主动的行为。主动创建的模式，

责任归于开发者，而在被动的模式下，责任归于ioc容器。基于这样的被动形式，我们就说对象

被控制反转了。基于降低开发难度，对模块解耦，Spring Ioc容器可以容纳我们所开发的各种Bean，并且我们可以从中获取各种发布在Spring ioc容器里的Bean，并且通过描述可以得到它。