如何理解IoC/DI

IoC:Inversion of Control,控制反转
DI:Dependency Injection,依赖注入

要理解上面两个概念,就必须搞清楚如下的问题:

参与者都有谁?
依赖:谁依赖于谁?为什么需要依赖?
注入:谁注入于谁?到底注入什么?
控制反转:谁控制谁?控制什么?为什么叫反转(有反转就应该有正转了)?
依赖注入和控制反转是同一概念吗?

下面就来简要地回答一下上述问题,把这些问题搞明白了,也就明白IoC/DI了。
(1)参与者都有谁:一般有三方参与者,一个是某个对象;另一个是IoC/DI容器(譬如Spring);还有一个是某个对象的外部资源。
Tips:某个对象指的是任意的、普通的Java对象;IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序;
对象的外部资源指的就是对象需要的,但是是从对象外部获取的,都统称为资源,譬如,对象需要的其它对象,或者是对象需要的文件资源等。

(2)谁依赖于谁:当然是某个对象依赖于IoC/DI的容器
(3)为什么需要依赖:对象需要IoC/DI的容器来提供对象需要的外部资源
(4)谁注入谁:很明显是IoC/DI的容器把某个对象需要的资源注入此对象
(5)到底注入什么:就是注入某个对象所需要的外部资源
(6)谁控制谁:当然是IoC/DI的容器来控制对象了
(7)控制什么:主要是控制对象实例的创建
(8)为何叫反转:反转是相对于正向而言的,那么什么算是正向的呢?
考虑一下常规情况下的应用程序,如果要在A里面使用C,你会怎么做呢?
一般会使用组合,直接去创建C的对象,也就是说,在A类中主动去获取需要的外部资源C,这种情况被称为正向的。
那么什么是反向呢?就是A类不再主动去获取C,而是被动等待,等待IoC/DI的容器获取一个C的实例,然后反向地注入到A类中
主动去取是正向,被动接收就反向,从正向改为反向,就称为反转

(9)依赖注入和控制反转是同一概念吗?
依赖注入和控制反转是对同一事情的不同角度的描述。

DI/IoC都是以对象为主体来描述构架、对象、资源之间的关系,

DI强调的是框架的作用:对象依赖框架,框架服务对象(对象什么也不做,等着框架主动伺候);
IoC强调的是对象获取资源的方式,是主动创建还是被动接收;

依赖注入是强调某个对象获取需要的资源的方式;
控制反转强调的是指某个对象在获取所需资源是主动还是被动;

从某个方面讲,就是它们描述的角度不同。
依赖注入是从应用程序的角度去描述,可以把依赖注入描述得完整点:应用程序依赖容器创建并注入它所需要的外部资源;
控制反转是从容器的角度去描述,容器接管一切,描述的完整点就是:容器控制应用程序,由容器向应用程序注入其所需要的外部资源。

因为以前是应用程序主动获取所需的资源,需要什么主动拿什么,
现在的方式和以前相反
框架接管一切,应用程序所需资源及吃喝拉撒框架负责,什么都由框架来做,这种方式与以前相反,
这个变化就称为反转或者逆袭,都是与以前相比较的。

IoC/DI的进步是编程思想上“主从换位”的变化。应用程序原来是老大,要获取什么资源都是主动出击,但是在IoC/DI思想中,
应用程序就变成被动的了,被动地等待IoC/DI容器来创建并注入它所需要的资源。

IoC/DI的目标是代码复用、解耦。当然,程序的体系结构也变得非常灵活。

《研磨设计模式》

 

时间: 2024-09-16 13:41:35

如何理解IoC/DI的相关文章

IOC DI

IoC:Inversion of Control,控制反转DI:Dependency Injection,依赖注入 要理解上面两个概念,就必须搞清楚如下的问题: 参与者都有谁?依赖:谁依赖于谁?为什么需要依赖?注入:谁注入于谁?到底注入什么?控制反转:谁控制谁?控制什么?为什么叫反转(有反转就应该有正转了)?依赖注入和控制反转是同一概念吗? 下面就来简要地回答一下上述问题,把这些问题搞明白了,也就明白IoC/DI了.(1)参与者都有谁:一般有三方参与者,一个是某个对象:另一个是IoC/DI容器(

如何理解IOC 依赖注入的思想(目前见过最好的对DI的描述)

1 IoC理论的背景 我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑. 图1:软件系统中耦合的对象 如果我们打开机械式手表的后盖,就会看到与上面类似的情形,各个齿轮分别带动时针.分针和秒针顺时针旋转,从而在表盘上产生正确的时间.图1中描述的就是这样的一个齿轮组,它拥有多个独立的齿轮,这些齿轮相互啮合在一起,协同工作,共同完成某项任务.我们可以看到,在这样的齿轮组中,如果有一个齿轮出了问题,就可能会影响到整个齿轮组

对DIP IoC DI的理解与运用

DIP,IoC,DI基本概念 依赖倒置原则(DIP,Dependency Inverse Principle):强调系统的"高层组件"不应当依赖于"底层组件",并且不论是"高层组件"还是"底层组件"都应当依赖于抽象.抽象不应当依赖于实现,实现应当依赖于抽象. 依赖(Dependency):组件A如果:①持有B的引用,②调用B的方法,③创建(new)B,则A对B产生依赖. 控制(Control):A依赖B,则B拥有"控

Microsoft实现的IOC DI之 Unity 、Service Locator、MEF

这几个工具的站点 Microsoft Unity  http://unity.codeplex.com Service Locator http://commonservicelocator.codeplex.com MEF  .net4.0内含,3.x前在codeplex上开源 Utility The main reasons to use Unity (or any other IoC container) are if: Ø You have dependencies between yo

谈谈对Spring IOC的理解

学习过Spring框架的人一定都会听过Spring的IoC(控制反转) .DI(依赖注入)这两个概念,对于初学Spring的人来说,总觉得IoC .DI这两个概念是模糊不清的,是很难理解的,今天和大家分享网上的一些技术大牛们对Spring框架的IOC的理解以及谈谈我对Spring Ioc的理解. 一.分享Iteye的开涛对Ioc的精彩讲解 首先要分享的是Iteye的开涛这位技术牛人对Spring框架的IOC的理解,写得非常通俗易懂,以下内容全部来自原文,原文地址:http://jinniansh

IoC与DI (转载)

(本文转自梦想风暴的blog) 一个朋友发了封mail问了几个问题,其中的一个是关于IoC和DI的:Inversion of Control和Dependency Injection 是什么关系,我认为两个词代表的是同一个意思,只是两种不同的表示,对吗? 下面是我对这个问题的一些理解.准确的说,IoC和DI并不相同,这一点从字面上就可以看出,否则,它们可以叫一个名字.^_^ 理解IoC,我们需要知道Control是什么,它又是怎样被Inversion的.其实,IoC是用来说明"程序库"

【调侃】IOC前世今生(转)

前些天,参与了公司内部小组的一次技术交流,主要是针对<IOC与AOP>,本着学而时习之的态度及积极分享的精神,我就结合一个小故事来初浅地剖析一下我眼中的"IOC前世今生",以方便初学者能更直观的来学习与理解IOC!也作抛砖引玉之用. (虽说故事中的需求有点小,但看客可在脑海中尽量把他放大,想象成一个很大的应用系统)   一.IOC雏形 1.程序V1.0     话说,多年以前UT公司提出一个需求,要提供一个系统,其中有个功能可以在新春佳节之际给公司员工发送一封邮件.邮件中给

ASP.NET Core中的依赖注入(1):控制反转(IoC)

ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务,为了方便对这些组件进行定制,ASP.NET通过定义接口的方式对它们进行了"标准化",我们将这些标准化的组件称为服务,ASP.NET在内部专门维护了一个DI容器来提供所需的服务.要了解这个DI容器以及现实其中的服务提供机制,我们先得知道什么是DI(Dependence Injection),而一旦我们提到DI,又不得不说IoC(Inverse of Control). 目录 一.流程控

【SSH系列】spring中为什么要使用IOC

开篇前言 在前面的博文中,小编主要简单的介绍了spring的入门知识,随着学习的深入,我们知道spring最核心的两大技术,IOC和AOP,这两个技术也是spring最耀眼的地方,在后续的博文中小编将隆重介绍IOC和AOP,今天这篇博文,小编先简单的介绍一下,IOC是什么?在spring中为什么要使用IOC?IOC的优缺点以及IOC的应用. IOC是什么? 控制反转(Inversion of Control,英文缩写为IoC)是一个重要的面向对象编程的法则来削减计算机程序的耦合问题,也是轻量级的