|
|
|
|
Eclipse 插件开发法则 |
|
|
|
作者：未知 来源：月光软件站 加入时间：2005-2-28 月光软件站 |
扩展者
贡献法则( Contribution Rule )：一切皆是贡献。
遵循法则( Conformance Rule)：插件必须遵循预期的接口。
共享法则( Sharing Rule)：增加，不要取代。
有样学样法则( Monkey see/Monkey Do Rule)：遇到问题时，首先复制类似插件的结构。
相关性法则( Relevance Rule)：只有在操作有可能成功时才显示你所贡献的操作。
整合法则( Intergration Rule)：要整合，不要分裂。
责任法则( Responsibility Rule)：明确指出你开发的插件是问题的源头。
针对API契约编程法则( Program To API Contract Rule)：首先检查 Eclipse API 契约，然后
针对契约编程。
“其他”法则( Other Rule)：让用户选择所有东西，但把那些通常不用于当前世界的选项方在
Other 对话框中。
IResource 适配法则( Adapt To IResource Rule)：应该尽量为领域对象定义 IResource 适
配器。
分层法则( Strata Rule)：将语言无关的功能与特定于具体语言的功能分开，将核心功能与 UI
功能分开。
使用连贯性法则( User Continuity Rule)：在多次会话之间，应该保持用户界面状态一致。
促成者
邀请法则( Invitation Rule)：尽可能的邀请别人为你的作品作出贡献。
懒加载法则( Lazy Loading Rule)：只有在真正需要的时候才加载插件。
安全平台法则( Safe Platform Rule)：作为扩展点的提供者，你必须保护好自己，不要让扩展
者的误操作给你造成损失。
公平竞赛法则( Fair Play Rule)：所有使用者遵守同样的游戏规则，包括我自己。
明确扩展法则( Explicit Extension Rule)：明确说明瓶盖的什么地方可供扩展。
发散性法则( Diversity Rule)：一个扩展点接纳多个扩展。
良好防御法则( Good Fences Rule)：如果要交出程序的控制权，首先保护好你自己。
用户决定法则( User Arbitration Rule)：如果有多个选择，由用户决定使用哪一个。
明确 API 法则( Explicit Rule)：将 API 与插件内部使用的类分开。
稳定性法则( Stability Rule)：如果你已经开始邀请其他人作出贡献，就不要再改变游戏规则。
保守 API 法则( Defensive API Rule)：只暴露你有信心的 API ，但同时也应该做好准备暴露
更多的 API，因为使用者会要求你这样做
发布者
许可法则( License Rule )：每项贡献品都应该提供许可证。
|
|
相关文章：相关软件： |
|
本类阅读TOP10