IOC理论提出的观点大致是这样的:借助于“第三方”实现具备依赖关系的对象之间的解耦。
因为引进了中间位置的“第三方”,也就是IOC容器,使得A、B、C、D这4个对象没有了耦合关系,齿轮之间的传动所有依靠“第三方”了,所有对象的控制权所有上缴给“第三方”IOC容器,因此,IOC容器成了整个系统的关键核心,它起到了一种相似“粘合剂”的做用,把系统中的全部对象粘合在一块儿发挥做用,若是没有这个“粘合剂”,对象与对象之间会彼此失去联系,这就是有人把IOC容器比喻成“粘合剂”的由来。html
图1:软件系统中耦合的对象web
图3:IOC解耦过程spring
图4:拿掉IoC容器后的系统小程序
控制反转(IOC)到底为何要起这么个名字?咱们来对比一下:spring-mvc
软件系统在没有引入IOC容器以前,如图1所示,对象A依赖于对象B,那么对象A在初始化或者运行到某一点的时候,本身必须主动去建立对象B或者使用已经建立的对象B。不管是建立仍是使用对象B,控制权都在本身手上。mvc
软件系统在引入IOC容器以后,这种情形就彻底改变了,如图3所示,因为IOC容器的加入,对象A与对象B之间失去了直接联系,因此,当对象A运行到须要对象B的时候,IOC容器会主动建立一个对象B注入到对象A须要的地方。app
经过先后的对比,咱们不难看出来:对象A得到依赖对象B的过程,由主动行为变为了被动行为,控制权颠倒过来了,这就是“控制反转”这个名称的由来。框架
2004年,Martin Fowler探讨了同一个问题,既然IOC是控制反转,那么究竟是“哪些方面的控制被反转了呢?”,通过详细地分析和论证后,他得出了答案:“得到依赖对象的过程被反转了”。控制被反转以后,得到依赖对象的过程由自身管理变为了由IOC容器主动注入。因而,他给“控制反转”取了一个更合适的名字叫作“依赖注入(Dependency Injection)”。他的这个答案,实际上给出了实现IOC的方法:注入。所谓依赖注入,就是由IOC容器在运行期间,动态地将某种依赖关系注入到对象之中。ide
因此,依赖注入(DI)和控制反转(IOC)是从不一样的角度的描述的同一件事情,就是指经过引入IOC容器,利用依赖关系注入的方式,实现对象之间的解耦。模块化
【1】Spring quick guide
http://www.tutorialspoint.com/spring/spring_quick_guide.htm
【2】Spring的IOC原理
http://www.importnew.com/14751.html
【3】Spring MVC框架搭建-页面最后是详细的搭建过程连接
http://www.tutorialspoint.com/spring/spring_web_mvc_framework.htm