我想絕大部分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實現也是 以擴展點的方式動態掛入，公平法則啊。
幾點綜合考慮吧
