IOC控制反轉(zhuǎn)依賴注入和new對(duì)象的區(qū)別

spring默認(rèn)是單例模式的，依賴注入其中操作的都是一個(gè)對(duì)象

new對(duì)象

單例中如果要做到注入的效果就是在類的頭部進(jìn)行實(shí)例化對(duì)象，這個(gè)時(shí)候該對(duì)象不管使用與否都貫穿該類的始終。該類對(duì)象不被回收，這個(gè)實(shí)例化對(duì)象也不會(huì)被回收，因?yàn)榇嬖谝脿顟B(tài)。如果要使用多例對(duì)象則最好使用new創(chuàng)建對(duì)象而不是依賴注入，即使依賴注入有多例模式也不推薦。

依賴注入：是指程序運(yùn)行過程中，如果需要調(diào)用另一個(gè)對(duì)象協(xié)助時(shí)，無須再代碼中創(chuàng)建被調(diào)用者，而是依賴外部的注入。spring的依賴注入對(duì)調(diào)用者和被調(diào)用者幾乎沒有任何要求，完全支持對(duì)pojo之間依賴關(guān)系的管理

依賴注入

如果調(diào)用者使用到被調(diào)用對(duì)象才會(huì)從spring容器中取出依賴的對(duì)象注入到使用的類中，如果不用則會(huì)放回spring容器的對(duì)象池中，做到內(nèi)存節(jié)省并且代碼的耦合度也降低。面向接口編程中，讓依賴注入只需要找到符合規(guī)范的接口注入即可實(shí)現(xiàn)調(diào)用者和被調(diào)用者解耦。對(duì)象的調(diào)用關(guān)系由spring管理。

進(jìn)入實(shí)習(xí)之后，就之前不是很理解的依賴注入很好奇，在實(shí)際工作中也有留意使用并且理解多了之后就查閱文檔總結(jié)出這個(gè)結(jié)論，如果有錯(cuò)誤的請(qǐng)大佬指出。 

spring的IOC容器比New對(duì)象究竟好在哪

私以為以上各位都沒有對(duì)spring ioc的精髓講解到位。大多都在很模糊的說是什么，抽象化的表述或者含糊其辭的說概念。

ioc的思想最核心的地方在于，資源不由使用資源的雙方管理，而由不使用資源的第三方管理，這可以帶來很多好處。

• 第一，資源集中管理，實(shí)現(xiàn)資源的可配置和易管理。
• 第二，降低了使用資源雙方的依賴程度，也就是我們說的耦合度。

也就是說，甲方要達(dá)成某種目的不需要直接依賴乙方，它只需要達(dá)到的目的告訴第三方機(jī)構(gòu)就可以了，比如甲方需要一雙襪子，而乙方它賣一雙襪子，它要把襪子賣出去，并不需要自己去直接找到一個(gè)賣家來完成襪子的賣出。它也只需要找第三方，告訴別人我要賣一雙襪子。這下好了，甲乙雙方進(jìn)行交易活動(dòng)，都不需要自己直接去找賣家，相當(dāng)于程序內(nèi)部開放接口，賣家由第三方作為參數(shù)傳入。甲乙互相不依賴，而且只有在進(jìn)行交易活動(dòng)的時(shí)候，甲才和乙產(chǎn)生聯(lián)系。反之亦然。這樣做什么好處么呢，甲乙可以在對(duì)方不真實(shí)存在的情況下獨(dú)立存在，而且保證不交易時(shí)候無聯(lián)系，想交易的時(shí)候可以很容易的產(chǎn)生聯(lián)系。甲乙交易活動(dòng)不需要雙方見面，避免了雙方的互不信任造成交易失敗的問題。因?yàn)榻灰子傻谌絹碡?fù)責(zé)聯(lián)系，而且甲乙都認(rèn)為第三方可靠。那么交易就能很可靠很靈活的產(chǎn)生和進(jìn)行了。

這就是ioc的核心思想。生活中這種例子比比皆是，支付寶在整個(gè)淘寶體系里就是龐大的ioc容器，交易雙方之外的第三方，提供可靠性可依賴可靈活變更交易方的資源管理中心。另外人事代理也是，雇傭機(jī)構(gòu)和個(gè)人之外的第三方。嗯，就這樣，希望對(duì)題主有幫助。

==============update==============

• 在以上的描述中，誕生了兩個(gè)專業(yè)詞匯，依賴注入和控制反轉(zhuǎn)
• 所謂的依賴注入，則是，甲方開放接口，在它需要的時(shí)候，能夠講乙方傳遞進(jìn)來(注入)
• 所謂的控制反轉(zhuǎn)，甲乙雙方不相互依賴，交易活動(dòng)的進(jìn)行不依賴于甲乙任何一方，整個(gè)活動(dòng)的進(jìn)行由第三方負(fù)責(zé)管理。

這就是spring IOC的思想所在，不要只談DI IOC這些概念。

人之所惡在好為人師,不實(shí)知，謹(jǐn)慎言。

下面是我個(gè)人看了上面文章結(jié)合評(píng)論中的問題進(jìn)行的一次回復(fù)：

問：有點(diǎn)小問題，如果是甲方要襪子，那么他也必須依賴于一個(gè)賣襪子的人，這之間就有聯(lián)系了，也就是說甲方也是依賴于乙方的，因?yàn)槿绻曳經(jīng)]有賣襪子的話，甲方也就買不到襪子，自然也就沒法繼續(xù)進(jìn)行，這怎么就解隅了呢？？

答：是解耦的，平時(shí)new A()時(shí)候是要import包地址的，這就已經(jīng)寫死了，以后這個(gè)引用就死死的指向了那個(gè)類，想改變很麻煩，用ac.getbean(“A”)就沒引入包，也就是所謂的不依賴 （就是跟那類A沒關(guān)系），它只從容器找那個(gè)叫A的類，至于你給我的是啥，看容器中咋配置。舉了例子：比如說是個(gè)很常用的dao類，開始你new的很開心，萬一以后需求大改，數(shù)據(jù)庫(kù)mysql換db2了，這個(gè)dao文件基本就得重寫，如果這個(gè)類已經(jīng)封裝編譯為class文件，不能改了怎么辦。又或者你實(shí)例化了一個(gè)常用接口。原來那個(gè)實(shí)現(xiàn)類A不好，要換成B做他的實(shí)現(xiàn)類，重寫他的方法。你就得把項(xiàng)目中所有實(shí)例化的地方都找出來，再改成B（大項(xiàng)目用了很多的話你就一個(gè)一個(gè)改類似，萬一漏了就是不小的bug）。用ioc就沒 這個(gè)麻煩，直接在配置文件中將叫A的bean指向你新寫的類就可以。所以說他依賴的乙方不是賣襪子的，而是一個(gè)中介

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。 

最新評(píng)論