文章索引：
一、概述和待剖析宏罗列
二、MFC、ATL COM支持原理概述
三、宏剖析
☆ ☆ MFC篇
PART1----接口基础构造的由来
PART2 ----深入CCmdTarget看一看COM三大元素的实现
PART3------类厂的由来
PART4-------自动化支持
PART5-------组件得以使用的纽带：几个核心函数
☆ ☆ ATL篇
PART1----几个核心模板类介绍
PART2----模板撑起的天空 : 接口的由来
PART3-------自动化支持
PART4------深入核心模板类
PART5-------组件得以使用的纽带：几个核心函数
---------------------------------------------------------------------------------------------------------------------------
COM是出了名的难缠.原因在于它本身的设计灌注了大量的细节处理,九曲十八弯,令人迷惑.
然而MS惯用的宏手法,也是令很多人迷惑、久久不得思路.那么MFC、ATL用宏手法来提供对
COM开发的支持,就更加令人…了.下面我们就进程内组件开发探讨一下MFC、ATL对COM开
发的基础支持是怎样实现的….
一、概述和待剖析宏罗列
二、MFC、ATL COM支持原理概述
三、宏剖析
☆ ☆ MFC篇
PART1----接口基础构造的由来
PART2 ----深入CCmdTarget看一看COM三大元素的实现
PART3------类厂的由来
PART4-------自动化支持
PART5-------组件得以使用的纽带：几个核心函数
☆ ☆ ATL篇
PART1----几个核心模板类介绍
PART2----模板撑起的天空 : 接口的由来
PART3-------自动化支持
PART4------深入核心模板类
PART5-------组件得以使用的纽带：几个核心函数
---------------------------------------------------------------------------------------------------------------------------
COM是出了名的难缠.原因在于它本身的设计灌注了大量的细节处理,九曲十八弯,令人迷惑.
然而MS惯用的宏手法,也是令很多人迷惑、久久不得思路.那么MFC、ATL用宏手法来提供对
COM开发的支持,就更加令人…了.下面我们就进程内组件开发探讨一下MFC、ATL对COM开
发的基础支持是怎样实现的….
一、概述和待剖析宏罗列
首先给你一个关于COM结构大致的描述 : 在组件(dll,exe,ocx等)内,存在大量的组件类
(CoClass),每个组件类维护N多的接口(interface),接口背后维护N的方法.自然还有类厂
(ClassFactory),类厂是组件类的平行类.
不错,那么MFC、ATL是怎样将上述的结构实现的呢 ？
针对MFC我们需要剖析的宏罗列于下：
存在组件类.h和.cpp文件中的宏：
1. DECLARE_DYNCREATE(CSAM)
IMPLEMENT_DYNCREATE(CSAM, CCmdTarget)[.cpp]
简要说明：支持RTTI和动态创建类对象能力.
关于此,下面不会详细讲解.
欲了解更多细节者可参见
《深入浅出MFC》,原理相同
2. DECLARE_MESSAGE_MAP()
BEGIN_MESSAGE_MAP(CSAM, CCmdTarget)[.cpp]
END_MESSAGE_MAP()
简要说明：维护消息处理系统,原因在于MFC仍然
以CwinApp对象为核心.
对于此,下面不会详解,
欲知详情,参考《深入浅出MFC》.
3.DECLARE_OLECREATE(CSAM)
IMPLEMENT_OLECREATE(CSAM, "MFCCOM.SAM",
0x43d242f9, 0x4f7e, 0x4cbb, 0xae, 0xda, 0x77, 0x8d, 0xa1, 0x16, 0xd0, 0xd9)
简要说明：创建类厂对象,且将类厂和组件类关联,
为通过CLSID创建类实例提供保证.
4.DECLARE_DISPATCH_MAP()
BEGIN_DISPATCH_MAP(CSAM, CCmdTarget)[.cpp]
END_DISPATCH_MAP()
简要说明：支持自动化分发,事实上,
这里体现MFC对COM支持的真正意图,
因为MFC默认派生的接口为dispinterface
(纯dispatch接口),具体细节下面会描述.
5.DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_MAP(CSAM, CCmdTarget)[.cpp]
INTERFACE_PART(CSAM, IID_ICOM, Dispatch)
END_INTERFACE_MAP()
简要说明：创建接口映射表,这里的手法在MS的FrameWork中随处可见
虽然可能细节的实现不同.
在dll主文件中的： [xxx.cpp]
1.AFX_MANAGE_STATE(AfxGetStaticModuleState())
简要说明：这里是模块的状态管理.
很重要,它维护关于程序的
大量信息,我们将讨论其中的类厂表.
2. COleObjectFactory::RegisterAll()
简要说明：在dll初始化时,注册所有的类厂.
3. AfxDllGetClassObject(rclsid, riid, ppv);
简要说明：根据rclsid获取类厂指针.
几个重要的函数：
1. EnableAutomation()
简要说明：存在于各组件类的构造函数中
使得CcmdTarget内含的xDiapatch首先获得
另一个内含的实现Idispatch的对象的vtable,
从而使得programmers自建的接口类成为真正的
实用品.
这里有点复杂,详细的下面说明.
2. AfxOleLockApp()
简要说明：存在于各组件类的构造函数中
自然这个组件类须是Creatable By ID的
才会显式.
创建组件对象时,锁定App,进入临界区.
3. AfxOleUnlockApp()
简要说明： 存在于各组件类的构析函数中
自然这个组件必须是Creatable By ID 的,
才会显式.
退出临界区.
是否OLE 自动化创建的所有对象销毁,
是则终止应用程序，在析构函数中调用.
4. CCmdTarget::OnFinalRelease()
组件类对象的最后引用释放后,进行的收尾工作.
针对ATL我们需要剖析的宏罗列如下：
在组件类.h文件中的宏：
在.h文件中：
1. DECLARE_REGISTRY_RESOURCEID(IDR_SIM)
简要说明：支持用注册表脚本注册组件,脚本
在ATL中作为资源的一种.
2.DECLARE_PROTECT_FINAL_CONSTRUCT()
简要说明：防止组件类对象被删除.
3.BEGIN_COM_MAP(CSim)
COM_INTERFACE_ENTRY(ISim)
COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()
简要说明：生成COM映射表,其作用与MFC的接口映射表作用是一样的.
在.cpp文件中：[xxx.cpp]
5. BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_Sim, CSim)
END_OBJECT_MAP()
简要说明：生成组件类表,保存所有组件类的大量信息,包括
CLSID、组件类的类工厂、更新注册成员函数的指针、
获得描述成员函数的指针、创建组件类实例成员函数的指针等.
这里也是一个关键之所在.
我们发现上面的MFC和ATL宏大有不同.是吧,事实上它们实现的手法也是大不相同的.
首先给你一个关于COM结构大致的描述 : 在组件(dll,exe,ocx等)内,存在大量的组件类
(CoClass),每个组件类维护N多的接口(interface),接口背后维护N的方法.自然还有类厂
(ClassFactory),类厂是组件类的平行类.
不错,那么MFC、ATL是怎样将上述的结构实现的呢 ？
针对MFC我们需要剖析的宏罗列于下：
存在组件类.h和.cpp文件中的宏：
1. DECLARE_DYNCREATE(CSAM)
IMPLEMENT_DYNCREATE(CSAM, CCmdTarget)[.cpp]
简要说明：支持RTTI和动态创建类对象能力.
关于此,下面不会详细讲解.
欲了解更多细节者可参见
《深入浅出MFC》,原理相同
2. DECLARE_MESSAGE_MAP()
BEGIN_MESSAGE_MAP(CSAM, CCmdTarget)[.cpp]
END_MESSAGE_MAP()
简要说明：维护消息处理系统,原因在于MFC仍然
以CwinApp对象为核心.
对于此,下面不会详解,
欲知详情,参考《深入浅出MFC》.
3.DECLARE_OLECREATE(CSAM)
IMPLEMENT_OLECREATE(CSAM, "MFCCOM.SAM",
0x43d242f9, 0x4f7e, 0x4cbb, 0xae, 0xda, 0x77, 0x8d, 0xa1, 0x16, 0xd0, 0xd9)
简要说明：创建类厂对象,且将类厂和组件类关联,
为通过CLSID创建类实例提供保证.
4.DECLARE_DISPATCH_MAP()
BEGIN_DISPATCH_MAP(CSAM, CCmdTarget)[.cpp]
END_DISPATCH_MAP()
简要说明：支持自动化分发,事实上,
这里体现MFC对COM支持的真正意图,
因为MFC默认派生的接口为dispinterface
(纯dispatch接口),具体细节下面会描述.
5.DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_MAP(CSAM, CCmdTarget)[.cpp]
INTERFACE_PART(CSAM, IID_ICOM, Dispatch)
END_INTERFACE_MAP()
简要说明：创建接口映射表,这里的手法在MS的FrameWork中随处可见
虽然可能细节的实现不同.
在dll主文件中的： [xxx.cpp]
1.AFX_MANAGE_STATE(AfxGetStaticModuleState())
简要说明：这里是模块的状态管理.
很重要,它维护关于程序的
大量信息,我们将讨论其中的类厂表.
2. COleObjectFactory::RegisterAll()
简要说明：在dll初始化时,注册所有的类厂.
3. AfxDllGetClassObject(rclsid, riid, ppv);
简要说明：根据rclsid获取类厂指针.
几个重要的函数：
1. EnableAutomation()
简要说明：存在于各组件类的构造函数中
使得CcmdTarget内含的xDiapatch首先获得
另一个内含的实现Idispatch的对象的vtable,
从而使得programmers自建的接口类成为真正的
实用品.
这里有点复杂,详细的下面说明.
2. AfxOleLockApp()
简要说明：存在于各组件类的构造函数中
自然这个组件类须是Creatable By ID的
才会显式.
创建组件对象时,锁定App,进入临界区.
3. AfxOleUnlockApp()
简要说明： 存在于各组件类的构析函数中
自然这个组件必须是Creatable By ID 的,
才会显式.
退出临界区.
是否OLE 自动化创建的所有对象销毁,
是则终止应用程序，在析构函数中调用.
4. CCmdTarget::OnFinalRelease()
组件类对象的最后引用释放后,进行的收尾工作.
针对ATL我们需要剖析的宏罗列如下：
在组件类.h文件中的宏：
在.h文件中：
1. DECLARE_REGISTRY_RESOURCEID(IDR_SIM)
简要说明：支持用注册表脚本注册组件,脚本
在ATL中作为资源的一种.
2.DECLARE_PROTECT_FINAL_CONSTRUCT()
简要说明：防止组件类对象被删除.
3.BEGIN_COM_MAP(CSim)
COM_INTERFACE_ENTRY(ISim)
COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()
简要说明：生成COM映射表,其作用与MFC的接口映射表作用是一样的.
在.cpp文件中：[xxx.cpp]
5. BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_Sim, CSim)
END_OBJECT_MAP()
简要说明：生成组件类表,保存所有组件类的大量信息,包括
CLSID、组件类的类工厂、更新注册成员函数的指针、
获得描述成员函数的指针、创建组件类实例成员函数的指针等.
这里也是一个关键之所在.
我们发现上面的MFC和ATL宏大有不同.是吧,事实上它们实现的手法也是大不相同的.
二、MFC、ATL COM支持原理概述
首先我们必须清楚：MFC、ATL支持COM的手法是不一样的.
MFC是通过嵌套类,而ATL是通过多继承.
MFC支持手法概述：在一般的嵌套类解决方案中,嵌套类对象中需要维护一个指向
包裹类对象的指针,这样才能在接口(其实是嵌套类对象)之间转移,并实现与包裹类
的本身的通信.然而由于Programmers并不需要自己处理在QueryInterface时保证
接口指针指向正确的地址.事实上,ATL手法也不需要.所以MFC在具体实现上,
采用了MS的惯用手法：建偏移量表.表中记录IID和接口vtable与包裹类对象地
址this之间的偏移量.这样,在得到组件类的地址时,就可以得到接口的地址,从而
调用方法.自然,这里还有一个你感觉不到的问题：不采取特殊的手段
在接口指针级回到包裹类会又是一问题,然而MFC在这个问题上的解决方案是：
早就将嵌套类的AddRef、Release、QueryInterface,转移到包裹类的调用.
这样还怕进去了回不来吗 ? 这是在xDispatch中实现的.
没办法MS就钟情与data-driven,而且它产品中,这种手法的确玩的炉火纯青.
我实验了通过在嵌套类中维护包裹类指针,事实上的确比这里的
方法不好控制.
这里的一切手段的由来,都是针对解决类嵌套的特征的.
值得讲一下的是,这里使用的手法有组件的聚合之风范.你就带着这份感觉来
透彻的理解聚合和这里对嵌套的处理吧…
ATL支持手法概述：ATL的支持手法,可能很贴近你的思维.组件类从任意的接口继承,
这样就可以利用接口在C++中的虚特征实现方法,自然同于MFC,接口必须共享
一套AddRef、Release、QueryInterface实现.这也是由C++的虚机制保证的.
MFC是通过嵌套类,而ATL是通过多继承.
MFC支持手法概述：在一般的嵌套类解决方案中,嵌套类对象中需要维护一个指向
包裹类对象的指针,这样才能在接口(其实是嵌套类对象)之间转移,并实现与包裹类
的本身的通信.然而由于Programmers并不需要自己处理在QueryInterface时保证
接口指针指向正确的地址.事实上,ATL手法也不需要.所以MFC在具体实现上,
采用了MS的惯用手法：建偏移量表.表中记录IID和接口vtable与包裹类对象地
址this之间的偏移量.这样,在得到组件类的地址时,就可以得到接口的地址,从而
调用方法.自然,这里还有一个你感觉不到的问题：不采取特殊的手段
在接口指针级回到包裹类会又是一问题,然而MFC在这个问题上的解决方案是：
早就将嵌套类的AddRef、Release、QueryInterface,转移到包裹类的调用.
这样还怕进去了回不来吗 ? 这是在xDispatch中实现的.
没办法MS就钟情与data-driven,而且它产品中,这种手法的确玩的炉火纯青.
我实验了通过在嵌套类中维护包裹类指针,事实上的确比这里的
方法不好控制.
这里的一切手段的由来,都是针对解决类嵌套的特征的.
值得讲一下的是,这里使用的手法有组件的聚合之风范.你就带着这份感觉来
透彻的理解聚合和这里对嵌套的处理吧…
ATL支持手法概述：ATL的支持手法,可能很贴近你的思维.组件类从任意的接口继承,
这样就可以利用接口在C++中的虚特征实现方法,自然同于MFC,接口必须共享
一套AddRef、Release、QueryInterface实现.这也是由C++的虚机制保证的.
