IOC 理解三

一：依赖倒置(DIP)和依赖注入(DI)

　 《敏捷软件开发》第11章：

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

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

二：控制反转(IoC)和依赖注入(DI)

　 《EXPERT ONE ON ONE J2EE DEVELOPMENT WITHOUT EJB》第6章：

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

　　流行的「Martin Fowler将IoC改名为DI」的说法，Martin Fowler的原文在这里：  Inversion of Control Containers and the Dependency Injection pattern

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.

　　大意是：已经存在某种模式，该模式被称为IoC，但IoC太普遍，任何框架都IoC，为了让表意更明确，决定用DI来精确指称那个模式。
　　意思大概就是 IoC ioc = the_pattern; DI di = (DI)ioc，显然，说the_pattern是IoC或DI都行，多态。但严格说IoC.class == DI.class肯定不为真，两者还是有区别，是 is-a 的关系。不过正如不少人把Service和ServiceImpl分开，但Service事实上永远只有一个ServiceImpl实现一样，IoC虽然理论上还有其他实现，但DI过于主流，以至于混用了。

三：换种方式理解IOC

　 《Spring实战》第1章：在项目中应用DI，你会发现你的代码会变得异常简单并且更容易理解和测试。另外说说不限于DI的IoC，你的代码不再被直接调用，而是被框架代码调用，所以说框架与类库的区别在于控制反转。往大了说，http请求不由你的Servlet/Filter直接处理，而是由Struts/Spring MVC的Servlet/Filter处理，再分配给你的组件，这也算IoC。往小了说，操作数据库不再由你直接写jdbc的一大堆try嵌套，而是把固定的部分抽到JdbcTemplate中，你只负责写局部代码，然后由框架调你的局部代码，这也算IoC。前一种，也就是前端控制器模式（《企业应用架构模式》第14章第3节），后一种，也就是模板方法模式（《设计模式》第5章第10节）。当然，除此之外还有很多。所以说，IoC的好处，也就是框架的好处。   《Struts2技术内幕》第2章：框架是一组程序的集合，包含了一系列的最佳实践，作用是解决某个领域的问题。这说得很对，但把框架换成类库也适用。关于框架的好处，在stackoverflow上一个问题下的答案我很喜欢：What is the difference between a framework and a library?   大意是：框架提供了骨架，你只要提供肉就可以了，你的肉在骨架中被调用。我认为，这就是控制反转的意义。框架提供了骨架（通用代码），你提供肉（业务逻辑）就行了。你的肉在骨架中被调用（如web容器先调用框架，框架再调用你的代码，而不是你的代码直接被web容器调用）。