Eclipse插件结构设计思考

在进行插件开发，构建软件产品的过程中，往往涉及到很多个插件。这些插件应该如何设计？我基于自己的经验提供以下插件结构的想法：

对于整个产品，可以将产品划分为四大模块：业务无关核心层、业务相关核心层、可插拔业务层、功能与产品定制。其中业务无关核心层和业务相关核心层，共同组成了系统核心层。
系统核心层，我认为需要遵循以下原则：

1. 每一个大版本，可增加，但不应删除核心层之中的API，以保证核心层稳定性。(思路来自于Java的向后兼容，在不进行大幅修改核心层的情况下，可以最大程度保证高版本对低版本的兼容，易于维护)
2. 核心层应尽可能短小、稳定，开发过程中，API开放应尽可能小，防止影响产品后续维护。所以应尽可能将模块剥离核心层。（思路来自于Eclipse，小核心，高可用，扩展性好，插件开发的优势）
3. 软件系统应允许系统核心层、以及功能产品定制的最小配置情况下，能够稳定运行。（思路来自于对产品分级，商业软件的VIP与非VIP的差别）
4. 应提供详细扩展API以及说明。并且本系统内的可插拔模块应严格基于此API进行扩展，从而也是为第三方扩展提供示例，保证所有扩展基于同一种模式。（思路来自于插件开发中的扩展点、扩展等）。

业务无关层、业务相关核心层、可插拔业务层、功能与产品定制，遵循的原则，可以参考具体模块说明。

提供了插件命名规范，这个规范可以事先约定，从而能够更好的进行团队沟通、协作。通过规范化的插件命名，也方便调试时候，定位问题，同时能够更加方便的解耦合。
下面插件相关说明中：

1. XXX指代公司以及本项目的前缀。例如，com.formaltech.smave.ics，这是我公司与项目的前缀。com.formaltech是公司，smave.ics则是项目前缀。用户可以使用自己的公司或前缀替代。
2. YYY指代某一个功能模块。
3. ZZZ用于指代为了实现某一个功能模块的一个项目。
4. nl_zh用于表示国际化片段。nl指代国际化，zh指代中文。

业务无关层

业务无关层，主要用于提供处理与当前软件业务无关的相关工具。划分为三大部分：仅与Java API有关，与Eclipse平台API有关，与第三方项目有关。 这两个部分，内部又分为UI和非UI部分。

遵循以下原则：

1. 按照业务无关的功能划分，将公共的代码进行分类。
2. 任何基于插件开发的产品，应能够直接复用这些项目，而无需复制代码。（根据代码设计原则，代码应尽可能的复用，最理想情况下，某一段功能代码，在整个程序中应只存在一份）
3. 插件依赖，应尽可能的可选。这是因为某一个UI或非UI插件中，可能同时引用多个插件项目，但是部分工具类代码实际并不引用这些项目，其他项目使用这些工具类并不需要依赖某些可选的插件。
4. 最好存在代码库，维护这些代码。（思路来自于迭代式开发，代码库本身就是公司的实力，也为公司开发出新产品节约时间。同时，这些通用的代码，也更容易在产品开发过程中，不断完善，解决隐藏的bug，从而更加稳定。还有，比较方便于设计大量测试用例，用于测试这些通用的项目。）

XXX.lang插件

该插件应仅依赖于Java API，例如提供StringUtils工具类，反射工具类、数据结构等等，原则上应只有一个。下图是一个示例：

我们收集网络上开源的项目的代码（注意符合相关许可证规范），并基于这些开源代码，维护公司产品自己的版本，从而能够更加可靠的保证产品更新时的稳定性。
可以看到，在插件依赖时候，对应的两个依赖插件，均是可选的，这是因为该插件仅依赖于Java API，无需强制要求一定依赖某个插件项目。

XXX.core插件

该插件应只能依赖于Java API，XXX.lang插件，以及Eclipse平台非UI的API，原则上应只有一个。主要功能是，提供Eclipse平台相关的非UI公共工具或抽象类、接口等。例如项目nature，IFile等资源文件、EMF的EObject模型相关工具等。

XXX.thirdparty.YYY插件

第三方某个功能的插件，可以有多个，按实现的功能划分。应只能依赖于Java API，Eclipse 非UI的API,指定的第三方开源项目，XXX.lang项目，XXX.core项目。例如POI用于对Word，Excel等进行处理的第三方开源项目，可以在该项目下提供lib包或者直接引用源码结构，继而进行处理。

在整个软件中，所有第三方项目应只能通过这插件进行访问，应尽量少的开放第三方开源项目中的API。

XXX.lang.ui插件

主要是用于提供非Eclipse的UI工具，例如Java AWT,Java Swing，以及Java API中处理图标等类。应只能依赖于Java API， XXX.lang项目。

XXX.core.ui插件

主要是用于提供Eclipse的UI工具，例如SWT,JFace,GEF等等。应只能依赖于Java API，Eclipse API，XXX.lang插件，XXX.core插件，

XXX.lang.ui插件。

主要是用于提供非Eclipse的UI工具，例如Java AWT,Java Swing，以及Java API中处理图标等类。应只能依赖于Java API， XXX.lang项目。

XXX.thirdparty.ui.YYY插件

用于为第三方开源项目，提供UI配置等，该插件是可选的，如果不需要配置则不需要此插件。应只能依赖于Java API，Eclipse API，XXX.lang插件，XXX.core插件，XXX.lang.ui插件，XXX.core.ui插件，相同功能模块YYY的插件XXX.thirdparty.YYY。

业务相关核心层

业务相关核心层，主要是为该软件系统提供最小可运行部分。主要应遵循以下原则：

1. 在XXX.business.core和XXX.business.core.ui提供多处插件的公共代码。如果仅有一个插件使用，则尽量不要放入这两个插件之中。
2. 某一个模块虽然可以引用其他模块，应尽量少的耦合在一起，或者存在调用与调用关系，不要有互相调用的情况。
3. 在进行需求和设计的时候，应首先分析出哪些属于核心层，哪些不是；可以划分为哪些独立的功能模块。

XXX.business.core插件

业务核心插件，用于提供基于业务的核心包。 例如开发工具（或者分析工具），名称唯一性校验，语法分析，字符串与对象对应关系，变量类型和值分析等等，这些与UI无关的公共部分，应放置在此包之中。

该插件包，建议唯一一个。仅能依赖于Java API，Eclipse 非UI的API，以及业务无关层的非UI插件。

如果允许核心层扩展非UI的扩展点，则应在此项目的schema文件夹之中定义。

XXX.business.core.ui插件

业务核心UI插件，用于提供基于业务的核心UI包。例如开发工具（或者分析工具），多个插件均使用到的类型声明、初始值赋值，变量选择等对话框，以及一些标签提供者，内容提供者，在多个插件调用时，且比较通用时，可以放入此插件内。

该插件仅依赖于Java API，Eclipse API，以及业务无关层的所有插件和XXX.business.core插件。

在此插件中，可以提供核心系统需要使用到的各种资源文件，例如图标，国际化，字体、颜色等等，从而可以统一管理这些资源。

如果允许核心层扩展UI的扩展点，则应在此项目的schema文件夹中定义。

XXX.business.YYY.ZZZ插件

业务核心中某个模块的非UI项目。业务核心也可以划分为多个不同的模块，可以有多个这种插件。

该插件应仅依赖于Java API，Eclipse API，业务无关层的非UI插件，XXX.business.core插件，以及其他的XXX.business.YYY.ZZZ插件。

**注意：**业务相关核心层，是允许依赖其他核心层的非UI插件的，但应提供清晰的上下依赖关系图，并尽量减少这种依赖。最理想情况下，是模块与其他模块没有依赖关系。

XXX.business.YYY.ui.ZZZ插件

业务核心中某个模块的UI项目。实现UI与非UI的分离，是为了更好的维护程序，而且通过这种方式，允许脱离UI项目，完全由程序控制自行运行。

该插件应仅依赖于Java API，Eclipse API，业务无关层的非UI插件，XXX.business.core插件，以及本身和其他的XXX.business.YYY.ZZZ， 其他的XXX.business.YYY.ui.ZZZ插件。

**注意：**同样的，应提供清晰的上下依赖关系图，并尽量减少这种依赖。最理想情况下，是模块与其他模块没有依赖关系。

可插拔业务层

可插拔业务层，是指将该模块业务剥离后，系统仍然能够独立运行，只是功能少一些而已。该层真正体现了插件开发的精髓，同时有以下要求：

1. 可插拔业务层的一个模块，仅能依赖于核心系统的相关插件，以及Java API和Eclipse API。
2. 同样的可插拔业务层，也划分为两个部分。这两个部分可以在同一个插件项目之中，由于支持第三方扩展，所以并不强求严格区分UI和非UI。
3. 可插拔业务层的插件，应通过业务相关核心层中对应插件之中的一些扩展点进行扩展。缺少后，不得影响其他可插拔业务的插件项目。

XXX.module.YYY.ZZZ插件

某个可插拔业务的非UI插件，只可以依赖于系统核心以及Java API，Eclipse API。如果划分了UI和非UI，则应只能依赖非UI部分的API。

同一个可插拔模块，可以包含多个子插件，不做限制。

XXX.module.YYY.ui.ZZZ插件

某个可插拔业务的UI插件，只可以依赖于系统核心以及Java API，Eclipse API。如果可插拔业务不区分UI和非UI，则无需此插件，并且对应的XXX.module.YYY.ZZZ插件可以依赖UI部分的API。

同一个可插拔模块，可以包含多个UI子插件，不做限制。

功能与产品定制

当基于Eclipse插件开发的软件，相关项目完成后，可以按照功能，对产品进行客户化定制。下面的部分，介绍了产品定制的各个方面。

功能与产品定制，则依赖于上述所有插件，但是不应提供除了产品使用过程中的相关业务执行细节。

应遵循以下原则：

1. 功能产品，应能够支持对应的产品的打包；启动信息等的配置；国际化；欢迎界面（新手向导）等等。
2. 功能产品，应提供基于maven或其他构建过程，方便打包和部署。
3. 功能产品，应支持国际化。作为中文编程者，应至少提供中文、英文两种语言支持。

XXX.module.YYY.ZZZ.feature功能

用于包含某个可插拔模块的功能。一般一个可插拔业务层，对应于一个feature项目。

XXX.business.feature功能

用于包含所有核心运行需要的功能或插件。必须使得产品仅包含此功能后，程序能够正常运行。

包含Eclipse相关的功能和插件、片段。以及系统核心的所有插件。

XXX.product产品

可以在项目中，定义多个product文件，用于组合XXX.business.feature功能，以及指定多个的XXX.module.YYY.ZZZ.feature功能。

建议，应至少提供两种产品。第一种仅包含系统核心；第二种除了系统核心外，包含所有可插拔业务层。公司可以根据自己的营销方案，按照可插拔业务层的提供情况，划分出多种产品级别。

XXX.maven插件

用maven插件项目，主要是为了可以为多个协作程序员，提供统一的编译打包环境。同时公司可以提供自己的数据中心，从而允许软件的用户直接从公司网站上下载或者更新部署插件。为产品的发布提供方便。

XXX.business.YYY.ZZZ.nl_zh片段

主要用于为某一个插件项目，提供国际化支持，应作为片段项目。作为中文编程者，应至少支持中文、英文两种语言。

XXX.example.YYY插件

作为一个软件而言，应提供使用该软件的详细示例，或者提供测试用例，并说明如何使用。该项目用于配合软件教程，帮助软件使用者快速熟悉软件。

今天的文章Eclipse插件结构设计思考分享到此就结束了，感谢您的阅读。