聪明的作者很快就实现了他的COM组件，源码大概是下面这个样子，不要奇怪为什么作者的COM之路这么顺风顺水，这么快就出了作品。
#pragma once class IExtensibleObject { public: virtual void* Dynamic_Cast(const char* str)=0; virtual void AddRef()=0; virtual void Release()=0; }; class IFastString:public IExtensibleObject { public: virtual int Length(void)=0; virtual int Find(const char* str)=0; }; class FastString:public IFastString { public: FastString(const char* str=NULL); virtual void* Dynamic_Cast(const char* str); virtual void AddRef() ; virtual void Release(); virtual int Length(); virtual int Find(const char* str); ~FastString(); private: char* m_str; int len; int m_cPtrs;//引用计数 }; //导出函数 extern "C" __declspec(dllimport) IFastString* CreateFastString(const char* psz); |
作者的COM组件做到了一下几点，终于实现了增量更新。
1：作者不在以源码的方式卖给厂商，而是以头文件和库的方式卖个厂商，厂商可以通过静态/动态的方式链接作者的库。
2：作者不在让厂商到处实例化他的FastString，我可爱的FastString。而是通过一个导出函数实例化FastString，并返回IFastString，这样就不会出现不同DLL中FastString实例大小不一样的问题。现在所有的实例都在作者的DLL中创建了。
3：关于回收FastString的问题？作者刚开始是想直接delete掉CreateFastString返回的指针，但为了实现COM组件，此时的FastString已经不是彼时的自己了，他继承并实现了多个接口，由于接口之间转换来转换去，都不知道删除哪个指针了，于是作者决定通过使用引用计数的方式销毁FastString。
4：为什么要自己实现Dynamic_Cast？
RTTI是一个与编译器极为相关的特征，每个编译器厂商对RTTI的实现是独有的，这大大破坏了“以抽象基类作为接口而获得的编译器独立性”，既然每个编译器可能有不同的实现，即析构函数不能定义成虚函数，因为不同的编译器，虚函数在虚方法表中的位置是不一样的，有的编译器放在最前面有的放在最后面，这会导致不同的编译器编译后虚方法在虚方法表中的位置是不一样的。所以析构函数不能定义成virtual，其他public接口都必须定义成virtual。其他虚方法在虚方法表中的位置和虚方法的声明保持一致，即按照声明的顺序存放在虚方法中。
由于类型转换和引用计数是每个接口都需要的，于是把他们提出来放到最顶层，让所有的接口继承它。
5：新增的接口只能加在最后面，废弃的接口不能删除。
如果新增的接口插在中间，那么部分接口在虚方法表中的地址就会发生变化，新版本的DLL就不能与已经发布的程序兼容，就不能实现增量升级，即只用覆盖某个DLL，而不需要全部都要更新，废弃的接口删除会导致同样的问题。
综述：为什么作者的这个DLL能实现增量更新？
COM对象通过特定的导出方法在DLL中以new的方式创建，通过引用计数自动析构，客户端不能自己创建COM对象，COM对象的内部结构发生变化，对外部也没有影响，如果新增了接口，就在最后加，之前的接口在虚方法表中的位置不会受到印象，即对别的接口没有影响，废弃的接口不能删除，
改变对象的内存结构和新增virtual方法都没关系，那不就成了。实现增量不在是问题，我们在回到FastString这个问题上，如果FastString一开始是以上诉方式实现的，现在要新增一个len字段和一个Length接口，我就这样增了，新出个版本，直接覆盖以前的那个DLL，我直接可以用，一切都是OK的，外部的调用不会受到任何影响。为了证明这个FastString能实现增量升级，我做了一个DEMO，大家可以试一下，我就是下载地址。
你或许会说我这说的都不是COM，但这的确是更好的C++。
