对IOC的解释为：“Inversion of control is a common characteristic of frameworks， so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.”
我想对这一概念执行 一个个人的阐述，以方便我的理解。控制反转，从字面意思来看， 就是控制权由被动变主动又变为被动，或被动变主动又变为被动。从这个角度来说，IOC就变得非常容易理解了。
举个例子：你的主管要求你做一件事情，这个时候就存在这么多个 流程 ,主管命令你做事情（这个时候主动权在主管，你是被动的）
你接到命令做事情（这个时候主题是你，你是主动的，控制权在你手里） 你完成事情（这个时候主题依然是你，控制权在你手里）
报告主管做完事情（主动权又叫交到主管手里了）
上面的整个流程 就完成了一次IOC，从上面可以看出，IOC的基本思想是控制权的转换流程 。
举个代码的例子：
假如有Class A，Class B，在A内部会原始化一个B，调用B的一个要领
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
DoMethod public Class B { public void DoMethod（） { /// do somthing； } } public Class A { public void Excute（） { B b = new B（）； b.DoMethod（）； } } |
假如在Main函数中如下执行： A a = new A（）； a.Excute（）；
从这两行代码来看，事实上也存在一个IOC的流程 ，a——>b——>a，理解的关键点就在在A的内部调用Excute的时候， 要领 b.DoMethod的执行。 理解了IOC，我们再看一下DI， 从上面A调用B我们可以看出， 在原始化一个A的实例时，也必须实例化一个B，也就是说如果没有B或者B出了疑问 ， A就不能 实例化，这就产生了一种依赖，就是A依赖B， 这种依赖从设计的角度来说就是耦合，显然它是不能 满足高内聚低耦合的要求的。这个时候就须要 解耦， 当然解耦有很多种要领 ， 而DI就是其中一种。不管任何一种解耦要领 ，都不是说使A和B完全没有联系 ， 而是把这种联系 的实现变得隐晦，不那么直接，但是又很容易实现， 而且易于扩展，不像上面的代码那样，直接new一个B出来。那为什么我们总是把IOC和DI联系到一起呢？ 是因为DI的基本思想就是IOC，而体现IOC 思想的要领 还有另外一个，那就是Service Locator，这个要领 好像涉及到的很少。其实这些都是从java里面衍生出来的，虽然本人已经好几年没用java，里面Spring这些都会用到IOC、DI好像他们是紧密连接在一块的。
