繼第一節。

（1）IOC與DI的理解

IOC（Inversion of Control）:其思想是反轉資源獲取的方向，傳統的資源獲取方式需要元件向容器索取，作為迴應，容器返回資源給元件。而應用了IOC以後，容易主動的將資源推送給元件，元件需要做的是以一種合適的方式接受資源（例如setter、構造器）。這種行為也被稱為被動形式。

DI（Dependency Injection）--IOC另一種表達形式：即元件以一些預定好的方式（setter）接受來自容器的資源。相較於IOC，這種表述更為直接。

舉例：買菜。傳統的買菜就是我們到菜市場挑選菜，然後放到籃子裡買回來。是我們主動去買菜。

採用IOC的思想，還是買菜，但是我們不需要去菜市場了，會有人把菜送到我們家來。這樣買菜就變得被動了。

例項

舉個小例子把，運用到框架如SSH的時候，我們在action（控制器類）裡會需要用到資料庫dao層的類，一般我們會有業務層biz，用於做action與dao之間的橋樑，如果不採用IOC，在action裡面會需要dao層，和biz層的例項，這樣增加業務邏輯的耦合度，為了降低這種耦合度，我們用到IOC，在IOC容器裡面裝配，我們就不需要dao，和biz層的例項了，只需要在action裡面新增接受方法(setter)即可。等於說dao依賴注入進了biz。

（2）IOC的由來

①IOC前生---分離介面與實現

這個類圖的理解是這樣的：我們有個報表服務站（ReportService）需要接受報表，有兩個報表生成器PdfReportGenerator, HtmlReportGenerator。這兩個生成器繼承ReportGenerator介面。最原始的方式，我們在報表服務站用到這兩種生成器，需要知道這個生產器和它的父類介面，耦合度極高，可能這張圖看不出什麼，但是如果報表生成器有一萬個呢，那我們的服務站是不是需要知道這一萬個報表的生產方式？

②IOC前生---採用工廠設計模式

繼分離介面實現來說，工廠模式跨出了一步，我們建立一個工廠用來生產PdfReportGenerator報表和HtmlReportGenerator報表，這個工廠繼承ReportGenerator介面，我們的報表站只需要知道工廠和ReportGenerator介面就可以了，具體的報表生產方式並不需要知曉，報表的生產交給工廠來做，做好了交給服務站。這樣耦合程度就有了大大改善。

③IOC---控制反轉

在IOC的模式下，報表服務站只需要知道ReportGenerator介面和提供setter方法接受即可，其他的交給IOC容器來處理。IOC容器主動找到這個元件，為這個元件注入值（需要在配置資訊裡提供PdfReportGenerator的bean資訊）。這樣看來報表服務站就輕鬆多了，它只需要知道一個藉口，其他的類會由IOC主動給你。我們就可以在服務站痛痛快快的寫業務程式碼啦。