改进的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. iconnectableobjectpublic 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. 证明 须要证明的是，正文只是引见了我的一点小小的办法。有不对理的因素，请大师提出矫正的看法（径直发邮件给我，或写恢复）。在这边载入源代码：