com组件开发难学之原因浅析

再次叩问让我屡次碰得头破血流的 com ，让我对她的认知更近一步。

 

       com 是个好东西， office 自动化编程， active 插件， vs studio 插件， ie 插件，动态脚本支持，她的应用如此吸引着我，然而，她又是如此的可望而不可即。

 

       最近先是由于项目中使用 wtl ，而开始研读 wtl 源码，以及学习领悟一些 windows 编程机制，进而拐入了 mfc ，随之又牵扯到了 atl ，于是再次与老冤家 com 碰头。感觉个人学习知识，飘忽不定，今天 wtl 呢，明天就 mfc 了，几年的技术学习之路，有一些螺旋式上升的感觉，今天来个倒叙，从最近的 atl 开始谈起。改日再记录个人对 wtl 和 mfc 的体会。

 

com 在我上述提到的一些技术中，对我个人来说是最为博大精深的了，以自己近日对其粗浅的认识，乱侃几句。 com 其难学有多方面原因：

 

1. 预备知识较多：首先要有深厚的 c++ 功底，然后要了解 com 理论， com 对象， com 服务器，著名的 IUnknown ， IDispatch 等接口，了解了这些之后，我们不能使用原始的 com sdk 来开发 com 组件，接下来就要学习 mfc 或 atl 实现的 com 框架， mfc 不是专门服务 com 的，这里不论；诚然利用 atl 可以快速的实现自己 com 组件，然而 alt 库本身的理解，又是一道难关；简单看了几眼《深入解析 atl 》之后的感觉是， atl 为我们实现了一些，我们自己实现 com 组件一些必须实现而实现起来又相似的东西，比如 IUnknown 接口，接口查询，聚合的支持， com 服务器的类工厂， com 服务器的注册，线程模型，以及一些常用的工具类，如智能指针， bstr 等。我们在掌握 atl 为我们所做的工作的基础（这需要我们对 com 原理的理解）上，就可以专心实现我们自己的接口功能了。

 

class ATL_NO_VTABLE CFun :

              public CComObjectRootEx<CComSingleThreadModel>,

              public CComCoClass<CFun, &CLSID_Fun>,

              public IFun

 

利用 atl 生成基本代码结构如上，其中 CComObjectRootEx<CComSingleThreadModel>, 替我们作好了 IUnkown 的工作， CComCoClass<CFun, &CLSID_Fun> 替我们做了产生类厂，注册服务器的工作，而 IFun 是我们自己定义的接口，我们的 CFun 要实现它，最开始接触 atl 的时候，被这个多继承搞糊涂了，直到今天才稍微清晰些，这里的继承有两层含义：

 

1, 继承 atl 库为我们提供的类，享受其给我们提供的服务（ atl 提供给我们的服务远不止这些，一大堆 IxxxImp 名字的类；

2 ，实现我们自己的接口，最终提供给别人使用。

 

好了，这就是自己对于 atl 的泛泛的理解。

 

好，假设你对 atl 有很好的理解，那么你可以掌握 com 了么，还远远不够，还有一道难关要闯 ---ole2 。

 

就是你实现一个 ActiveX 插件，或实现一个包容控件的应用,所需要知道的一切，通过阅读 atl 的源代码也可以看出这一点，随便列几个接口，

 

IViewObject ， IDropSource ， IDropTarget ， IOleObject ， IOleClientSite ， IOleInPlaceObject ， IOleControl ， IOleControlSite...

 

你需要了解以上这些接口的目的，以及它们之间的交互，很好的理解了它们，才能很好的理解 com ，个中原因就需要我们追溯 com 的起源了：

 

OLE 是最早出现的，自从 Windows 操作系统流行以来，“剪贴板”（ Clipboard ）首先解决了不同程序间的通信问题（由剪贴板作为数据交换中心，进行复制、粘贴的操作），但是剪贴板传递的都是“死”数据，应用程序开发者得自行编写、解析数据格式的代码，于是动态数据交换（ Dynamic Data Exchange ， DDE ）的通信协定应运而生，它可以让应用程序之间自动获取彼此的最新数据，但是，解决彼此之间的“数据格式”转换仍然是程序员沉重的负担。对象的链接与嵌入（ Object Linking and Embedded ， OLE ）的诞生把原来应用程序的数据交换提高到“对象交换”，这样程序间不但获得数据也同样获得彼此的应用程序对象，并且可以直接使用彼此的数据内容，其实 OLE 是 Microsoft 的复合文档技术，它的最初版本只是瞄准复合文档，但在后续版本 OLE2 中，导入了 COM 。

 

由此可见， COM 是应 OLE 的需求而诞生的，所以虽然 COM 是 OLE 的基础，但 OLE 的产生却在 COM 之前。 COM 的基本出发点是，让某个软件通过一个通用的机构为另一个软件提供服务。 COM 是应 OLE 的需求而诞生，但它的第一个使用者却是 OLE2 。

 

COM第一个使用者是OLE2 ，所以我们理解 com 标准，最好不过是掌握 ole2 了，然而说来容易，做起来难啊。

 

大家都说 com 难学，自己试以此文剖析了其难学的原因。吾以为更重要的一点原因是，现在已是一个“无网而不胜”的时代，是 java ， .net 的时代，需求为导向，谁还会舍近而求远，退而求其次呢？

 

然而，本着追寻技术之流脉的目的，了解一下也没什么坏处的。

 

也许有一天，和 com 会再次不期而遇，也许是要将日志导入到 excel 这样的小需求，也是是开发一个支持插件的可扩展应用。