22《框架通讯契约接口》.doc

22《框架通讯契约——接口》.txt第一次笑是因为遇见你，第一次哭是因为你不在，第一次笑着流泪是因为不能拥有你。插件式框架的宿主程序启动以后，它首先会遍历插件文件夹中所有的插件程序集，这些程序集文件以dll格式存在，框架宿主程序将遍历程序集中包含的插件类型，然后由插件引擎负责依据类型分别生成ICommand、ITool、IToolBar、IMenu和IDockableWindow等对象，这些对象将放在一个插件对象池中传递给宿主程序进行进一步解析和处理。 一个插件程序集中可以包含多个插件类型（即多个Class或Struct代码文件可以编译在一个Assembly文件中），框架宿主程序如何识别这些类型的对象是否为插件对象呢？这是由于每个插件对象都有一个身份标识──接口，这个标识在框架设计中被称为“通讯契约”──由于接口也可以被看作是一种类型并定义了必要的方法和属性，宿主程序就可以通过这种契约来生成具体的UI对象并对外界操作作出事件反应。宿主程序必须声明自己有什么样的功能可被插件调用，且插件必须符合什么条件才能被宿主程序使用；反之，插件也需要知道宿主程序提供了什么样的功能和属性，才能将自己融入宿主程序的结构中。 插件式框架作为一个高聚合低耦合的系统，它的功能定义与功能实现之间是分离的，这种策略是高聚合实现的保证。插件式框架好像一个功能聚集站，它对外界宣布，只要符合它发布的插件规范的组件（实现接口的类通常称为组件）都可以加入到这个平台中，而这些组件的具体功能，它并不关心，当然，框架也提供了一些必要的信息和帮助保证这些组件能够正常实现它们的功能。 通讯契约可以以接口或抽象类的形式出现，但一般都是采用接口。这是典型的桥接（Bridge）模式。桥接模式是一种被认可的表示定义和与之关联的实现的方式，它和工厂（Factory）模式为所有的应用提供了基础。使用桥接模式开发的组件具有为了一个共同目标而多方协同工作除某些必须实现的接口外无需彼此交互的优点。[1] 在具有多个逻辑层的结构设计中，各层之间的通讯大多通过接口实现，由于接口不会轻易改变，如果一个层的功能发生变化，不会影响其它层；只要实现了接口的组件功能正常，那么程序的运行就没有问题。这种做法使得各层之间的相互影响降低到最低程度。 2.2.1. 接口的秘密 在大部分编程和设计工作中，很少遇到需要考虑“接口（Interface）”这个术语的情况，如果我们仅仅满足通过拖曳控件的方式在IDE上编程和使用.NET Framework中一般的类库，可能永远也不会在程序中使用到接口，即使在C#等面向对象语言的语法书中读者会无数次看到过这个名词。 接口作为类型而存在 接口是类型（Class）一般行为的定义和契约。如所有的交通工具都包含启动、停车、加速和刹车等方法，交通工具类（VehicleClass）可以将这些一般的、公共的方法都定义在一个接口中，而不同类型车辆之间的这些操作可能并不一样，但接口并不考虑它们各自采用什么方式实现自己的这些功能或方式之间的差异，它只关心这些类型都必须实现接口定义的所有功能，而实现了这个接口的类型都可以看作是一种交通工具。 因此，接口的两个主要作用是： l 定义多个类型都需要的公共方法和属性； l 作为一种不可实例化的类型存在； 实现了接口的类或结构必须实现接口中定义的每一个属性和方法，这些方法在设计或功能上往往是相关的，这是最典型的接口设计策略。 接口与抽象类 接口与抽象类非常类似，例如两者都不能产生实例对象，但都可以作为一种契约和定义被使用。但接口和抽象类有本质的不同，这些不同包括： l 接口没有任何实现部分，但抽象类可以包含部分实现代码； l 接口没有字段，但抽象类可以包含字段； l 接口可以被结构（struct）继承，但抽象类不行； l 抽象类有构造函数和析构函数； l 接口仅仅能继承自接口，而抽象类可以继承自其它类和接口； l 接口支持多继承而抽象类仅仅支持单根继承。 下面是接口和抽象类的一个对比例子： 接口IIterface： public interface IInterface { void MethodA (int a); void MethodB (int a); void MethodC (int a); void MethodD (int a); } 抽象类AClass： public abstract class AClass { abstract publ