spring中IOC控制反轉依賴註入和new對象的區別說明

IOC控制反轉依賴註入和new對象的區別

spring默認是單例模式的,依賴註入其中操作的都是一個對象

new對象

單例中如果要做到註入的效果就是在類的頭部進行實例化對象,這個時候該對象不管使用與否都貫穿該類的始終。該類對象不被回收,這個實例化對象也不會被回收,因為存在引用狀態。如果要使用多例對象則最好使用new創建對象而不是依賴註入,即使依賴註入有多例模式也不推薦。

依賴註入:是指程序運行過程中,如果需要調用另一個對象協助時,無須再代碼中創建被調用者,而是依賴外部的註入。spring的依賴註入對調用者和被調用者幾乎沒有任何要求,完全支持對pojo之間依賴關系的管理

依賴註入

如果調用者使用到被調用對象才會從spring容器中取出依賴的對象註入到使用的類中,如果不用則會放回spring容器的對象池中,做到內存節省並且代碼的耦合度也降低。面向接口編程中,讓依賴註入隻需要找到符合規范的接口註入即可實現調用者和被調用者解耦。對象的調用關系由spring管理。

進入實習之後,就之前不是很理解的依賴註入很好奇,在實際工作中也有留意使用並且理解多瞭之後就查閱文檔總結出這個結論,如果有錯誤的請大佬指出。 

spring的IOC容器比New對象究竟好在哪

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

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

  • 第一,資源集中管理,實現資源的可配置和易管理。
  • 第二,降低瞭使用資源雙方的依賴程度,也就是我們說的耦合度。

也就是說,甲方要達成某種目的不需要直接依賴乙方,它隻需要達到的目的告訴第三方機構就可以瞭,比如甲方需要一雙襪子,而乙方它賣一雙襪子,它要把襪子賣出去,並不需要自己去直接找到一個賣傢來完成襪子的賣出。它也隻需要找第三方,告訴別人我要賣一雙襪子。這下好瞭,甲乙雙方進行交易活動,都不需要自己直接去找賣傢,相當於程序內部開放接口,賣傢由第三方作為參數傳入。甲乙互相不依賴,而且隻有在進行交易活動的時候,甲才和乙產生聯系。反之亦然。這樣做什麼好處麼呢,甲乙可以在對方不真實存在的情況下獨立存在,而且保證不交易時候無聯系,想交易的時候可以很容易的產生聯系。甲乙交易活動不需要雙方見面,避免瞭雙方的互不信任造成交易失敗的問題。因為交易由第三方來負責聯系,而且甲乙都認為第三方可靠。那麼交易就能很可靠很靈活的產生和進行瞭。

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

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

  • 在以上的描述中,誕生瞭兩個專業詞匯,依賴註入和控制反轉
  • 所謂的依賴註入,則是,甲方開放接口,在它需要的時候,能夠講乙方傳遞進來(註入)
  • 所謂的控制反轉,甲乙雙方不相互依賴,交易活動的進行不依賴於甲乙任何一方,整個活動的進行由第三方負責管理。

這就是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指向你新寫的類就可以。所以說他依賴的乙方不是賣襪子的,而是一個中介

以上為個人經驗,希望能給大傢一個參考,也希望大傢多多支持WalkonNet。 

推薦閱讀: