我想绝大部分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实现也是以扩展点的方式动态挂入，公平法则啊。
几点综合考虑吧
本博客中的所有文章、随笔除了标题中含有引用或者转载字样的，其他均为原创。转载请注明出处，谢谢！