IOC 理解三

依赖倒置原则
a.高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
b.抽象不应该依赖于细节，细节应该依赖于抽象。

　　可见，依赖倒置的本质是依赖抽象，这与依赖注入的本质依赖容器，是两回事。换句话说，如果Java没有接口、多态，依赖倒置就无从谈起。而依赖注入依然可以存在，只要有一个注册表（《企业应用架构模式》第18章第5节）定义bean，利用反射来实例化并装配bean，有个容器容纳它们即可。

二：还有的朋友可能把控制反转(IoC)和依赖注入(DI)混为一谈了

IoC主要的实现方式有两种：依赖查找，依赖注入。(128页)
依赖注入是一种更可取的方式。(130页)

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

　　显然，说the_pattern是IoC或DI都行，多态。但严格说IoC.class == DI.class肯定不为真，两者还是有区别，是 is-a 的关系。不过正如不少人把Service和ServiceImpl分开，但Service事实上永远只有一个ServiceImpl实现一样，IoC虽然理论上还有其他实现，但DI过于主流，以至于混用了。

三：废话说完了，正面答题

　　另外说说不限于DI的IoC，你的代码不再被直接调用，而是被框架代码调用，所以说框架与类库的区别在于控制反转( 好莱坞原则，don‘t call me, i‘ll call you )。往大了说，http请求不由你的Servlet/Filter直接处理，而是由Struts/Spring MVC的Servlet/Filter处理，再分配给你的组件，这也算IoC。往小了说，操作数据库不再由你直接写jdbc的一大堆try嵌套，而是把固定的部分抽到JdbcTemplate中，你只负责写局部代码，然后由框架调你的局部代码，这也算IoC。前一种，也就是前端控制器模式（《企业应用架构模式》第14章第3节），后一种，也就是模板方法模式（《设计模式》第5章第10节）。当然，除此之外还有很多。所以说，IoC的好处，也就是框架的好处。

　　这说得很对，但把框架换成类库也适用。关于框架的好处，在stackoverflow上一个问题下的答案我很喜欢：What is the difference between a framework and a library?

　　我认为，这就是控制反转的意义。框架提供了骨架（通用代码），你提供肉（业务逻辑）就行了。你的肉在骨架中被调用（如web容器先调用框架，框架再调用你的代码，而不是你的代码直接被web容器调用）。