再次叩问让我屡次碰得头破血流的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，如需转载请自行联系原作者
