springIoc 講解

• 僅爲做筆記用
• 什麼是IOC？
• IOC解決了什麼問題？
• IOC 和 DI 的區別？

• 首先聲明：IOC & AOP不是Spring提出來的，它們在Spring之前其實已經存在了，只不過當時更加偏向於理論。 Spring 在技術層次將這兩個思想進行了很好的實現。

  什麼是 IOC

  IOC （Inversion of control ）控制反轉/反轉控制。它是一種思想不是一個技術實現。描述的是：Java 開發領域對象的創建以及管理的問題。

  例如：現有 類A依賴於類B

  傳統的開發方式：往往是在類A中手動通過new關鍵字來 new 一個B的對象出來

  使用IOC思想的開發方式： 不通過new關鍵字來創建對象，而是通過IOC容器(Spring 框架) 來幫助我們實例化對象。我們需要哪個對象，直接從IOC容器裏面過去即可。

  從以上兩種開發方式的對比來看：我們 “喪失了一個權力” (創建、管理對象的權力)，從而也得到了一個好處（不用再考慮對象的創建、管理等一系列的事情）

  爲什麼叫控制反轉

  控制： 指的是對象創建（實例化、管理）的權力

  反轉： 控制權交給外部環境（Spring框架、IOC容器）

• IOC 解決了什麼問題

  IOC 主要解決的是對象之間的耦合問題。

  例如：現有一個針對User的操作，利用 Service 和 Dao 兩層結構進行開發

  在沒有使用IOC思想的情況下，Service 層想要使用 Dao層的具體實現的話，需要通過new關鍵字在UserServiceImpl 中手動 new出 IUserDao 的具體實現類 UserDaoImpl（不能直接new接口類）。

• 很完美，這種方式也是可以實現的，但是我們想象一下如下場景：開發過程中突然接到一個新的需求，針對對IUserDao 接口開發出另一個具體實現類。因爲Server層依賴了IUserDao的具體實現，所以我們需要修改UserServiceImpl中new的對象。如果只有一個類引用了IUserDao的具體實現，可能覺得還好，修改起來也不是很費力氣，但是如果有許許多多的地方都引用了IUserDao的具體實現的話，一旦需要更換IUserDao的實現方式，那修改起來將會非常的頭疼。

• 使用IOC的思想，我們將對象的控制權（創建、管理）交有IOC容器去管理，我們在使用的時候直接向IOC容器 “要” 就可以了、

• IOC 和 DI 的區別

  IOC 和 DI 描述的是同一件事情（對象實例化以及依賴關係的維護），只不過角度不同。

  IOC （Inversion of control ） 控制反轉/反轉控制。是站在對象的角度，對象實例化以及管理的權限（反轉）交給了容器。

  DI （Dependancy Injection）依賴注入。是站在容器的角度，容器會把對象依賴的其他對象注入（送進去）。例如：對象A 實例化過程中因爲聲明瞭一個B類型的屬性，那麼就需要容器把B對象注入到A中。

  什麼是AOP