我想绝大部分Eclipse插件开发人员对扩展点这个概念应该都比较熟悉了，那 么什么时候决定创建自己的扩展点呢？简单的说一下俺的看法，错了不要笑话。
为什么说这个问题呢？亲眼看到一些插件开发刚入门的人，不怎么懂得扩展 点相关的东西，也谈不上理解扩展点机制，所以这个时候从来不自己定义新的扩 展点；过了一段时间之后，感觉使用Eclipse扩展点有点经验了（尤其是 workbench相关的扩展点肯定经常使用），开始定义自己的扩展点了，….，灾 难发生了，乱定义扩展点，各种想法的扩展点都出来了…..
背景知识：【Eclipse插件开发】Eclipse中的扩展点机制存在的理由
在什么情况下你才会创建你自己的扩展点呢？一句话：允许扩展，而且是主 动邀请外部扩展。
在定义扩展点之前，你可以试着问一下自己如下两个问题：
1、从需求角度考虑，要这种需求存在吗？
2、从技术视角思考，你要用扩展点描述的东西是不是属于模块内部的实现？
3、从技术视角思考，即使需要扩展，真的需要动态挂入吗？java默认的静态 注入不可以？
4、从技术视角思考，你处的模块是不是一个上层功能模块？
关于第一点，就去看一下需求文档，对应的功能点需求描述如何。这个时候 从客户的角度看，客户会针对你的模块进行二次开放吗，如果开发，需要注册扩 展到你的模块吗？
关于第二点，如果你要用扩展点描述的东西不是对模块外部可见的，是属于 你模块里面的内部实现，扩展点肯定用不上。
关于第三点，是很多新人非常容易犯的错误，将语言特性和平台机制混在了 一起。举个例子，假设你定义了一个策略接口IPolicy，有个对应的manager类型 的角色在管理IPolicy实例，现有实现PolicyA、PolicyB，
1 public class PolicyManager {2 private static PolicyManager manager;34 private List policyList = new ArrayList(5);56 /**7 * sinleton8 */9 private PolicyManager() {10 policyList.add(new PolicyA());11 policyList.add(new PolicyB());12 }1314 public static PolicyManager getInstance() {15 if (manager == null)16 manager = new PolicyManager();1718 return manager;19 }2021 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实现也是 以扩展点的方式动态挂入，公平法则啊。
几点综合考虑吧
值不值得，真是不足为外人道，自己心里有数就行。
