基于C的插件框架设计和实现.docxVIP

一、引言????1. 问题的引入????假设你设计的程序已经部署到用户的计算机上，并且能够正常运行了。但是有一天，用户打来了电话——他们要求增加新的功能。确定了用户的需求 后，你竟然发现原有的软件架构已经无法胜任新增任务的需求——你需要重新设计这个应用了！但问题是，就算你又用了一个开发周期完成了用户需要的应用，却不 能保证用户的需求不会再次变更。也就是说，需求蔓延的可能性依然存在。因此，这种情况下插件构架更能显示出它的优越性。????2. 几个解决方案的对比????我总结了一下我所接触到的插件构架，大致上可分为以下几类： i> 脚本式????使用某种语言把插件的程序逻辑写成脚本代码。而这种语言可以是 Python ，或是其他现存的已经经过用户长时间考验的脚本语言。甚至，你可以自行设计一种脚本语言来配合你程序的特殊需要。当然，用当今最流行的 XML 是再合适不过了。????这种形式的特点在于，稍有点编程知识的用户就可以自行修改你的脚本（ ^_^ 假如你不加密它的话）。我们无法论证这是好处还是坏处。因为，这种情况所造成的后果是不可预知的。 ii> 动态函数库 DLL????插件功能以动态库函数的形式存在。主程序通过某种渠道（插件编写者或某些工具）获得插件 DLL 中的函数签名，然后在合适的地方调用它们。用过 Matlab 的读者都知道， Matlab 中的各项功能几乎都是些动态链入的函数。 iii> 聚合式????顾名思义，就是把插件功能直接写成 EXE 。主程序除了完成自己的职责外，还负责调度这些“插件”。我不喜欢这种形式。这使插件与插件之间，主程序与插件之间（主要是这一点）的信息交流困难了许多。巴比伦塔的失败 [1] 从某种程度上讲就是信息交流无法实现造成的。 iv> COM 组件????COM [2] 的产生给这个世界增添了几分活力。只有接口！我们的插件需要做的只是实现程序定义的接口。主程序不需要知道插件怎样实现预定的功能，它只需要通过接口访问插件，并提供主程序相关对象的接口。这样一来，主程序与各插件之间的信息交流就变得异常简单。并且，插件对于主程序来说是完全透明的。 ????3. 决策????C# 是面向对象的程序设计语言。它提供了 interface 关键字来直接定义接口。同时， System.Reflection 命名空间也提供了访问外部程序集的一系列相关对象。这就为我们在 C# 中实现插件构架打下了坚实的基础。 ????下面，我们将以一个具有插件构架的程序编辑器为例，来阐述这种构架在 C# 中的实现。 二、设计过程????好了，现在我们准备把所有的核心代码都放在 CSPluginKernel 命名空间中。用VSIDE建立一个C#类库工程。在命名空间 CSPluginKernel 中开始我们的代码。????1. 接口设计????我们的程序编辑器会向插件开放正在编辑的文档对象。程序启动后，就枚举每一个插件并把它连接到主程序，同时传递主程序对象的接口。插件可以通过这个接口来请求主程序对象或访问主程序功能 。 ????根据上面的需求，我们首先需要一个主程序接口： public interface IApplicationObject { ???? void Alert( string msg ); // 产生一条信息 ???? void ShowInStatusBar( string msg ); // 将指定的信息显示在状态栏 ???? IDocumentObjectQueryCurrentDocument(); // 获取当前使用的文档对象 ???? IDocumentObject[] QueryDocuments(); // 获取所有的文档对象 ???? // 设置事件处理器 ???? void SetDelegate( Delegates whichOne , EventHandlertarger ); } // 目前只需要这一个事件 public enumDelegates { ???? Delegate_ActiveDocumentChanged , } ????然后是 IDocumentObject 接口。插件通过这个接口访问编辑器对象。 /// /// 编辑器对象必须实现这个接口 /// public interface IDocumentObject { ???? // 这些属性是 RichTextBox 控件的相应的属性映射 ???? string SelectionText { get ; set ; } ???? Color SelectionColor { get ; set ; } ???? Font SelectionFont { get ; set ; } ???? intSelectionS