1、Eclipse 法则(Eclipse Rule)

 

扩展者( Extender) ――添加插件

       贡献法则（ Contribution Rule ）：一切皆是贡献。

       遵循法则（ Conformance Rule ）：插件必须遵循预期的接口。

       共享法则（ Sharing Rule ）：增加，不要取代。

       有样学样法则（ Monkey See/Monkey Do Rule ）：遇到问题时，首先复制类似插件的结构。

       相关性法则（ Relevance Rule ）：只有在操作有可能成功时菜显示你所贡献的操作。

       整合法则（ Integration Rule ）：要整合，不要分裂。

       责任法则（ Responsibility Rule ）：明确指出你所开发的插件时问题的源头。

       针对 API 契约编程法则（ Program to API Contract Rule ）：首先检查 Eclipse API 契约，然后针对契约编程。

       Other 法则（ Other Rule ）：让用户可以选择所有东西，但把那些通常不用于当前视角的选项放在 Other… 对话框中。

       IResource 适配法则（ Adapt to IResource Rule ）：应该尽量为领域对象定义 IResource 适配器。

       分层法则（ Strata Rule ）：将语言无关的功能与特定于具体语言的功能分开，将核心性能与 UI 分开。

       用户连贯性法则（ User Continuity Rule ）：在多次会话之间，应该保持 UI 状态一致。

 

促成者( Enabler  ) ――发布扩展点

       邀请法则（ Invitation Rule ）：尽可能的邀请别人为你的作品作出贡献，发布扩展点。

       懒加载法则（ Lazy Loading Rule ）：只有在真正需要的时候才加载插件。

       安全平台法则（ Safe Platform Rule ）：作为扩展点的提供者，你必须保护好自己，不要让扩展者的误操作给你造成损失。

       公平竞争法则（ Fair Play Rule ）：所有使用者遵守同样的游戏规则，包括我自己。

       明确扩展法则（ Explicit Extension Rule ）：明确说明平台的什么地方可供扩展。

       发散性法则（ Diversity Rule ）：一个扩展点接纳多个扩展。

       良好防御法则（ Good Fences Rule ）：如果要交出程序的控制权，首先保护好你自己。

       用户决定法则（ User Arbitration Rule ）：如果有多个选择，由用户决定使用哪一个。

       明确 API 法则（ Explicit API Rule ）：将 API 与插件内部使用的类分开。

       稳定性法则（ Stability Rule ）：如果你已经开始邀请其它人作出贡献，就不要再改变游戏规则。

       保守 API 法则（ Defensive API Rule ）：只暴露你有信心的 API ，但同时也应该做好准备暴露更多的 API ，因为使用者会要求你这样做。（不含 internal 的包被认为是公开的、允许后续的扩展者使用的；不含 internal 的包，则不是打算拿到插件外使用的。）

 

发布者( Publisher) ――发布插件

       许可法则（ License Rule ）：每项贡献品都应该提供许可证。

2、Eclipse 插件(Plug-in)

何时需要一个插件类

 

       每个插件都由一个插件类来代表。插件类是一个Singleton，其中提供了一些钩子方法，可以对插件的什么周期事件作出响应。可以在插件第一次加载时读入所需的资源，也可以在插件停止时做必要的清理工资。另外，插件还负责提高一些共享信息。

 

投影（Shadow）的世界

 

       Eclipse平台启动时会将所有插件清单文件读入一个插件注册表中，为每个插件创建一个投影。此时不会加载插件本身，只加载它们的描述信息。（Platform.getPluginRegistry()）

 

开发插件时，不要在项目属性中修改构建classpath，始终在清单文件中修改。

 

在Eclipse中，每个插件都有自己的类加载器（class loader）和自己的类查找路径（classpath），后者将继承该插件所导入的其它插件的classpath。当插件的类加载器加载插件的第一个类时，就会激活该插件。

 

插件类加载器

 

1、  插件类加载器的上级加载器，Eclipse的引导加载器，boot.jar

2、  插件本身的类加载器，plugin.xml清单文件中的<run-time>元素中描述的类。

3、  相依插件的类加载器，如果插件依赖于其它插件，在类查找时，会在内部使用一个URL类加载器。

4、  不包括应用程序类/系统CLASSPATH变量的加载器。

 

加载扩展的全过程

 

1、  从Eclipse平台取得扩展点。

2、  取得以在此扩展点上注册的扩展（实现IExtension接口）。

3、  对于每个扩展，取出其中以XML方式声明的配置元素（实现IConfigurationElement接口）。

4、  对于每个配置元素，根据该元素XML声明中class属性的值创建一个对象，确保定义的属性完整、有效。

5、  将新创建的扩展对象保存到一个集合中，而不是直接返回一个扩展对象。

 

理想的开发策略：

1、  信心：在增加新性能或修改旧结构时，不比担心对原代码造成破坏。

2、  学习：快速而自信地学习Eclipse地新领域。

3、  设计：鼓励自己和同事认真考虑设计，尤其是代码地外在接口，然后去考虑如何实现。

 

测试驱动开发（Test-Driven Development, TDD）的开发循环：

1、  编写欲添加功能的测试。

2、  针对这个测试引用到、暂未存在的类和方法，创建一段空的占用程序，使测试通过编译。

3、  实现测试，测试测试应该失败。

4、  尽量对实现代码加以清扫，例如去除其中的重复代码。

 

插件的测试策略

 

       从审美的角度，每个插件应该尽可能少的依赖其它插件；从实用的角度，以测试驱动的方式开发插件的每个部分。应该首先创建测试插件，让它依赖于新插件，以便完全用测试来驱动新插件的开发。

 

工作副本（working copy）是Eclipse JDT引入的一个概念，是原有的编译单元在内存中的复制品。让用户修改时，操作的实际是Java编辑器所创建的工作副本；当用户保存编译单元时，Java编辑器才把副本提交到文件系统，此时对编译单元的修改才会以Java元素变化增量的形式广播出去。（JavaUI.getWorkingCopyManager()）

 

视角，定义了（一组）视图和编辑器的排列方式，工作台页面的布局，解决某个完整问题的环境。

 

降低插件的维护成本：良好的异常处理和错误报告机制；提供联机帮助文档（Eclipse的help扩展点的扩展）。

 

分段（fragment）使开发者能够向现有的插件中添加代码和资源。（fragment.xml）

分段的用途：

1、  为插件提供额外的字符串翻译（语言包）。

2、  为现有组件提供特定于平台的内容。