IoC & Extension Point

          昨天在fog討論到這個問題,fog認為Extension Point是按照IoC的思路實現(xiàn)出來的,我來談談我的觀點,我卻認為Extension Point并不是按照IoC思路來實現(xiàn)的,甚至可以說兩者沒有關系。
          首先來說說IoC,IoC,全稱Inversion of Control,Martin Fowler認為這個詞有些不恰當,建議改為DI,為什么呢?其實這是因為IoC的本質決定的,IoC是什么,其主要作用是解耦,分離關注點,通俗點說就是使得調用者和被調用者之間沒有直接的耦合,而只是接口的耦合,舉例來說:

          在沒用IoC實現(xiàn)的時候是這樣的:

          public class A{
           
           
          public void execute(){
            B b
          =new BImpl();
            b.execute();
           }


          }


          可見在這里造成的一個問題就是調用者A和被調用者B的實現(xiàn)構成了一個直接的依賴,為什么Martin Fowler要建議改名成DI呢,原因就在這了,這里造成的是抽象對實現(xiàn)的依賴,這不用說,是嚴重違反OO中依賴抽象而不依賴實現(xiàn)這一原則的,所以稱為DI確實更符合一些。

          再來看一下使用了IoC后是這樣的:

          public class A{
           
           
          private B b;

           
          public void setB(B b){
            
          this.b=b;  
           }


           
          public void execute(){
            b.execute();
           }
           

          }


          可見在這里調用者A和被調用者B是接口的依賴,而不是實現(xiàn)的依賴,這就實現(xiàn)了調用者對于被調用者具體實現(xiàn)依賴的解耦。
          當然,也許諸位看官會說可以用Factory之類的模式來實現(xiàn)對具體依賴的解耦,但那樣同樣造成一個問題就是調用者和被調用者的Factory耦合,而在IoC中是不會有這個問題的,調用者和被調用者之間只有清晰的接口依賴。
          根據(jù)上面這些解釋,我們可以看出IoC最大的好處在于解耦調用者對于被調用者具體實現(xiàn)的依賴。

          現(xiàn)在來說說Extension Point,Extension Point是Eclipse為支持Plugin擴展而做的一種設計,舉例來說吧,在工具欄這個Plugin中,必然需要提供某種方法能使得其他Plugin可加入按鈕至工具欄中,那么該怎么去做呢,在Extension Point中是這么實現(xiàn)的,工具欄Plugin提供了一個這樣的Extension Point,其他的Plugin只需要實現(xiàn)這個Extension Point即可加入按鈕至工具欄中,工具欄的Plugin在可擴展的地方通過對于容器中Extension Point注冊信息的獲取來取得所有實現(xiàn)了當前Extension Point的類,并相應的進行調用。
          這里還是得羅嗦一下Extension Point的實現(xiàn)思路,在Eclipse中是這么做的,首先它會根據(jù)各Plugin提供的Extension Point構成一個Extension Point的信息集合,之后根據(jù)各Plugin提供的Extension Point的實現(xiàn)構成Extension Point Registry,而各提供了Extension Point的Plugin必然會在可擴展的地方調用這個Registry獲取相應實現(xiàn)了此Extension Point的集合,通過所提供的Extension Point Interface做相應的callback來實現(xiàn)擴展。
          首先我們來看,如果Extension Point是采用IoC思想來實現(xiàn)的,那么我們可以按照IoC思想來進行分析,那么提供Extension Point的Plugin就是調用者,提供Extension Point實現(xiàn)的Plugin就是被調用者,按照IoC思想是為了解耦調用者對于被調用者實現(xiàn)的依賴,那么我們可以看出這個命題是不成立的,這里的關鍵在于提供Extension Point的Plugin并不依賴于實現(xiàn)Extension Point的Plugin,它才不關心哪些Plugin實現(xiàn)了它的Extension Point,沒有直接的依賴關系又何來IoC一說。
          其次我們來看Extension Point的設計目的是為了什么?它設計的目的是為了Plugin可被擴展,而不是說用于解除Plugin之間依賴的問題。
          其實Extension Point的設計思路很簡單,是類似Template的模式,只是它把所有實現(xiàn)了此Template的信息都集中存儲了,并且由提供了Template的類去獲取了所有的這些信息,鑒于此我還是堅持自己的觀點Extension Point并不是按照IoC的思想來設計的,兩者并沒什么關系。

          posted on 2005-07-15 10:47 BlueDavy 閱讀(964) 評論(2)  編輯  收藏 所屬分類: Java

          評論

          # re: IoC & Extension Point 2005-07-16 00:09 落魄的程序員

          我認同fog的觀點
          而且DI和Template模式正是IoC在面向對象領域的表現(xiàn)形式
          DI和模板方法模式的區(qū)別在于
          DI用于解除創(chuàng)建依賴
          模板方法用于解除行為依賴

          你的這幾句似乎有邏輯問題:
          “我們可以按照IoC思想來進行分析,那么提供Extension Point的Plugin就是調用者,提供Extension Point實現(xiàn)的Plugin就是被調用者,按照IoC思想是為了解耦調用者對于被調用者實現(xiàn)的依賴,那么我們可以看出這個命題是不成立的,這里的關鍵在于提供Extension Point的Plugin并不依賴于實現(xiàn)Extension Point的Plugin”

          真是因為EP的提供者不依賴于EP的實現(xiàn)者,所以才符合IoC的思想
          也就是組件IoC
          而不是因為EP中沒有IoC要解耦的那種依賴所以不叫IoC

          因為它符合IoC,所以不存在IoC要解決的問題,這個是不是有點繞?
          ^_^
          因為符合IoC,所以問題已經被解決掉了,自然不存在了
            回復  更多評論   

          # re: IoC & Extension Point 2005-07-16 17:34 Programmer's Life

          恩,說的是,那個邏輯分析我寫的是有問題的,應該從EP解決的問題點來分析  回復  更多評論   

          公告

           









          feedsky
          抓蝦
          google reader
          鮮果

          導航

          <2005年7月>
          262728293012
          3456789
          10111213141516
          17181920212223
          24252627282930
          31123456

          統(tǒng)計

          隨筆分類

          隨筆檔案

          文章檔案

          Blogger's

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 龙陵县| 奉化市| 塔城市| 金坛市| 沂源县| 湖南省| 海伦市| 广水市| 贡山| 达日县| 长岭县| 茶陵县| 梅州市| 平利县| 伊通| 嘉峪关市| 鲜城| 马龙县| 汝城县| 扬中市| 板桥市| 锦屏县| 长沙市| 视频| 岳阳市| 朔州市| 麻江县| 通河县| 玉溪市| 壶关县| 张家界市| 清河县| 广水市| 格尔木市| 邵东县| 璧山县| 策勒县| 平谷区| 乌兰浩特市| 防城港市| 遵义市|