从C++向COM演进

 

 

我们要解决的问题是复用问题，我们的目标：

（1）       当被复用的软件升级时，客户程序不需要重新编译。

（2）       被复用的软件应该容易扩展和升级。

（3）       在客户能正常使用复用组件功能的基础上，组件向客户暴露尽可能少的信息。

（4）       尽可能是客户使用组件更加方便，将许多繁琐复杂的工作从客户端转移到组件内部。＝＝》所有可以在组件内部完成的事情，决不在组件外部完成。

 

COM的核心在于：接口。它解决了复用时两个主要的问题：

（1）       不同的编译器对具体技术的不同实现问题和名字改编问题。首先，客户程序源代码中仅仅需要引入接口定义，而不同的编译器对同一接口的VTBL的结构安排是一样的，所有的组件功能的调用都通过同样的VTBL来中转。其次，由于用户通过接口来调用组件的功能，而不需要其它导出函数，所以没有名字改编的问题了。

（2）       组件仅仅导出接口，而不是导出类，避免了因组件中的类的大小发生变化而客户程序不重新编译而继续运行时产生运行错误的问题。

 

 

 

从C++开始演进：

1．C++程序有两种复用方式：

（1）源码复用：

即客户程序直接得到A.h文件和A.CPP源代码，将其添加到客户程序中，然后对所有代码进行编译，链接。

问题：首先，当客户机器上有三个正在运行的应用都复用了A时，那么内存中将会有三份同样的代码。其次，当A进行升级或修改时，必须将所有源码再次分发给所有的客户，并且所有的客户程序都必须重新编译。

（2）目标码复用：

a．  静态库：客户得到A.h文件和相应的静态库文件（主要由.obj构成），然后编译客户代码，并且与链接所得到的静态库文件。

问题：同上面一样，只是当A.h不变时，客户程序只需要重新链接即可。

b．  普通DLL：客户需要知道DLL导出的函数签名和导出的类的结构，然后就可以在运行时装载DLL，并调用其中的功能。

问题：主要是各个编译器对同问题的处理不同，如不同的编译器对同一签名的函数的导出名――即名字改编，就可能不一致。

 

以上的所有方式都有一个潜在的假设：那就是开发源码的编译器和所有客户所使用的编译器是一样的，而现实中不可能这样。由于不同的编译器对导出函数名、导出类的布局可能不一样，所以上面三个基本的重用都难以成立，更不要说对升级的支持。

 

2．普通DLL

   上面提到了普通DLL的一些问题，暂时先放下那个问题，还有一个很重要的问题，假设A.dll导出了一个类CA，某个客户程序使用这个DLL导出类CA工作得很好。这之中，客户需要知道DLL中类的声明结构。客户程序中有类似如下代码：

        CA* aa  =  new CA() ;

但是当A.dll为了增强功能升级为AA.dll时，其所导出的那个类CA个头变大了。当客户采用AA.dll代替A.dll后，再次运行，就会出现错误。这是因为，客户程序并没有重新编译，所以它仍然用sizeof（原CA）的空间去容纳一个变大后的CA对象，当然就出现错误了。

（1）解决这个问题的一个方案是采用一个句柄类，这样一来无论CA的大小怎么变，这个封装CA*的句柄类的大小永远不会变。＝＝》为每一个导出类实现一个句柄类是很繁琐的。

（2）另一个解决方案：不在客户程序中创建DLL中的类的对象，而是将创建对象的工作从客户端移到DLL内部，DLL只需导出另外一个被客户方法，该方法创建一个对象，并返回这个新建对象的指针。

 

 

3．1/2COM DLL

需要说明的是，不同的编译器对一个接口（该接口不含纯虚析构函数，因为不同的编译器对纯虚析构函数指针在vtbl中安放的位置不一样）的vptr和vtbl是一致的。所以考虑将接口从实现中完全分离开来。结合上面的2（2）客户端就不需要知道DLL中复用类声明的结构了，而只需要所使用的接口的声明结构。

 

4．3/4 COM DLL ＝＝》DLL中的类从多接口继承

客户程序在对向上转换时2（2）返回的指针作向上转换时，会使用RTTI，但是RTTI是与编译器相关的，所以，再一次，将这种向上转换的动作移到DLL中，让DLL再次导出一个函数来执行这种转换并返回适当的指针。

 

5．4/5COM DLL

从4后，客户就可以得到指向同一个实体的多个接口型的指针，这样对多个指针执行delete操作，将会导致运行时错误，并且客户必须记住哪个指针对应哪个对象，并保证对每个对象仅仅调用一次delete操作。＝＝》再一次，将这种操作从客户端移到DLL内部，于是产生了引用计数机制。

 

6．COM DLL，COM EXE

    最后规范化所有操作，并提供COM库对COM组件的支持，且COM库最为客户与COM组件之间的桥梁。