我想絕大部分Eclipse插件開發人員對擴展點這個概念應該都比較熟悉了，那么什么時候決定創建自己的擴展點呢？簡單的說一下俺的看法，錯了不要笑話。
為什么說這個問題呢？親眼看到一些插件開發剛入門的人，不怎么懂得擴展點相關的東西，也談不上理解擴展點機制，所以這個時候從來不自己定義新的擴展點；過了一段時間之后，感覺使用Eclipse擴展點有點經驗了（尤其是workbench相關的擴展點肯定經常使用），開始定義自己的擴展點了，....，災難發生了，亂定義擴展點，各種想法的擴展點都出來了.....
背景知識：
【Eclipse插件開發】Eclipse中的擴展點機制存在的理由
在什么情況下你才會創建你自己的擴展點呢？一句話：允許擴展，而且是主動邀請外部擴展。
在定義擴展點之前，你可以試著問一下自己如下兩個問題：
1、從需求角度考慮，要這種需求存在嗎？
2、從技術視角思考，你要用擴展點描述的東西是不是屬于模塊內部的實現？
3、從技術視角思考，即使需要擴展，真的需要動態掛入嗎？java默認的靜態注入不可以？
4、從技術視角思考，你處的模塊是不是一個上層功能模塊？
關于第一點，就去看一下需求文檔，對應的功能點需求描述如何。這個時候從客戶的角度看，客戶會針對你的模塊進行二次開放嗎，如果開發，需要注冊擴展到你的模塊嗎？
關于第二點，如果你要用擴展點描述的東西不是對模塊外部可見的，是屬于你模塊里面的內部實現，擴展點肯定用不上。
關于第三點，是很多新人非常容易犯的錯誤，將語言特性和平臺機制混在了一起。舉個例子，假設你定義了一個策略接口IPolicy，有個對應的manager類型的角色在管理IPolicy實例，現有實現PolicyA、PolicyB，
1 public class PolicyManager {
2 private static PolicyManager manager;
3
4 private List<IPolicy> policyList = new ArrayList<IPolicy>(5);
5
6 /**
7 * sinleton
8 */
9 private PolicyManager() {
10 policyList.add(new PolicyA());
11 policyList.add(new PolicyB());
12 }
13
14 public static PolicyManager getInstance() {
15 if (manager == null)
16 manager = new PolicyManager();
17
18 return manager;
19 }
20
21 public static IPolicy[] getPolicys() {
22 //TODO:
23 }
24 }
而且你感覺以后還會有有PolicyC加入。那就加入好了，加入的時候望你的manager里面用代碼注冊一下就可以了。那可能會問，這樣不是修改代碼了嗎，如果用擴展點，那么不就不用修改manager的代碼了？ 要記住，擴展點是平臺機制，比語言特性高一個level。在這種場景下，除非你確實需要外部參與提供新的IPolicy實現（利用擴展點動態掛入），否則就老實用java語言支持的吧。
關于第四點，看一下Eclipse自身提供的擴展點就知道了。Eclipse中大部分擴展點基本上都是在兩中類型模塊中提供的：一是基礎模塊，例如runtime、resource management、workbench；二是可能需要二次定制開發的模塊，例如JDT，因為很多場景下用戶會基于JDT進行擴展開發，往JDT中提供自己的擴展。 如果你的模塊是一個上層的功能模塊，而且也可以肯定不會有其他模塊會依賴于它，那么怎么可能會存在擴展點呢？？？如果你現在做的是一個IDE，創建了自己的工程類型，那么現有的文件類型就有可能會擴展。你現在在設計一個project builder，正常的設計邏輯當然是針對不同文件類型去調用對應的編譯器，那這種編譯器就需要動態掛入了。例如你的針對文件的編譯器接口是IModelCompiler，那你就創建一個compiler擴展點，你現有的compiler實現也是以擴展點的方式動態掛入，公平法則啊。
幾點綜合考慮吧
本博客中的所有文章、隨筆除了標題中含有引用或者轉載字樣的，其他均為原創。轉載請注明出處，謝謝！