關於IOC和DI的理解

IOC：Inversion of Control 控制反轉

DI:Dependency Injection 依賴注入

控制反轉，從字面意思來看，就是控制權又被動變主動，最後又變回被動。

舉個例子：

你的主管要求你作一件事情，這個時候就存在這麼幾個過程，

主管命令你作事情（這個時候主動權在主管，你是被動的）

你接到命令作事情（這個時候主題是你，你是主動的，控制權在你手裏）

你完成事情（這個時候主題依然是你，控制權在你手裏）

報告主管作完事情（主動權又叫交到主管手裏了）

上面的整個過程就完成了一次IOC，從上面能夠看出，IOC的基本思想是控制權的轉換過程。

舉個代碼的例子：

假若有Class A，Class B，在A內部會初始化一個B，調用B的一個方法DoMethod

public Class B
{
　　public void DoMethod（）
　　{
　　  // do somthing；
    }
}

public Class A
{
  public void Excute（）
  {
    B b = new B（）；
     b.DoMethod（）；
  }
}

 假如在Main函數中以下執行：

　　A a = new A();
　　a.Excute();

從這兩行代碼來看，事實上也存在一個IOC的過程，a——>b——>a，理解的關鍵點就在在A的內部調用Excute的時候，方法b.DoMethod的執行。

理解了IOC，咱們再看一下DI。

從上面A調用B咱們能夠看出，在初始化一個A的實例時，也必須實例化一個B，也就是說若是沒有B或者B出了問題，A就沒法實例化，這就產生了一種依賴，就是A依賴B，這種依賴從設計的角度來講就是耦合，顯然它是沒法知足高內聚低耦合的要求的。這個時候就須要解耦，固然解耦有不少種方法，而DI就是其中一種。無論任何一種解耦方法，都不是說使A和B徹底沒有關係，而是把這種關係的實現變得隱晦，不那麼直接，可是又很容易實現，並且易於擴展，不像上面的代碼那樣，直接new一個B出來。

那爲何咱們老是把IOC和DI聯繫到一塊兒呢？是由於DI的基本思想就是IOC，而體現IOC 思想的方法還有另一個，那就是Service Locator，這個方法好像涉及到的不多。

DI，依賴注入，從字面意思就能夠看出，依賴是經過外接注入的方式來實現的。這就實現瞭解耦，而DI的方式一般有三種，

 構造器注入

 屬性設置器注入

 接口注入（我感受接口注入是同時存在於上兩種注入方式的，而不該該獨立出來）

以上的闡述只是爲了先讓咱們能對IOC和DI有一個感性的理解，那麼IOC真正解決的問題是什麼呢？

咱們講了那麼多主動被動的問題，那咱們是從什麼視角來看待這個問題的呢？

所謂爲何你是主動，而我不是主動呢？這就須要一個參照物，那這個參照物是什麼呢？就是容器，在容器中來體現主動和被動。

用白話來說，就是由容器控制程序之間的關係，而非傳統實現中，由程序代碼直接操控。這也就是所謂「控制反轉」的概念所在：控制權由應用代碼中轉到了外部容器，控制權的轉移，是所謂「反轉」，這是一般對IOC的一個解釋。

從容器的角度來看主動和被動，和由容器來控制程序之間的關係，應該是相通的，是一個意思。

IOC要解決的就是程序之間調用的一個問題，它應該是一個思想層面的東西，是一箇中心，就像一支樂隊的指揮，而程序就是樂器，經過指揮來協調各類樂器，來演奏出美好的音樂來。

 

如下文字參考：http://www.cnblogs.com/gooddasenlin/archive/2009/03/02/1401631.html

Interface Driven Design 接口驅動

接口驅動有不少好處，能夠提供不一樣靈活的子類實現，增長代碼穩定和健壯性等等，可是接口必定是須要實現的，也就是以下語句早晚要執行：AInterface a = new AInterfaceImp(); 這樣一來，耦合關係就產生了。

如：

Class A
{
   AInterface a;
   A(){}
   aMethod()
   {
     a = new AInterfaceImp();
   }
}

 

ClassA與AInterfaceImp就是依賴關係，若是想使用AInterface的另一個實現就須要更改代碼了。

固然咱們能夠創建一個Factory來根據條件生成想要的AInterface的具體實現，即：

InterfaceImplFactory
{
   AInterface create(Object condition)
   {
      if(condition = condA)
        {
          return new AInterfaceImpA();
        }
      elseif(condition = condB)
        {
          return new AInterfaceImpB();
        }
      else
        {
          return new AInterfaceImp();
        }
    }
}

 

表面上是在必定程度上緩解了以上問題，但實質上這種代碼耦合並無改變。

經過IoC模式能夠完全解決這種耦合，它把耦合從代碼中移出去，放到統一的XML文件中，經過一個容器在須要的時候把這個依賴關係造成，即把須要的接口實現注入到須要它的類中，這可能就是「依賴注入」說法的來源了。

IOC模式系統中，經過引入實現IOC模式的IOC容器，便可由IOC容器來管理對象的生命週期、依賴關係等，從而使得應用程序的配置和依賴性規範與實際的應用程序代碼分開。其中一個特色就是經過文本的配置文件進行應用程序組件間相互關係的配置，而不用從新修改並編譯具體的代碼。

當前比較知名的IOC容器有：Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。其中，輕量級的有Pico Container、Avalon、Spring、HiveMind等，超重量級的有EJB，而半輕半重的有容器有JBoss，Jdon等。

能夠把IoC模式看作是工廠模式的昇華，能夠把IoC看做是一個大工廠，只不過這個大工廠裏要生成的對象都是在XML文件中給出定義的，而後利用Java 的「反射」編程，根據XML中給出的類名生成相應的對象。從實現來看，IoC是把之前在工廠方法裏寫死的對象生成代碼，改變爲由XML文件來定義，也就是把工廠和對象生成這二者獨立分隔開來，目的就是提升靈活性和可維護性。

IoC中最基本的Java技術就是「反射」編程。反射又是一個生澀的名詞，通俗的說反射就是根據給出的類名（字符串）來生成對象。這種編程方式可讓對象在生成時才決定要生成哪種對象。反射的應用是很普遍的，象Hibernate、String中都是用「反射」作爲最基本的技術手段。

IoC最大的好處是什麼？由於把對象生成放在了XML裏定義，因此當咱們須要換一個實現子類將會變成很簡單（通常這樣的對象都是現實於某種接口的），只要修改XML就能夠了。