改进的C#插件构架（转帖）

不过这种技术接口的制订是个难题，设计不好很影响以后的功能扩展 —— fking      比较简单的插件想法，扩展的功能是有限的。 应该考虑主程序本身也应该是一个插件的结构。也就是说插件分为宿主插件和扩展插件两类。这两类也可以在一起。这样的话才可能有好的扩展性。象eclipse的扩展和扩展点的思想，和sharpdevelop的插件树的思想比较好解决了扩展性的问题。 —— jan

     以上是两位网友对笔者《C#插件构架实战》一文作出的评价。首先对两位热心的读者表示感谢。

     的确如此，在软件开发的过程中，设计的过程往往比写代码的过程要难得多。因此，通常除了软件测试之外，耗时最多的也就是系统建模了。一个好的软件系统应当具有较高的稳定性（可靠性）、易操作性以及可扩展性支持，尤其是可扩展性。我认为，良好的可扩展性支持是一个软件团队在开发中变被动为主动的必要条件。对于一个应用，我们希望在用户增加需求时，我们能够用最少的时间、最少的人力来解决问题。当别人在用户快速增长的需求中忙得不可开交时（用户总是不能在第一次需求分析时将需求完完整整的告诉你 ^_^），而你，你的团队只需要作一点工作就可以让“贪得无厌”（-_-）的用户得到满足，从而提高了效率，让团队有更多的的时间来创造，而不是去做无谓的修改。

     很遗憾的是，在《C#插件构架实战》一文中，我并未考虑到这一点。当然，对于一个十八岁的没有也不可能有团队工作经验的年轻人来说，这样的失误（失误就是失败——老师如是说）是可以原谅的（自我开脱之辞）。不过，我决定对这个插件系统进行重构。

     考虑到系统的复杂性，这次我准备使用UML（大上个月才开始学的，画得不好，见笑了）。

     1. 着手分析

     对于网友 jan 的指教，我大概明了，但人的思维差别太大，我不敢保证我的理解是完全符合 jan 的意思的。但是，我仍然会根据自己对可扩展性的理解构建一个应用程序框架模型。

     直入正题。我现在假设我属于一个软件团队（就暂且叫她 AbstractSoft 吧），并任系统分析师（^o^）。任何事物都有它规范的一面，我们希望我们的团队出品的部署在同一平台的所有应用都有相同的框架，相同的部署形式。这样便可以形成独有的团队特色，并在竞争中以效率取胜。因为我们不需要为每一套应用设计不同的框架——这可以节约不少时间！

     这样我需要把程序实现与用户界面分开到不同的框架中。我的意思是：

     如此一来，在 Application Frame Level 的核心库中存在的是抽象接口以及一些泛化的细节。这些内容在第一次安装团队产品时就已经部署在用户的机器上了。它不会自动销毁，直到用户提交把它从本地移除的请求。GUI Level 提供了团队产品泛化后的统一的界面组件（比如：属性编辑器、数据库操作界面等可重用组件）。特化的产品（Speciallized Application）通过实现 Application Frame Level 中的某些接口实现可扩展性，通过使用 GUI Level 中的的类来实现用户界面。

     以下是一个简单的静态图(接口和类的成员将在下面详细阐述)：

     2. IConnectableObject

public interface IConnectable {      // application 为插件所属的主框架对象。若为null则表示插件本身就是主框架      ConnectionResult Connect( object application );      ExtendibleVersionInfo VersionInfo { get; }        void OnDestory();      void OnLoad();      void Run(); }   public enum ConnectionResult {      Connection_Success ,      Connection_Failed }   public class ExtendibleVersionInfo {      private ExtendibleVersionInfo() {}      public ExtendibleVersionInfo( string name , string version , string copyright ) { // Omitted }      public ExtendibleVersionInfo(string name,int version1,int version2,int version3,string copyright) { // Omitted }        public int PrimaryVersion { get { return _Version1; } }      public int SecondaryVersion { get { return _Version2; } }      public int BuildVersion { get { return _Version3; } }      public string Name { get { return _Name; } }      public string VersionString { get { // Omitted } }      public string Copyright { get { return _Copyright; } }        private string _Name;      private int _Version1 = 1;      private int _Version2 = 0;      private int _Version3 = 0;      private string _Copyright;        public static ExtendibleVersionInfo Empty = new ExtendibleVersionInfo(); }

     所有可连接的对象必须实现这个接口。这是所有 Application Frame Level 中类的鼻祖。

     3. IExtendible

public interface IExtendible {      IConnectable GetLatestVersion();      IConnectable QuerySpecifiedVersion( ExtendibleVersionInfo version );      ExtendibleVersionInfo[] EnumerateVersions(); }

     4. 使用类工厂创建应用程序和插件的最新版本

     我们的主程序以及插件会设计成 internal class 。程序只输出一个工厂类，用户界面通过调用 IExtendible 接口的 GetLatestVersion() 方法获得这些用来完成实际任务的对象的实例,并把它们显示出来。或者，也可以枚举所有的版本，让用户来挑选所需要版本。

     5. 可扩展性

     不得不承认，这样的方式可扩展性仍不是很强。程序需要升级时同时需要修改提供给用户的工厂类（虽然接口不变）。为了实现更好的可扩展性，可以把简单工厂模式转换为工厂方法模式。

     6. 声明

     需要说明的是，本文仅仅介绍了我的一点小小的想法。有不合理的成分，请大家提出改进的意见（直接发邮件给我，或写回复）。在这里下载源代码：