【转贴】思考IoC

导读：

　　当人们面对复杂问题时应该何去何从？一种最为常用解决问题的方法便是分而治之，也就是将一个复杂问题分解为可以解决的小问题。这种思想在软件开发中得到了大量的应用，在软件架构方面的表现之一就是分层的思想。关于分层优劣的讨论，Martin Fowler在《企业应用架构模式》的第一章进行了深入的论述。

　　面对具体应用时，我们应该如何设计层次呢？DIP（Dependency Inversion Principle，依赖倒置原则）为我们指出了一个方向：

　　a 高层模块不应该依赖于低层模块，二者都应该依赖于抽象

　　b 抽象不应该依赖于细节，细节应该依赖于抽象

　　之所以称之为“倒置”，因为在传统的结构化程序设计中，高层模块总是依赖于低层模块，而在面向对象程序设计中，其结构相对而言，是被“倒置”了。关于DIP更详细的讨论，可以参考Robert Martin的《敏捷软件开发》第11章。

　　当我们的应用抽象层次提高到足够通用时，实际上就产生了一个框架，因此，框架代表的是一种抽象。就像抽象类无法实例化对象一样，单独的框架并不具备任何意义，只有当我们使用这个框架，补充抽象中缺失的具体细节时，这个框架才是具备了活力。

　　使用通常意义的库时，我们是作为主控方，控制着所有逻辑，而在使用一个框架时，我们所编写的部分是作为框架的细节补充到框架之中的，而框架本身已经定义好了它的逻辑，控制权是掌控在框架的手中。抽象控制着具体，这也就是框架之所以为框架的生存之本。同使用库的时候截然不同，这种控制关系就是将我们通常习惯的控制关系“倒置”了。没错，这就是IoC（Inversion of Control）。因此，Martin Fowler在他的那篇大名鼎鼎的《IoC容器和DependencyInjection模式》才会提出IoC是框架所共有的特征，也正是基于这样的原因，针对许多轻量级容器解决实际上是依赖关系的特点，他才提出Dependency Injection，以正视听。



本文转自

http://dreamhead.blogbus.com/logs/2005/05/1222803.html