面向過程------
想象乙個過程----當我們的計算機技術還沒有這麼發達的時候，所有的**，就是建立在面向過程的。
這種**模式帶來乙個重要的問題，大專案的程式在寫的過程中，會有相當的**量是冗餘重複的。
不僅僅耗時耗力，一不小心就可能讓我們的整個工程出現坍塌事故。
物件導向------
我們在寫**的過程中，發現很多的**例項都是重複的，他們僅僅需要乙個引數例項化，這樣一樣的**就能起到不一樣的
作用，物件導向的程式設計出現了，一切皆可物件化，物件的例項化就是引數轉移的過程。
乙個問題？------
注意上述過程，當我們在寫乙個專案的時候，所有的**建立在類上，類與類之間有一定的依賴關係，倘若你的工程
中有個類跟其他的類一點關係也沒有，那你可以把這個類刪掉了，因為它很可能沒有被編譯。
現在有個問題，建立乙個專案需要不同的類之間的依賴關係，那麼當我們的這個專案有大的變動時，修改其中的乙個類
其他的類及**是否也需要改變？答案是肯定的，那麼在這個過程中，可想而知，重複的工作和沒必要的**以及重新搭建
的工程是怎麼樣的耗時耗力不討好的過程了。
耦合就是專案中類與類之間的依賴關係，就像學生和班級的關係，學生的班級改變後，對應的班主任也不一樣。
類與類之間的依賴越多越深，類與類之間的耦合越大。
介面是抽象的類，其所有的方法和屬性都是抽象的，我們在使用它的時候需要先例項化，建立乙個類來實現它。通過以上描述，當前需要解決的問題是，有沒有一種模式，讓我們在進行類的使用的時候，
可以根據我們的需要進行不同的類之間的依賴關係的重新設定——即依賴注入。
當類和類之間的關係變得可控的時候，以上提出的問題都能夠被解決。
1.我們知道類和類之間之所以出現耦合的關係，是因為物件有自己特定的例項化的時間和過程，即班級的物件必定要在
學生物件之前出現。
基於此，如果我們能夠控制類建立物件的時間，就能夠偽實現類和類的耦合，為什麼是偽實現，因為即使控制了不同
的類建立物件的時間，但是類與類時間的書寫關係並沒有改變。
2.當所有的類都分離，借用第三方的容器，該容器擁有所有類的使用權，你只需要告訴它什麼時候建立哪個物件，並和哪個類
有什麼的關係，這樣我們就實現了類和類之間的無耦合關係。
上述兩個解決方案，顯然第二個更值得嘗試。
控制反轉ioc---將元件間的依賴關係在系統中抽離出來。
依賴注入di-----將元件間的依賴關係通過外部傳參的方式注入。
這裡我們提出兩個概念 ioc 和 di 來實現我們上面提到的第二個解決方案。首先程式設計的過程中進行ioc再根據我們的需要進行di
依賴前和解決問題後的模式如下所示：
可以參考這篇部落格
**層面來看ioc思想
控制反轉 IoC 與依賴注入 DI
最近幾天在 研究容器。發現有幾個理念需要理一下。細一看，又發現根本就是我們之前學過的東西。控制反轉 ioc 與依賴注入 di 這兩個概念有很多相同的內容，只不過是側重不相同。控制反轉 控制反轉 inversion of control，英文縮寫為ioc 是乙個重要的物件導向程式設計的法則來削減電腦程...
控制反轉 IOC 和依賴注入 DI
控制反 從拆解字面上的意思，控制，是指物件建立 銷毀和管理 單例 的控制權，傳統程式設計上這個是交給呼叫方來控制。反轉，是指這些控制權優傳統上的呼叫方反轉為類似乙個容器的東西，統一調配和管理。依賴注入 依賴，其實就是耦合，這裡更多的是呼叫方和操作物件的耦合。注入是指，將某些耦合關係從乙個東西注入到另...
依賴注入（DI）和控制反轉（IOC）
依賴注入是用於實現控制反轉的最常見的方式之一。依賴注入的思想是 當乙個類對另乙個類有依賴時，不在該類內部對依賴的類進行例項化，而是有乙個配置好了的bean.xml檔案，告訴容器所依賴的類，在例項化該類時，容器自動注入乙個依賴的類的例項。傳統的方法就是在類中先例項化依賴的類，然後再呼叫該類中的方法。p...