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;
}
}
完。