合理的自定义扩展点

Eclipse中提供了各种各样的用于扩展Eclipse功能的扩展点。

有时候，我们也要考虑提供合适的自定义扩展点来使用得应用的实现和扩展更加简单容易。

 

例子一：

 

例如以前做了一个编辑SA中各种SU的配置文件的扩展，一开始做法就很傻，把所有的类型的编辑实现都在一个插件实现类中，然后在createControl()的时候，根据用户选择的类型，就会有大致如下的实现方式：

 

if(...){

    a.createControl();

}else if(....){

     b.createControl();

}....

 

后来我就建议他们稍稍修改一下，定义一个扩展点来实现不同类型的选择，例如定义一个扩展点：com.....type.editor

然后实现的时候需要提供一个type类型和一个对应的实现类：

例如 type="file" class="com.....FileTypeEditor"

 

剩下的就是加载扩展点，根据type查找对应的Editor实现。这个实现方式明显比之前要好很多：

 

首先：代码结构明显清晰很多

再次：可以自由的增加和减少实现类型而不用修改代码

最后：可以自由修改匹配类型而不用修改代码

 

例子二：

 

写一个简单的代码统计工具，用来统计当前选择文件或文件夹里的代码行数。现在语言和脚本类型这么多，不可能通过一个长长的判断语句来把所有的统计类型都考滤进去，何况还有各种新语言层出不穷；例如properties文件就认为"#"是注释、bat文件里rem是一个注释、java里有/** */等等。

 

所以一个良好的实现就是提供一个统计类的扩展点用来提供各种对应类型的统计方式。

 

例如：

   <extension
         point="com.tibco.cdc.liugang.codecount.countDelegate">
      <delegate
            class="com.tibco.cdc.liugang.codecount.count.CountJavaFile"
            fileExtensions="java">
      </delegate>
      <delegate
            class="com.tibco.cdc.liugang.codecount.count.CountPropertiesFile"
            fileExtensions="properties">
      </delegate>
   </extension>

 

在自定义扩展点时，有一点很重要：提供一个良好的继承类或接口。

 

很难考滤的一点给用户足够的信息。有时无法预测用户究竟需要哪些信息。

 

例如我做一个SCA BPEL组件时，要从XPDL文件生成一个直接可部署的包里。因为那些Activity可能有各种各样的类型，每个类型都可能有一个单独的实现，所以我需要提供一个扩展点用以给各种实现类型一个自己在扩展来给出他们的信息以实现打包工能，最大的问题就是：无法预测有什么样类型的实现会给出，这些实现类型需要什么样的信息来实现他们的打包逻辑。所以大至只能想了！