《在什么情况下创建扩展点》

   在定义扩展点之前，你可以试着问一下自己如下两个问题：
        1、从需求角度考虑，要这种需求存在吗？
        2、从技术视角思考，你要用扩展点描述的东西是不是属于模块内部的实现？
        3、从技术视角思考，即使需要扩展，真的需要动态挂入吗？java默认的静态注入不可以？
        4、从技术视角思考，你处的模块是不是一个上层功能模块？
   
        关于第一点，就去看一下需求文档，对应的功能点需求描述如何。这个时候从客户的角度看，客户会针对你的模块进行二次开放吗，如果开发，需要注册扩展到你的模块吗？

        关于第二点，如果你要用扩展点描述的东西不是对模块外部可见的，是属于你模块里面的内部实现，扩展点肯定用不上。

        关于第三点，是很多新人非常容易犯的错误，将语言特性和平台机制混在了一起。举个例子，假设你定义了一个策略接口IPolicy，有个对应的manager类型的角色在管理IPolicy实例，现有实现PolicyA、PolicyB，

public class PolicyManager { private static PolicyManager manager; private List<IPolicy> policyList = new ArrayList<IPolicy>(5); /** * sinleton */ private PolicyManager() { policyList.add(new PolicyA()); policyList.add(new PolicyB()); } public static PolicyManager getInstance() { if (manager == null) manager = new PolicyManager(); return manager; } public static IPolicy[] getPolicys() { //TODO: } }  

而且你感觉以后还会有有PolicyC加入。那就加入好了，加入的时候望你的manager里面用代码注册一下就可以了。那可能会问，这样不是修改代码了吗，如果用扩展点，那么不就不用修改manager的代码了？  要记住，扩展点是平台机制，比语言特性高一个level。在这种场景下，除非你确实需要外部参与提供新的IPolicy实现（利用扩展点动态挂入），否则就老实用java语言支持的吧。

        关于第四点，看一下Eclipse自身提供的扩展点就知道了。Eclipse中大部分扩展点基本上都是在两中类型模块中提供的：一是基础模块，例如runtime、resource management、workbench；二是可能需要二次定制开发的模块，例如JDT，因为很多场景下用户会基于JDT进行扩展开发，往JDT中提供自己的扩展。  如果你的模块是一个上层的功能模块，而且也可以肯定不会有其他模块会依赖于它，那么怎么可能会存在扩展点呢？？？如果你现在做的是一个IDE，创建了自己的工程类型，那么现有的文件类型就有可能会扩展。你现在在设计一个project builder，正常的设计逻辑当然是针对不同文件类型去调用对应的编译器，那这种编译器就需要动态挂入了。例如你的针对文件的编译器接口是IModelCompiler，那你就创建一个compiler扩展点，你现有的compiler实现也是以扩展点的方式动态挂入，公平法则啊。

 

摘自：http://www.pin5i.com/showtopic-20484.html