序言：
N年前，我们曾在软件开发上出现了这样的困惑，用VC开发COM组件过于复杂，用VB开发COM组件发现效率低，而且不能实现面向对象的很多特性，例如，继承，多态等。更况且如何快速封装利用历史遗留的大量C++代码本身就是一个大的难题。
当时，开发小组的成员通过共同努力，摸索了一套C++类的动态组件化技术，很好的解决了以上的问题，通过这个技术，我们继承了大量的C++代码，同时使这些C++程序以COM+组件的形式得以新生。通过这几年在实际应用中的考验，这个技术是成熟可靠的。
也许新的系统大多数都完全构建在.Net 或者 Java 上，但是我觉得当时我们研究C++类对象的组件化的思路很好，从软件工程的角度，解决了一个日常程序员可能遇到的难题。大家用一套组件编程的规范实现程序，也降低了代码的难度，提高了维护性。这样一般对COM技术不是很熟悉的程序员也能用C++做出优良的COM组件，并且能实现组件的继承，多态等。
现在我将这个技术的思路在博客上公开，如果还能对大家现在的工作有所帮助的话，实在荣幸，呵呵！
C++类的动态组件化技术
关键词
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++对象实例是以普通对象存在的，只有外部需要以组件的方式得到该C++对象实例的时候，程序会自动给该对象加上一个组件外壳。外部程序通过外壳的接口实现对该C++对象的操作。
这样，程序逻辑由原有的C++类控制，但COM层的封装则由组件提供。基本思路如下图所示：
本文就这一技术展开讨论，最终提供一套由普通C++类平滑过渡到COM组件的完整解决方案。我们选用ATL（Active Template Library，活动模板库，简称ATL）作为COM组件的开发工具。如没有特殊说明，下文中的“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++类是以数组（array）、列表（list）、映射表（map）等容器形式管理其它C++对象。集合对象和它管理的元素对象如果用上述方法分别包装成组件后，集合型ATL对象可能调用一个“Destroy”方法，期望删除集合型ATL对象及其对应的元素ATL对象。但这一操作的实质却是，在调用集合型ATL对象的“Destroy”方法时，集合型C++对象的“Destroy”方法被调用，将元素C++对象删除了，而元素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组件类添加一个BOOL成员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
{
……
};
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所有简单数据类型都可以在VARIANT中找到对应的定义，但在多数的基于C++的系统设计中，方法参数不会仅仅出现简单数据类型，类对象、对象引用、对象指针被频繁的作为参数来传递。
以类对象、对象引用或对象指针形式存在的参数，我们称为复杂类型参数。在技术方案中，所有复杂类型参数在ATL接口方法中一律对应接口指针，我们需要提供C++对象（或引用、指针）和ATL接口指针之间的动态转换功能。
复杂类型在传入时，如何将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方法，用于实现以上功能。
复杂类型在传出时只需从C++指针转换为接口指针即可。
4. 接口的继承与多态
C++类的继承应用十分广泛，动态化后的组件应该保留原C++类之间的继承关系。在我们的技术方案中，C++类和接口一一对应，C++类的继承关系也应该体现在各个接口上，如下图所示：
实现接口继承的实质是为派生ATL类添加基接口，而为一个ATL类添加接口的实质则是：
l 修改IDL文件，体现接口的继承关系
l 在ATL类中提供接口实现
修改IDL文件很简单，只需要更改派生接口的基接口即可。在ATL类中添加基接口的实现倒颇费思量，我们的做法是：
l 扩展ATL模板基类的意义，每一个ATL组件类都对应一个模板基类，都从该模板基类派生
l 派生类的模板基类，从基类的模板基类中派生；CCPP2ATLTemplateBase是模板派生树的根节点，所有的模板都派生自CCPP2ATLTemplateBase
l 所有的接口方法，都在对应的模板基类中实现
ATL派生类继承自它对应的模板基类，这个模板基类又继承自ATL基类对应的模板基类，而在ATL基类的模板基类中提供了基接口的实现。所以，ATL派生类最终继承了基接口的实现。C++类、ATL类、各模板基类的继承关系如下图所示：
在实现接口的继承后，要展现接口的多态性就很容易了，只需在ATL派生类声明的接口映射表中添加基接口表项即可。
5. 总结
为了普通C++类平滑过渡到COM组件，首先利用ATL组件包装C++类，在包装C++类时在C++类中添加了一个指向ATL组件接口的指针来解决ATL组件和C++类生命周期的一致性问题，随后我们利用C++基类和ATL模板基类简化了这些工作的实现；然后我们对C++参数类型进行了自动化包装；最后我们利用模板实现了接口的继承和多态。至此，我们就完整地实现了将普通C++类平滑过渡到COM组件。在上述实现中，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”快车提供了可能。
参考文献
l 《COM原理与应用》，潘爱民 著，清华大学出版社
l 《COM本质论（Essential COM）》，Don Box 著，潘爱民 译，中国电力出版社
l 《深入解析ATL（ATL Internals）》，Brent Rector、Chris Sells 著，潘爱民、新语 译，中国电力出版社
l 《设计模式－可复用面向对象软件的基础（Design Patterns－Elements of Reusable Object-Oriented Software）》，Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 著，李英军、马晓星、蔡敏、刘建中 等译