再次叩问让我屡次碰得头破血流的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这样的小需求,也是是开发一个支持插件的可扩展应用。
本文转自 xchsp 51CTO博客,原文链接:http://blog.51cto.com/freebird/184567,如需转载请自行联系原作者