论文关键词：com组件 接口 生命周期 c++类 atl组件类 c++基类 atl模板基类 继承
论文摘要：在组件化编程的时代，如何复用历史累积的大量没有组件特性的c++类？本文从工程的角度对这一问题进行探讨，利用现有组件技术，提出了一套将c++类平滑过渡到com组件的完整解决方案。
1. 问题的提出
自从microsoft公布了com（component object model，组件对象模型，简称com）技术以后，windows平台上的开发模式发生了巨大的变化，以com为基础的一系列组件技术将windows编程带入了组件化时代，传统的面向对象的软件开发方法已经逐渐被面向组件的方法所取代。
com标准建立在二进制可执行代码级的基础上，不论何种工具、语言开发的组件，只要符合com规范，就可复用于vc、vb、delphi、bc等各种开发环境中。com的语言无关性将软件复用的层次从源代码级推进到了二进制级，复用更方便，也更安全。
然而，com技术带来全新的软件设计和开发模式的同时，也带来了新的问题。
许多软件公司在开发自己的软件产品过程中，都累积了大量c++类，这些代码设计精良，功能完备，以面向对象的标准来检验无可挑剔。然而，这些代码不支持com，将无法在com时代继续被复用。如果它们在软件组件化的趋势中被淘汰，那对软件公司和开发人员来说都是极大的损失。
com专家don box曾说过，“com is a super c++”。这给了我们一个启示，是否可以实现一种技术，能够动态的为普通c++类加上一层com的封装呢？这样，既可以保持这些代码自身的完整和特性，使它们能继续应用于原来的系统，也可以在需要作为组件使用的时候，把它们动态转变成组件，复用于新系统。
一个自然而然的想法是，为每一个c++类开发一个只暴露一个接口的com组件，将原c++类的每个public方法都对应于该接口的一个方法，接口方法的实现可以简单的调用相对应的c++类方法即可。这样，程序逻辑由原有的c++类控制，但com层的封装则由组件提供。基本思路如下图所示：
本文就这一技术展开讨论，最终提供一套由普通c++类平滑过渡到com组件的完整解决方案。我们选用atl（active template library，活动模板库，简称atl）作为com组件的开发工具，开发环境为visual studio 6.0。如没有特殊说明，下文中的“c++类”指没有组件特性c++类，“c++对象”指c++类的实例；“atl组件类”指用于包装的atl类，“atl对象”指atl组件类的实例。
2. 用atl包装c++类
按上述思路将c++对象动态组件化后，所得的组件实际上由两部分组成：atl组件对象和绑定的c++对象。两者的生命周期互相牵制，但要保持一致。生命周期的管理是c++类动态组件化的首要难点。
c++类分为两种，一种是简单的c++类，一种是集合型的c++类。集合型的c++对象管理一组c++对象，负责其创建和删除，维护它们的生命周期。下面，分别就简单c++类和集合型c++类的组件化技术进行说明，展示解决方案的核心技术。
2.1. 简单c++类的组件化
为使atl组件类可以自由调用c++类的方法，需要：
l 为atl组件类安插一个指针成员变量，指向c++类
l 提供atl对象和c++对象的绑定机制
我们可以在atl组件类初始化时创建一个c++类，用成员变量m_pcppobj记录，在析构时删除，从而实现atl组件类和c++类的天然绑定。但出于灵活性考虑，使得atl组件对象可以绑定任意c++类的对象，我们为atl组件类添加一个绑定函数link2cppobj（cimplement* pobj）。
在atl组件类的构造函数内，创建一个c++对象，用m_pcppobj记录。
如果调用了link2cppobj，则将m_pcppobj指向的对象删除，改用传入的c++对象。
在atl组件类的的析构函数内，删除其绑定的c++对象。由构造函数和link2cppobj函数的定义可知，m_pcppobj指针总是有意义的。
简单c++类组件化的思想如下图所示：
2.2. 集合型c++类的组件化
集合型c++类的情况有所不同。
集合型c++类以数组（array）、列表（list）、映射表（map）的形式管理其它c++对象。集合对象和它管理的元素对象都被包装成组件后，集合型atl对象可能调用一个“destroy”方法，期望删除某一个元素atl对象；这一操作的实质却是，集合型c++对象的“destroy”方法被调用，将元素c++对象删除了，而元素atl对象却不知道。这一操作的结果导致了元素的atl对象存在，而其绑定的c++对象却被删除的情况，两者的生命周期出现了不一致。
为了解决这个问题，我们需要在c++对象被删除时，能将atl对象同时删除；而在atl对象的引用计数为0需要删除自身时，也能把c++对象删除。可行的解决方案是：
l 在c++类中保存一个接口指针，指向绑定在一起的atl对象；为该接口指针赋值的最佳地点显然是提供绑定机制的link2cppobj函数内部，为此，还需要给link2cppobj添加一个iunknown*参数
l 在c++类的析构函数中，判断该接口指针是否为空，如果不为空，则release对接口的引用，引发atl对象自身的析构
现在，技术方案如下图所示：
2.3. 内部创建的组件和外部创建的组件
集合型c++类组件化后仍然是集合型atl组件，它可以创建、删除自己管理的组件。这样，组件的创建就可能有两种情况：
l 由客户直接创建
l 由客户调用集合型组件的接口方法间接创建
创建方式的不同导致了组件生命周期管理的复杂性。一般说来，组件的创建者负责维护组件的生命周期。上述两种情况下，分别由客户和集合型组件维护被创建组件的生命周期。然而，另有一种情况是，客户创建了一个组件，然后送交一个集合型组件管理，现在维护组件生命周期的责任就由客户转交给了集合型组件。
我们的解决方案必须提供这样的健壮性和灵活性，以维护各种情况下组件的生命周期。我们为atl组件类添加一个boo成员m_binnermanage，作为组件的维护标识。内部维护意味着组件的生命周期由其它组件（集合型组件）维护；外部维护则是由客户维护。
缺省情况下，组件是外部创建并维护的，在组件的构造函数内设置外部维护标识。集合型组件创建元素时，需要为元素分别创建一个c++对象和一个atl对象，然后调用atl对象的link2cppobj函数将两者绑定在一起，在link2cppobj函数内修改维护标识。对于第三种情况，可以在外部创建组件由客户转交给集合型组件时，在集合型组件相应方法内重新设置维护标识。
2.4. c++基类
为了对现有c++类的改动最小，我们设计一个基类封装需要为c++类添加的功能。所有需要动态组件化的c++类都必须从这个基类派生，以保证动态组件化中c++对象与atl对象生命周期的一致。如下图示：
实现代码如下所示：
class ccpp2atlobjbase
{
ccpp2atlobjbase ();
public:
// iunknown指针，反指向封装该cpp类的接口
iunknown* m_passociatlunk;
protected:
virtual ~ ccpp2atlobjbase ();
};
ccpp2atlobjbase::ccpp2atlobjbase()
{
// 将iunknown指针初始化为0
m_passociatlunk = null;
}
ccpp2atlobjbase::~ccpp2atlobjbase()
{
// cpp类的对象析构时，release对接口的引用
if (m_passociatlunk)
m_passociatlunk->release();
}
然后，修改现有各个c++类，使之从ccpp2atlobjbase派生，如下面代码片断所示：
class cimplement : public ccpp2atlobjbase
{
……
};
必须指出的是，在ccpp2atlobjbase基类中，我们设置的m_passociatlunk变量存在和现有c++类成员命名冲突的问题。但是，考虑到原c++类并没有组件特性，也应该不会有“iunknown”型指针，因此，只要各个类的变量命名都按照规范的命名法，出现这种名字冲突的可能性是极小的。
2.5. atl模板基类
通过以上分析，我们发现，所有的atl组件类都需要实现一些相同的功能：
l 保留一个指向其绑定c++对象的指针
l 提供一个link2cppobj函数
l 在构造函数中创建一个绑定c++类的对象
为了减化编码，我们定义一个带参数的模板基类，实现上述公共功能，模板参数就是绑定的c++类。然后，所有的atl组件类都从模板基类中派生。现在的技术方案如下图所示：
实现代码如下所示：
template <class t>
class ccpp2atltemplatebase :
{
protected:
// c++类指针
t* m_pcppobj;
// 标识继承该模板的atl对象是否由内部维护
bool m_binnermanage;
public:
/**********************************************************
模板的构造函数，实现如下功能：
1、new一个c++实现类对象
2、缺省情况下，atl对象由外部维护，将内部维护标识设为false
3、将c++类中对atl接口的反指指针设置为空
**********************************************************/
catlcpp2atltemplatebase()
{
m_pcppobj = new t;
m_binnermanage = false;
m_pcppobj->m_passociatlunk = null;
}
/**********************************************************
析构atl对象时，如果该atl对象是由外部创建的，
则显式的删除c++对象
如果atl对象由内部维护，那么什么事都不用做
**********************************************************/
virtual ~catlcpp2atltemplatebase()
{
if (!m_binnermanage) {
if (m_pcppobj)
delete m_pcppobj;
}
}
/**********************************************************
link2cppobj函数，负责绑定c++对象和atl接口
1、删除构造函数中new的c++对象，而使用外部传入的c++对象
2、将atl对象的内部维护标识设为true
3、设置c++基类中的接口指针成员
4、因为atl接口传送给外部使用，需要增加引用计数
**********************************************************/
virtual void link2cppobj(t* pobj, iunknown* punk)
{
assert(pobj != null);
assert(punk != null);
if (m_pcppobj)
delete m_pcppobj;
m_pcppobj = pobj;
m_binnermanage = true;
m_pcppobj->m_passociatlunk = punk;
m_pcppobj->m_passociatlunk->addref();
}
};
然后，每个atl类都从该模板类派生，如下代码片断所示：
class atl_no_vtable catlxx :
……,
// 添加atl模板基类
public ccpp2atltemplatebase<cimplementxx>
{
……
}
3. c++参数类型的自动化包装
在本文的技术方案中，c++类的public方法与atl组件接口中的方法一一对应；相应的，c++类中方法的参数类型也要转换为com规范所允许的数据类型。
在基于com的自动化（automation）技术中，microsoft提供了一套自动化兼容的数据类型variant，定义如下：
typedef struct farstruct tagvariant variant;
typedef struct farstruct tagvariant variantarg;
typedef struct tagvariant {
vartype vt;
unsigned short wreserved1;
unsigned short wreserved2;
unsigned short wreserved3;
union {
byte bval; // vt_ui1.
short ival; // vt_i2.
long lval; // vt_i4.
float fltval; // vt_r4.
double dblval; // vt_r8.
variant_bool boolval; // vt_bool.
scode scode; // vt_error.
cy cyval; // vt_cy.
date date; // vt_date.
bstr bstrval; // vt_bstr.
decimal far* pdecval; // vt_byref|vt_decimal.
iunknown far* punkval; // vt_unknown.
idispatch far* pdispval; // vt_dispatch.
safearray far* parray; // vt_array|*.
byte far* pbval; // vt_byref|vt_ui1.
short far* pival; // vt_byref|vt_i2.
long far* plval; // vt_byref|vt_i4.
float far* pfltval; // vt_byref|vt_r4.
double far* pdblval; // vt_byref|vt_r8.
variant_bool far* pboolval; // vt_byref|vt_bool.
scode far* pscode; // vt_byref|vt_error.
cy far* pcyval; // vt_byref|vt_cy.
date far* pdate; // vt_byref|vt_date.
bstr far* pbstrval; // vt_byref|vt_bstr.
iunknown far* far* ppunkval; // vt_byref|vt_unknown.
idispatch far* far* ppdispval; // vt_byref|vt_dispatch.
safearray far* far* pparray // vt_array|*.
variant far* pvarval; // vt_byref|vt_variant.
void far* byref; // generic byref.
char cval; // vt_i1.
unsigned short uival; // vt_ui2.
unsigned long ulval; // vt_ui4.
int intval; // vt_int.
unsigned int uintval; // vt_uint.
char far * pcval; // vt_byref|vt_i1.
unsigned short far * puival; // vt_byref|vt_ui2.
unsigned long far * pulval; // vt_byref|vt_ui4.
int far * pintval; // vt_byref|vt_int.
unsigned int far * puintval; // vt_byref|vt_uint.
};
};
我们看到，所有简单数据类型都可以在variant中找到对应的定义，但是，在多数的基于c++的系统设计中，方法参数不会仅仅出现简单数据类型，类对象、对象引用、对象指针被频繁的作为参数来传递。
以类对象、对象引用或对象指针形式存在的参数，我们称为复杂类型参数。在技术方案中，所有复杂类型参数在atl接口方法中一律对应接口指针，我们需要提供c++对象（或引用、指针）和atl接口指针之间的动态转换功能。下文就复杂类型作为传入、传出参数分别进行讨论。
3.1. 复杂类型的传入参数
atl接口方法获取一个接口指针参数后，如何将此接口指针转变为c++对象指针？对于atl对象，可以直接取得m_pcppobj变量，而接口指针却不能。所以，需要提供一种途径，从atl接口指针获取atl组件的m_pcppobj变量值。
我们的设计是，为每个atl组件提供一个基接口icppobjseeker，实现对绑定c++对象指针（即m_pcppobj）的查询方法handlecppobj。任意atl接口都从该基接口派生，都可以调用handlecppobj方法。
在前文就生命周期管理进行讨论时，曾提到这样一种情况：客户创建了一个组件，然后送交集合型组件管理。在集合型组件获取外部创建的组件的同时，需要：
l 取得后者的c++对象指针。集合型组件对元素组件管理的实质是通过集合型c++对象对元素的c++对象进行管理，而集合型atl对象和元素atl对象之间并没有直接联系
l 修改新加入元素组件的维护标识
因此，我们为icppobjseeker接口添加postcppobj方法，用于实现以上功能。
icppobjseeker接口idl定义如下所示，因为icppobjseeker接口和handlecppobj、postcppobj方法实际上都应用于内部，所以使用“hidden”属性对外隐藏：
[
object,
uuid(1e9f7f79-936d-4680-9f8e-34a7dccff818),
dual,
hidden,
helpstring("icppobjseeker interface"),
pointer_default(unique)
]
interface icppobjseeker : idispatch
{
[id(1), helpstring("取得c++对象的指针"), hidden]
hresult handlecppobj([out, retval] long* pcppobj);
[id(2), helpstring("取得c++对象的指针，客户程序不再负责对c++对象生命周期的维护"), hidden]
hresult postcppobj([out, retval] long* pcppobj);
};
icppobjseeker接口的方法可以放在ccpp2atltemplatebase模板基类中统一实现：
template <class t>
class ccpp2atltemplatebase :
{
……
/**********************************************************
handlecppobj函数，由icppobjseeker接口定义，
负责取得atl接口中的c++对象指针
**********************************************************/
stdmethodimp handlecppobj(long *pcppobj)
{
afx_manage_state(afxgetstaticmodulestate())
*pcppobj = (long)m_pcppobj;
return s_ok;
}
/**********************************************************
postcppobj函数，由icppobjseeker接口定义，
负责取得atl接口中的c++对象指针，
同时标记对象为内部维护，客户不再负责对象的生命周期管理
**********************************************************/
stdmethodimp postcppobj(long *pcppobj)
{
afx_manage_state(afxgetstaticmodulestate())
*pcppobj = (long)m_pcppobj;
if (m_binnermanage == false) {
m_binnermanage = true;
m_pcppobj->m_passociatlunk = this;
m_pcppobj->m_passociatlunk->addref();
}
return s_ok;
}
};
现在，所有的接口都不再直接从idispatch派生，而改从icppobjseeker派生，因此，idispatch的实现也应该在实现icppobjseeker接口的同一级或下级中提供。为了包容idispatch，我们将atl模板基类稍作改动：
template <class t, class q, const iid* piid, const guid* plibid = &ccommodule::m_libid>
class atl_no_vtable ccpp2atltemplatebase :
public idispatchimpl<q, piid, plibid>
{
……
};
在从该模板类派生atl类时，将atl wizard自动生成的对idispatch接口的实现注释，而使用新定义的ccpp2atltemplatebase，如下代码片断所示：
class atl_no_vtable catlxx :
……,
// 将atl wizard生成的对idispatch接口的支持注释
// public idispatchimpl<ixx, &iid_ixx, &libid_cpp2atllib>,
// 添加atl模板基类
public ccpp2atltemplatebase<cimplementxx, ixx, &iid_ixx, &libid_cpp2atllib>
{
……
}
3.2. 复杂类型的传出参数
从c++指针转换为接口指针基本上不存在困难，为方便使用，我们提供一个基于本技术方案的宏定义，如下代码所示：
/**********************************************************
从c++指针获取对应atl接口的宏
传入：c++指针，对应的atl类名，接口iid
传出：接口指针，执行状态hresult
**********************************************************/
#define cppobj_to_com_interface(pcppobj, catlclass, iid_idefine, ppinterface, hresult ) \
{ \
assert(pcppobj != null); \
if (pcppobj->m_passociatlunk != null) \
{ \
hresult = pcppobj->m_passociatlunk-> \
queryinterface(iid_idefine, (void **)ppinterface); \
atlassert(succeeded(hresult)); \
} \
else \
{ \
ccomobject<ccomatlclass>* pcomobj; \
hresult = ccomobject<ccomatlclass>::createinstance(&pcomobj); \
atlassert(succeeded(hresult)); \
hresult = pcomobj-> \
queryinterface(iid_idefine, (void **)ppinterface); \
atlassert(succeeded(hresult)); \
if (hresult == s_ok) \
pcomobj->link2cppobj(pcppobj, *ppinterface); \
}\
}
4. 接口的继承与多态
c++类的继承应用十分广泛，动态化后的组件应该保留原c++类之间的继承关系。在我们的技术方案中，c++类和接口一一对应，c++类的继承关系也应该体现在各个接口上，如下图所示：
4.1. 支持继承的系列atl模板基类
实现接口继承的实质是为派生atl类添加基接口，而为一个atl类添加接口的实质则是：
l 修改idl文件，体现接口的继承关系
l 在atl类中提供接口实现
修改idl文件很简单，只需要更改派生接口的基接口即可。在atl类中添加基接口的实现倒颇费思量，我们的做法是：
l 扩展atl模板基类的意义，每一个atl组件类都对应一个模板基类，都从该模板基类派生
l 派生类的模板基类，从基类的模板基类中派生；ccpp2atltemplatebase是模板派生树的根节点，所有的模板都派生自ccpp2atltemplatebase
l 所有的接口方法，都在对应的模板基类中实现
atl派生类继承自它对应的模板基类，这个模板基类又继承自atl基类对应的模板基类，而在atl基类的模板基类中提供了基接口的实现。所以，atl派生类最终继承了基接口的实现。c++类、atl类、各模板基类的继承关系如下图所示：
假定ibaseitf是基接口，iinherititf是派生接口。atl基类对应的模板基类定义如下：
/****************************************************************************
模板类catlbaseitf，提供了ibaseitf的实现，
用于将ibaseitf接口作为基接口共供其它接口继承
****************************************************************************/
template <class t, class q, const iid* piid, const guid* plibid = &ccommodule::m_libid>
class atl_no_vtable catlbaseitf : public ccpp2atltemplatebase<t, q, piid, plibid>
{
public:
// 基接口方法“basefunc”，在此模板类内实现
stdmethod(basefunc)()
{
m_pcppobj->basefunc();
return s_ok;
}
};
atl派生类对应的模板基类定义如下：
/****************************************************************************
模板类catlinherititf，继承了基接口ibaseitf方法的实现，
同时提供了iinherititf的实现，可以将iinherititf接口作为基接口共供其它接口继承
****************************************************************************/
template <class t, class q, const iid* piid, const guid* plibid = &ccommodule::m_libid>
class atl_no_vtable catlinherititf : public catlbaseitf<t, q, piid, plibid>
{
public:
// 派生接口方法“inheritfunc”，在此模板类内实现
stdmethod(inheritfunc)()
{
m_pcppobj->inheritfunc();
return s_ok;
}
};
更改iinherititf接口的idl定义：
[
object,
uuid(8f3902df-da55-4802-ab8a-958aff45b2f4),
dual,
helpstring("ibaseitf interface"),
pointer_default(unique)
]
// 基接口从icppobjseeker派生
interface ibaseitf : icppobjseeker
{
[id(1), helpstring("ibaseitf method")] hresult basefunc();
};
[
object,
uuid(afebd472-4bec-45ce-a5a2-e37537c4744a),
dual,
helpstring("iinherititf interface"),
pointer_default(unique)
]
// iinherititf接口从ibaseitf接口派生
interface iinherititf : ibaseitf
{
[id(11), helpstring("iinherititf method")] hresult inheritfunc();
};
最后，更改atl派生类的模板基类：
class atl_no_vtable catlinherit :
……,
public catlinherititf<cinherititfimplement, iinherititf, &iid_iinherititf, &libid_cpp2atllib>
{
……
};
现在，通过iinherititf，我们可以使用ibaseitf的所有方法，实现了接口的继承。
4.2. 接口的多态性
在实现接口的继承后，要展现接口的多态性就很容易了，只需在atl派生类声明的接口映射表中添加基接口表项即可：
class atl_no_vtable catlinherit :
……,
public catlinherititf<cinherititfimplement, iinherititf, &iid_iinherititf, &libid_cpp2atllib>
{
……
begin_com_map(cinherititf)
com_interface_entry(iinherititf)
com_interface_entry(ibaseitf)
……
end_com_map()
……
};
就象c++中基类指针所展现的多态性一样，一个“ibaseitf *”型指针可以完全操纵iinherititf接口，而不需要知道真正的接口类型。
5. 总结
至此，我们的技术方案全部介绍完毕。c++基类ccpp2atlobjbase、atl模板基类ccpp2atltempbase和基接口icppobjseeker是方案中的关键技术。ccpp2atlobjbase配合ccpp2atltempbase，完善了组件对象生命周期的管理机制；通过基接口icppobjseeker，我们可以从任意接口反向查询c++对象；ccpp2atltempbase提供了c++对象和atl组件的自由绑定功能，封装了idispatch接口的实现，而进一步定义的atl模板基类继承体系则极大的方便了接口的自由继承。
在本文快结束的时候，我们不得不特别提到microsoft的“.net framework”。“.net”开发框架的推出，的确解决了com技术的许多困惑，也包括本技术方案所要解决的一些技术问题。然而“.net framework”是一个“改朝换代”的变化，要想一步将原来基于c++的系统（尤其是大型系统）完全移植到“.net”平台上是不可想象的，其工作量不亚于重新开发，所以microsoft特别推荐从com技术到“.net”平台的平滑移植。由此看来，本文提出的动态组件化的技术更显得可贵，它从工程化的角度，着眼于实际应用，解决了从面向对象的c++到基于组件的com技术的许多问题，既充分保护了原有系统的积累，又为这些系统搭上日益发展的“.net”快车提供了可能。
参考文献
《com原理与应用》，潘爱民 著，清华大学出版社
《com本质论（essential com）》，don box 著，潘爱民 译，中国电力出版社
《深入解析atl（atl internals）》，brent rector、chris sells 著，潘爱民、新语 译，中国电力出版社
《设计模式－可复用面向对象软件的基础（design patterns－elements of reusable object-oriented software）》，erich gamma、richard helm、ralph johnson、john vlissides 著，李英军、马晓星、蔡敏、刘建中 等译
中国论文网(www.lunwen.net.cn)免费学术期刊论文发表,目录,论文查重入口,本科毕业论文怎么写,职称论文范文,论文摘要,论文文献资料,毕业论文格式,论文检测降重服务。
