BlueDavy之技術Blog

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

在沒用IoC實現的時候是這樣的：

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

}

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

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

public class A{
 
 private B b;

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

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

}

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

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