【Eclipse插件开发】在什么情况下创建扩展点

【Eclipse插件开发】在什么情况下创建扩展点

        我想绝大部分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实现也是以扩展点的方式动态挂入，公平法则啊。

        几点综合考虑吧

本博客中的所有文章、随笔除了标题中含有引用或者转载字样的，其他均为原创。转载请注明出处，谢谢！