ioc的思想最核心的地方在于,资源不由使用资源的双方管理,而由不使用资源的第三方管理,这可以带来很多好处。

  1. 资源集中管理,实现资源的可配置和易管理。
  2. 降低了使用资源双方的依赖程度,也就是我们说的耦合度。

也就是说,甲方要达成某种目的不需要直接依赖乙方,它只需要达到的目的告诉第三方机构就可以了,比如甲方需要一双袜子,而乙方它卖一双袜子,它要把袜子卖出去,并不需要自己去直接找到一个卖家来完成袜子的卖出。

它也只需要找第三方,告诉别人我要卖一双袜子。这下好了,甲乙双方进行交易活动,都不需要自己直接去找卖家,相当于程序内部开放接口,卖家由第三方作为参数传入。甲乙互相不依赖,而且只有在进行交易活动的时候,甲才和乙产生联系。反之亦然。

这样做什么好处么呢,甲乙可以在对方不真实存在的情况下独立存在,而且保证不交易时候无联系,想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面,避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系,而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是,支付宝在整个淘宝体系里就是庞大的ioc容器,交易双方之外的第三方,提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是,雇佣机构和个人之外的第三方。

在以上的描述中,诞生了两个专业词汇,依赖注入和控制反转

所谓的依赖注入,则是,甲方开放接口,在它需要的时候,能够讲乙方传递进来(注入)

所谓的控制反转,甲乙双方不相互依赖,交易活动的进行不依赖于甲乙任何一方,整个活动的进行由第三方负责管理。

这就是spring IOC的思想所在,不要只谈DI IOC这些概念。

人之所恶在好为人师,不实知,谨慎言。

问:有点小问题,如果是甲方要袜子,那么他也必须依赖于一个卖袜子的人,这之间就有联系了,也就是说甲方也是依赖于乙方的,因为如果乙方没有卖袜子的话,甲方也就买不到袜子,自然也就没法继续进行,这怎么就解隅了呢??

答:是解耦的,平时new A()时候是要import包地址的,这就已经写死了,以后这个引用就死死的指向了那个类,想改变很麻烦,用ac.getbean(“A”)就没引入包,也就是所谓的不依赖 (就是跟那类A没关系),它只从容器找那个叫A的类,至于你给我的是啥,看容器中咋配置。

举了例子:比如说是个很常用的dao类,开始你new的很开心,万一以后需求大改,数据库mysql换db2了,这个dao文件基本就得重写,如果这个类已经封装编译为class文件,不能改了怎么办。又或者你实例化了一个常用接口。

原来那个实现类A不好,要换成B做他的实现类,重写他的方法。你就得把项目中所有实例化的地方都找出来,再改成B(大项目用了很多的话你就一个一个改类似,万一漏了就是不小的bug)。

用ioc就没这个麻烦,直接在配置文件中将叫A的bean指向你新写的类就可以。所以说他依赖的乙方不是卖袜子的,而是一个中介

来源:zhihu.com/question/23277575/answer/24259844

作者:OneNoodle