《Spring 揭秘》讀書心得之第二章 IoC的基本概念
文章目錄
- 《Spring 揭秘》讀書心得之第二章 IoC的基本概念
-
- IoC的理念
- DI的三種方式
-
- Setter注入
- Constructor注入
- Interface注入
- IoC的附加值
IoC的理念
IoC，全稱Inversion of Control。了解IoC，需要了解兩個詞：Inversio和Control。
實際上，IoC作為一種理念，不僅存在于程式設計世界，現實世界也存在哦。著名的就是好萊塢原則“Don’t call us, we will call you”。演員找導演拍戲，那麼“控制”在演員，“控制”表現在演員可以決定找哪位導演；而“反轉”就是“控制”的反轉：由導演來找演員，“控制”表現在導演可以決定找哪位演員；“反轉”之後，導演是不是很輕松了呢？因為導演不需要面對他不需要的演員了啊！
回到程式設計世界裡，要完成一項任務，離不開對象之間的互相協作，而這種協作關系，我們也稱為一種依賴關系；是不是和導演與演員的關系很像呢？像就對了！因為Java本來就是面向對象的程式設計語言，就是為了友善對現實世界的描述嘛~； 前面提到“依賴關系”，那就得想想這依賴關系該如何建立了。
最直覺的是：如果需要，就new一個吧！哪裡需要哪裡new！爸媽再也不用擔心我的程式設計了。 好吧，按照前面的分析，A需要B，那麼A就new一個B。似乎沒問題。但是，我們的目标是什麼？沒有蛀牙。 是高内聚，低耦合啊。A因為要new一個B，那麼總得為B的構造函數傳遞參數吧，這些參數是不是要A來準備？這樣，A中的代碼就知道的太多了。知道太多的類，最後都怎麼了？都高耦合了呗。此時，“控制”在A。我們要反轉的，就是這個依賴關系的建立。
A還是需要一個B的，但是，肯定不是A直接來建立一個B，那麼總得有人來幹這個活吧！代碼哪有什麼歲月靜好，隻是有人在為你負重前行。這個人是誰，暫且不提，但是他一定是個好人，下文稱他為Good Man，簡稱GM。我們來看看A如何獲得B。
DI的三種方式
這裡的DI，全稱為Dependency Injection。依賴注入。沒錯，我們就是通過DI來實作IoC的~。 這裡有三種方式來實作DI。
Setter注入
A通過添加成員變量，并且添加一個B的Setter方法，GM（不知道GM是啥意思？回頭瞅瞅吧）檢測到A中有B，就建立一個B，然後通過A的Setter方法把現成的B給A。
Constructor注入
GM通過往A的構造函數中傳入一個B來達到将其交給A的目的；
Interface注入
這種方法正在被淘汰。。。。它需要A實作一個接口，叫啥不重要，隻需要有一個方法，該方法叫啥也不重要（實際上，這種方法也不重要。。。。），隻要有個B參數就好。GM發現A實作了該接口，就會通過其方法将B傳給A。
這種方法非要A實作一個不重要的接口，不友好；是以，逐漸被抛棄。。
從這三種方法來看，GM不僅是個Good Man，而且還是個Super Man。很厲害，對不對。他還有個名字，叫：IoC Service Provider。
另外，有沒有發現，A要使用B，就得将B作為一個成員變量，那麼如果A隻是有一個方法需要使用B，那也沒有必要把B上升到成員變量的級别，隻需要成為局部變量就好。但是，此場景就不是“注入”了，自然也就不再屬于DI的範疇了。實際上，此時A可以向GM主動索要嘛，就像唐僧對孫悟空說：“你想要就告訴我嘛，你不說，我怎麼知道你想要呢？”；
IoC的附加值
從主動擷取依賴關系的方式轉向IoC方式，不隻是一個方向上的改變，簡單的轉變背後實際上蘊藏着更多的玄機：
- 不會對業務對象構成很強的侵入性；
- 使用IoC後，對象具有更好的可測試性、可重用性和可擴充性
如果要用一句話來概括IoC可以帶給我們什麼，那麼我希望是， IoC是一種可以幫助我們解耦各業務對象間依賴關系的對象綁定方式！
這一章裡，作者沒有從對象解耦的角度對IoC給出介紹，而是從對象綁定方式的角度來介紹IoC的概念；很容易了解。
《Spring 揭秘》在介紹概念的時候，不但會描述這個概念是什麼樣，還會描述為什麼會是這個樣子；學習過程就像是在打通任督二脈，而不是死記招式；超級棒！