COM思想学习---把接口从实现中分离出来

1.在封装DLL时，首先介绍一下句柄类的思想：

当一个类里面有具体的实现内容并且有迭代更新的可能，我们通常不会把这个类选择导出。一种常用的思想是借鉴句柄的实现方式：

class FastStringItf { class FastString; FastString * m_pThis; public: FastStringItf(const char * psz); ~FastStringItf(void); int Length(void) const; int Find(const char *psz ) const; }这样的接口类内部包含一个FastString的指针成员，很有效的吧FastSting的实现部分隐藏起来，因此不会随着实现类FastSting中数据成员的加入或者删除而改变。使得FastSting在后续的更新中非常灵活。但是缺点在于当类库较大的时候，编写这些方法的传递过程会非常冗长，也增加了出错的可能性。同时每个方法增加两个函数调用对于性能的开销也不理想。

2.于是考虑抽象基类将“接口与实现分离，定义一个只定义行为的抽象类。

class IFastString { public: virtual void Delete(void) = 0; virtual int Length() const = 0; virtual int Find(const char* psz); } extern "C" IFastString* CreateFastString(const char* psz);为了使用FastString数据类型，客户只需简单的调用包含接口定义文件，并且调用CreateFastSting就可以工作。 上述DLL只引出了一个符号CreateFastSting,这使得客户可以很方便的按需装入DLL并且使用GetProAddress得到唯一的函数入口:

IFastSting *CallCreateFastSting(const char* psz) { static IFastString*(*pfn)(const char*) = 0;//pfn在此处是一个函数指针 if(!pfn) { const TCHAR szDLL[] = _T("FastString.DLL"); const char szFn[] = "CreateFastSting"; HINSTANCE h = LoadLibrary(szDLL); if(h) *(FARPROC*)&pfn = GetProAddress(h,szFn); } return pfn?pfn(psz) = 0; } 上述技术有几个很好的应用：

a.没有安装该DLL时不会产生系统错误

b.减少进程地址空间的初始化工作，DLL并没有在进程初始化的时候被装载进来

c.允许客户在同一接口的不同实现之间做出选择，比如当一个接口有几个不同版本的实现，客户可以通过DLL的文件名来动态加载。

3.如果现在有扩展接口的需求，我们该怎么办呢？

你会自然的想到：

class IFastSting { public: // version 1.0 virtual void Delete(void) = 0; virtual int Length(void) = 0; virtual int Find(const char* psz) = 0; //version 2.0 virtual int FindN(const char* psz,int n) = 0; } 然而当新的接口碰到老的DLL时，由于没有新引入的函数实现，就会导致程序崩溃。问题在于它修改了公开接口，从而打破了对象的封装性。

因此为了保证不破坏原有接口，我们可以考虑将派生一个接口：

class IFastring2:public IFastSting { public: virtual int FindN(const char* psz,int n) = 0; }客户可以在运行时询问对象，以确定与IFastString2相容。

int Find10thBob(IFastString* pfs) { IFastSting2 * pfs2 = dynamic_cast<IFastString2*>(pfs); if(pfs2) return pfs2->FindN("Bob",10); else { error("Canot find "); return -1; } } 完。