转一篇com的文章

面向对象的思想难以适应这种分布式软件模型，于是组件化程序设计思想得到了迅速的发展。
按照组件化的程序设计的思想，复杂的应用程序被设计成一些小的，功能单一的组件模块，这些组件模块可以运行在同一台机器上，也可以运行在不同的机器
上。
为了实现这样的应用软件，组建程序和组建程序之间需要一些极为细致的规范， 只有组件程序遵守了这些共同的规范，然间系统才能正常运行。
为此，OMG和Microsoft分别提出了CORBA(Common Object Request Breaker
Architecture)和COM(Component Object
model)标准，目前CORBA模型主要应用于UNIX操作系统平台上，而COM 则主要应用于Microsoft Windows操作系统平台上。 
在COM标准中，一个组件程序也被称为一个模块，它可以是一个动态连接库(DLL), 被称为进程内组件(in-of-process
component)也可以是一个可执行程序(EXE)，被称为进程外组件(out-of-process component). 
COM对象是建立在二进制可执行代码级的基础上，而C++等语言中的对象是建立在源代码级基础上的，因此COM对象是语言无关的。这一特性
使用不同编程语言开发的组件对象进行交互成为可能。
在Microsoft
Windows系统平台上，COM技术被应用于系统的各个层次，从底层的COM对象管理到上层的应用程序交互都用到了COM标准。 
概述

COM既提出了组件之间进行交互的规范，也提供了实现交互的环境，
因为组件对象之间交互的规范不依赖于任何特定的语言，所以COM也可以是不同语言协作开发的一种标准。
OLE技术以COM规范为基础，OLE充分发挥了COM标准的优势，使Windows操作系统上的应用程序具有极强的可交互性。如果没有
OLE的支持，Windows操作系统则会逊色很多。 
但是，COM规范并不局限于OLE技术，实际上，OLE技术只是COM的一个应用而已，这几年，OLE技术在进行网络互连是显示出了很大的
局限性，而COM则表现出了极强的适应能力。
COM标准包括规范和实现两大部分，规范部分定义了组件和组件之间通信的机制，这些规范不依赖于任何特定的语言和操作系统，只要按照该规
范，任何语言都可以使用; COM标准的实现部分是COM库，COM库为COM规范的具体实现提供了一些核心服务。 
COM是面对对象的软件模型，因而对象是他的基本要素之一。类似于C++中对象的概念，对象是某个类(class)的一个实例;而类则是一
组相关的数据和功能组和在一起的一个定义。使用对象的应用(或另一个对象)成为客户，有时也成为对象的用户。 
接口是一组逻辑上相关的函数集合，其函数也被称为接口成员函数。对象通过接口成员函数为客户提供各种形式的服务。 
在COM模型中，对象本身对于客户来说是不可见的，客户请求服务时，只能通过接口进行。每一个接口都由一个128位的全局唯一标识符
(GUID,Globally Unique
Identifier)来标识。客户通过GUID获得接口的指针，在通过接口指针，客户就可以调用其相应的成员函数。 
一般来说，接口是不变的，只要客户期望的接口在组建对象中还存在，它就可以继续使用该接口所提供的服务。对象可以支持多个接口，因此对组件
对象的升级可通过增加接口的办法实现，这样得到的新接口可以不影响老接口的使用。 
客户如何来标识COM对象呢？与接口类似，每个对象也用一个128位GUID来标识，称为CLSID(class
identifier,类标识符或类ID)，用CLSID标识对象可以保证(概率意义上)在全球范围内的唯一性。

只要系统中含有这类COM对象的信息，并包括COM对象所在的模块文件(DLL或EXE文件)以及COM对象在代码中的入口点，客户程序就
可以由此CLSID来创建COM对象。 
那么客户怎么使用COM对象所提供的服务呢？客户获得的又是什么呢？
实际上，客户成功创建对象后，它得到的是一个指向对象某个接口的指针，因为COM对象至少实现一个接口，所以客户就可以调用该接口提供的所有服务。

但是COM对象可以有自己的状态，正是这种状态才使客户感觉到COM对象的存在。如果客户同时拥有两个相同CLSID的对象，则两个对象可
以有不同的状态，客户完全不必关心COM对象是怎么实现的，以及两个对象的状态数据之间有什么关系(数组或者链表)。当然，COM对象也可以是无状态的，
这种COM对象以提供功能服务为主，可以用来代替传统的API函数接口，使得应用程序编程接口更为有序，组织层次性更强。 
COM本身除了规范之外，也有实现的部分，其中包括一些核心的系统级代码，也正是这部分核心代码，才使得对象和客户之间可通过接口在二进制
代码级进行交互 。
在Microsoft Windows操作系统环境下，这些库以.dll文件的形势存在，其中包括以下内容:
(1) 提供了少量的API函数实现客户和服务端COM应用的创建过程。在客户端，主要是一些创建函数;而在服务器端，提供一些对象的访问支持。
(2) COM通过注册表查找本地服务器即EXE程序，以及程序名与CLSID的转换等。
(3) 提供了一些标准的内存控制方法，使应用控制进程中内存的分配。

COM库一般不在应用程序层实现，而在操作系统层次上实现，因此一个操作系统只有一个COM库实现。而且COM库的实现必须依赖于具体的系统平台，
尤其是系统底层的一些标准。
COM库可以保证所有的组件按照统一的方式进行交互操作，而且它使我们在编写COM应用时，可以不用编写为进行COM通信而必需的大量基础代码，而
是直接利用COM库提供的API进行编程，从而大大加快了开发的速度。例如，现在COM库的版本都支持远程组件即分布式COM，我们不用编写任何网络或者
RPC(remote procedure call)的代码，就可以实现在网络上进行程序之间的通信。 
如果我们用面向对象语言来实现COM对象，则很自然可以用类类定义对象。在C语言中，对象的概念可能变成一个逻辑概念，如果两个对象同时存
在，则在接口实现中必须明确知道所进行的操作是针对哪个对象的，这个过程可由COM接口的定义保证。
COM规范使用GUID来标识COM对象的思想源于OSF(Open Software
Foundation)采用的UUID(Universallz Unique Identifier),
UUID被定义为DCE(Distributed Computing Environment)的一部分，主要用于表识RPC通信的双方。
除了封装性和重用性，C++对象还有一个重要特性是多态性。正是C++对象的多态性，才体现了C++语言用类描述事物的高度抽象的特
征;COM对象也
具有多态性，但这种多态性需要通过COM对象所具有的接口才能体现出来，就像C++对象的多态性需要通过其(virtual)函数才能体现一样。 
从API到COM接口
假如我们要实现一个字处理应用系统，它需要一个查字典的功能，按照组件化程序设计的方法，自然应该把查字典的功能放到一个组件(.dll)程序中实
现。如果以后字典程序的查找算法或者字典库改变了，只要应用程序和组件之间的接口不变，则新的组件程序仍然可以被应用系统使用。这就是采用组件程序带来的
灵活性。 
为了把应用系统和组件程序连接起来，又能使它们协同工作，最简单的做法就是先定义一组查字典的函数，而且这组函数尽可能一般化，不要加入特
定的与字典库相关的知识。