海鷗航際

          JAVA站
          posts - 11, comments - 53, trackbacks - 1, articles - 102

          IOC和Dependency Injection

          Posted on 2005-01-14 20:25 海天一鷗 閱讀(278) 評論(0)  編輯  收藏 所屬分類: J2EE

          介紹

          其實IOC模式并不是什么新的東西,它是一種很普遍的概念(或者說結構),GoF中的Template Method 就是IOC的結構。顧名思義,IOC即控制反轉。著名的好萊塢原則:“Don’t Call us, We will call you”,以及Robert C. Martin在其敏捷軟件開發中所描述的依賴倒置原則(Dependency Inversion Principle, DIP)都是這一思想的體現。Dependency InjectionMartin FlowerIOC模式的一種擴展的解釋,下面我們從一個簡單的實例開始。

           

          考慮一個Button來控制Lamp的開和關。

          如下的類圖,并寫下了代碼。

           

          public class Button {

                 private Lamp lnkLamp;

                 public void poll() {

                        lnkLamp.Turnon();

                 }

          }

          但是馬上發現這個設計的問題,Button類直接依賴于Lamp類,這個依賴關系意味著當Lamp類修改時,Button類會受到影響。此外,想重用Button類來控制類似與Lamp的另外一個對象則是不可能的。即Button控制Lamp,并且只能控制Lamp

          顯然,我違反了“高層模塊不應該依賴于底層模塊,兩者都應該依賴于抽象;抽象不應該依賴于具體實現,細節應該依賴于抽象” 這一原則(DIP原則)。

          考慮到上述問題,自然地想到應該抽象出一個接口,來消除ButtonLamp的依賴,于是設計如下:


              這樣,我們倒置了
          ButtonLamp的依賴關系,使得Lamp依賴于SwitchableDevice接口,SwitchableDevice并沒有依賴于Button類,任何知道如何操縱該接口的對象都可以控制Lamp。同時Button不只是可以控制Lamp,還可以控制同樣實現SwitchableDevice接口的如ComputerCell Phone等等。回頭想想,這種做法好像似曾相識,拍拍腦袋,哦!這不是GoF策略(Strategy)模式嗎?!正是,不經意間我就應用了設計模式(有點得意哦~~~~)。

          現在再來考慮一個問題,剛才的做法雖然倒置了依賴關系,但是如果將Button作為一個應用程序來控制Lamp或者同樣實現SwitchableDeviceComputerCell Phone等,則代碼可能如下:

          public class Button {

          private SwitchableDevice lnkLamp;

          public Button(){

              lnkLamp= new Lamp();

          }

          }

          也就是說ButtonLamp之間仍然存在《creates》這樣的依賴關系。

          為了解除這種依賴關系,首先看GoF能作些什么。顯然,這個地方應該用Factory模式,將對象的創建交給Factory Class來處理,這樣雖然解開了Lamp組件與我們應用程序Button之間的耦合關系,但是組件的創建仍然是顯式的(explicitly),在組件更改時仍需要重新編譯。

          另外,通過一個ServiceLocatorlook up實現類也是一種解除耦合的辦法,看到這兒,你不禁會想EJB不就是這么實現的嘛,U are Right! Rod Johnson 在其大作J2EE without EJB中稱這種方式為Dependency Look up,但這種方式也有其弊端,比如無法脫離容器環境,以及不利于Unit test等。

          Don’t Call us, We will Call you”,這個原則啟示我們應該換一個思路,不應該在應用類中創建具體對象的實例,而是應該將具體對象實例的創建插入(plug)或者說注射(inject)到應用類中,這大概是依賴注射名稱的由來吧。

          這種實現方式需要在應用類以及調用組件之間建立一個assembler來解除兩者之間的依賴,看起來與前面的方式沒有太大區別,來看一下結構:


              仔細查看會發現還是有比較大的不同,依賴關系是相反的,也就是說這個過程中依然倒置了依賴關系。
          Lamp通過Assembler將其創建過程注射到了Button中,從而消除了兩者之間的耦合,增加了靈活性。

          下面我們看一下具體的實現,在PicoContainer以及Spring中有著其不同的實現,分別代表了兩種類型的Dependency Injection, Constructor Injection Setter Injection

          private MutablePicoContainer configureContainer() {

                  MutablePicoContainer pico = new DefaultPicoContainer();

                  pico.registerComponentImplementation(SwitchableDevice.class, Lamp.class);

                  pico.registerComponentImplementation(Button.class);

                  return pico;

          }

          然后可以通過MutablePicoContainergetComponentImplementation方法獲得實現類,調用其poll方法控制Lamp的開關,這樣一來,兩者之間的耦合通過PicoContainer提供的Assembler完全消除了。

          Spring則通過一個XML格式的配置文件,將兩者聯系起來,使用時,通過ApplicationContext獲得Button Bean,再調用其方法實現,同樣也消除了耦合關系

          主站蜘蛛池模板: 佛坪县| 隆安县| 溧阳市| 嘉鱼县| 双峰县| 竹北市| 天水市| 磴口县| 霞浦县| 沛县| 汝阳县| 南漳县| 新宁县| 邹平县| 溧水县| 卢龙县| 麻栗坡县| 安丘市| 连南| 潮安县| 双江| 乐业县| 石柱| 灵璧县| 宣威市| 海安县| 华安县| 双峰县| 涪陵区| 通辽市| 明光市| 来宾市| 阳朔县| 玛沁县| 奎屯市| 报价| 陕西省| 光山县| 巴东县| 舒兰市| 双城市|