组件对象模型 (COM)一种跨平台的开放结构，用于开发基于面向对象技术的客户端/服务器应用程序。客户端可以通过在对象上实现的接口访问对象。COM 与语言无关，因此任何生成 ActiveX® 组件的语言都可以生成 COM 应用程序。
一部分：您打算解释 COM 吗？以前不是已经有人解释过了吗？ 医生听到您说：“您要干什么？解释 COM？已经有人写了这方面的书！”确实有书了，而且 GUI 医生还可以推荐很多好书。他很喜欢 Dale Rogerson 的 Inside COM (Microsoft Press, 1997) 和 Don Box 的 Essential COM (Addison-Wesley, 1998)。Adam Denning 的 ActiveX Controls Inside Out (Microsoft Press, 1996)，Sing Li 和 Panos Economopoulos 的 Professional Visual C++ 5 ActiveX/COM Control Programming (WROX Press, 1997) 也是好书。当然，您也应该看 Kraig Brockschmidt 的 Inside OLE, 2nd Edition (Microsoft Press, 1995)，这是 OLE 参考的最好印刷品。（当然，MSDN 也是最好的参考，不只是医生这样认为。）另外，如果您想要看客观地解释组件软件的书，请参考 Clemens Szyperski 的新书 Component Software: Beyond Object-Oriented Programming (Addison-Wesley, 1998)。“那又怎么样，”您问到，“GUI 医生还能比这些书说得更好吗？”“根本不会。”医生这样回答。这些作者（和其他作者）再加上文档确实已经全说到了。如果您有时间看这些书，就是这样。“那么您要做的就是，”您叫道，“为我们轻描淡写地介绍一番 COM 和 ATL，而且每周只有一小段！”GUI 医生回敬道：“您很聪明。这样就比我预料的要容易多了。”组件？我是在编写一个立体声系统吗？ 如果您很熟悉 Visual Basic，您就会很熟悉使用组件编写程序：您既使用 visual ActiveX 控件（例如微调按钮），也使用非可视的 ActiveX 组件（例如数据库访问对象）。很难找到一个没有频繁使用预制的可重用组件的重要 Visual Basic 程序。但是，虽然您重用了大量的组件，大多数人并没有为自己编写过完整的可重用组件。如果您使用 C++ 进行编程，那么您对重用会有不同的感受。人们说 C++ 和面向对象编程可以很容易地实现对象重用，但是您的经验怎么样？您编写过可重用对象库吗？无疑少数人确实编写过，但是大部分人并非如此。并且，就算有了这样的一个库，我们能很好地利用它吗？并不只是由于缺乏规则从而使我们难以重用代码；事实是，代码很难重用（代码好象从不按我们需要的方式执行），而编写可重用代码则更难（很难既足够通用又足够实用）。结果是，C++ 并没有使创建可重用二进制组件变得容易，而是使重用源代码变得相对容易。要知道，大多数主要的 C++ 库是以源代码形式发布的，而不是编译后的形式。为了正确地继承一个对象，很有必要查看这些源代码，并且依赖于原库的实现细节来进行重用是很容易的（也是有必要的）。更糟的是，修改源代码并自己连编原库是很诱人的（或是必要的）。（到底有多少自连编的 MFC？谁也不知道 . . . .）那么让我们重用二进制对象，而不是源代码 那么又怎能重用二进制对象呢？Windows 程序员首先想到的答案很简单：使用动态链接库 (DLL)。使用 DLL 确实管用，毕竟 Windows 本身就主要是一组 DLL。但是，还有一些问题。首先，DLL 不是独立于编程语言的。即使是使用 C 语言编写的 DLL，也很容易更改调用约定（按什么顺序将什么参数入栈），从而使该 DLL 只能用在 C 程序中。就算 Windows 使用的调用约定已作为 Windows 系统的标准规定得很完备，但是，医生仍遇到过由于调用约定不匹配而导致的 DLL 失败。为 DLL 编写一个 C 语言的接口有一些重要限制。首先，这限制了您进行面向对象编程，因为，C++ 的面向对象特性需要对函数名进行修饰，名称修饰没有统一的标准。有些情况下，甚至同一编译器的不同版本对名称的修饰也会不同。第二，实现多态性将很困难。通过创建包装类，您可以解决这些问题，但是这样做是痛苦的。GUI 医生没有痛苦过。（起码没有太痛苦过。）即使您解决了名称修饰问题，并进而成功地链接到了 DLL，当更新对象时也会出现其他问题。首先，如果当您更新对象时要向其中添加任何虚函数，那么您就会像浑身插满软管的病人一样动弹不得。您可能会认为在对象的末尾添加新函数不会出问题，但是实际上并非如此：这样会将所有从您的对象派生的对象的虚函数表入口平移。并且，因为调用虚函数需要使用虚函数表中的固定偏移，以便调用正确的函数，所以您不能对虚函数表进行任何更改——至少不重新编译每个有关的程序（这些程序使用您的对象或任何从您的对象派生的对象），就不能进行更改。很明显，每次更新您的对象时都重新编译全世界，不是个好主意。其次，如果您在客户程序中使用 new 来分配对象，那么您要更改该对象的大小（即添加任何数据），就必须重新编译全世界。最后（也是最重要的），更新 DLL 简直就是一场恶梦，因为您处于两难境地，两种选择都很令人倒胃口：要么通过覆盖 DLL 来“就地”更新该 DLL，要么重新命名一个新的版本。就地更新 DLL 很糟糕：即使您保持接口的统一，DLL 的某些用户程序也会被破坏，这样的几率很高。GUI 医生就不必一一告诉您业界（包括 Microsoft 在内）因此问题而遇到的所有麻烦了。另一种方法，即使用一个新的 DLL 名称，至少能让原来正常运转的系统继续正常运转。但是，代价是需要占用硬盘空间（也许当普通的硬盘有 3GB 左右大小时，这不是个大问题），而第二个代价是：增加了内存的使用。如果用户使用了两种版本的 DLL，那么在用户的工作集内就会存在两个代码极其相似的复本。例如，通常，当您检查用户内存的使用情况时，就会发现两三个版本的 Visual Basic 运行时模块或 Microsoft Foundation Class (MFC) DLL。既然几乎所有的 Windows 系统通常都使用比物理内存更多的虚拟内存，增加工作集的大小就意味着严重的性能问题，表现在增加了交换到硬盘上的虚拟内存的大小。（这就为 Brook 定律提供了反例：向一个慢的系统添加更多的内存反而会使它更快。）在理想情况下，您希望能让用户（或应用程序）来选择使用哪个版本。这对于静态链接的 DLL 是极其困难的，但是对动态加载的 DLL 就很容易了。公平地讲，应该指出，C++ 从来也没打算解决这类问题。C++ 的原本用途是在只有一个文件的程序中重用代码，这样所有的对象是同时编译的。C++ 并不打算提供一种建立可重用二进制组件的方法，以便可以混合使用不同版本和时间的组件。顺便说一句，Java 的缔造者注意到了这些问题，这些不足是开发 Oak 的主要原因，Oak 后来变成了 Java。
下面是COM的定义,希望能对你有帮助。 COM (Component Object Model) is Microsoft's framework for developing and supporting program component objects. It is aimed at providing similar capabilities to those defined in CORBA (Common Object Request Broker Architecture), a framework for the interoperation of distributed objects in a network that is supported by other major companies in the computer industry. Whereas Microsoft's OLE provides services for the compound document that users see on their display, COM provides the underlying services of interface negotiation, life cycle management (determining when an object can be removed from a system), licensing, and event services (putting one object into service as the result of an event that has happened to another object). COM includes COM+, DCOM, and ActiveX interfaces and programming tools.
医生听到您说：“您要干什么？解释 COM？已经有人写了这方面的书！”确实有书了，而且 GUI 医生还可以推荐很多好书。他很喜欢 Dale Rogerson 的 Inside COM (Microsoft Press, 1997) 和 Don Box 的 Essential COM (Addison-Wesley, 1998)。Adam Denning 的 ActiveX Controls Inside Out (Microsoft Press, 1996)，Sing Li 和 Panos Economopoulos 的 Professional Visual C++ 5 ActiveX/COM Control Programming (WROX Press, 1997) 也是好书。当然，您也应该看 Kraig Brockschmidt 的 Inside OLE, 2nd Edition (Microsoft Press, 1995)，这是 OLE 参考的最好印刷品。（当然，MSDN 也是最好的参考，不只是医生这样认为。）另外，如果您想要看客观地解释组件软件的书，请参考 Clemens Szyperski 的新书 Component Software: Beyond Object-Oriented Programming (Addison-Wesley, 1998)。“那又怎么样，”您问到，“GUI 医生还能比这些书说得更好吗？”“根本不会。”医生这样回答。这些作者（和其他作者）再加上文档确实已经全说到了。如果您有时间看这些书，就是这样。“那么您要做的就是，”您叫道，“为我们轻描淡写地介绍一番 COM 和 ATL，而且每周只有一小段！”GUI 医生回敬道：“您很聪明。这样就比我预料的要容易多了。”组件？我是在编写一个立体声系统吗？
如果您很熟悉 Visual Basic，您就会很熟悉使用组件编写程序：您既使用 visual ActiveX 控件（例如微调按钮），也使用非可视的 ActiveX 组件（例如数据库访问对象）。很难找到一个没有频繁使用预制的可重用组件的重要 Visual Basic 程序。但是，虽然您重用了大量的组件，大多数人并没有为自己编写过完整的可重用组件。如果您使用 C++ 进行编程，那么您对重用会有不同的感受。人们说 C++ 和面向对象编程可以很容易地实现对象重用，但是您的经验怎么样？您编写过可重用对象库吗？无疑少数人确实编写过，但是大部分人并非如此。并且，就算有了这样的一个库，我们能很好地利用它吗？并不只是由于缺乏规则从而使我们难以重用代码；事实是，代码很难重用（代码好象从不按我们需要的方式执行），而编写可重用代码则更难（很难既足够通用又足够实用）。结果是，C++ 并没有使创建可重用二进制组件变得容易，而是使重用源代码变得相对容易。要知道，大多数主要的 C++ 库是以源代码形式发布的，而不是编译后的形式。为了正确地继承一个对象，很有必要查看这些源代码，并且依赖于原库的实现细节来进行重用是很容易的（也是有必要的）。更糟的是，修改源代码并自己连编原库是很诱人的（或是必要的）。（到底有多少自连编的 MFC？谁也不知道 . . . .）那么让我们重用二进制对象，而不是源代码
那么又怎能重用二进制对象呢？Windows 程序员首先想到的答案很简单：使用动态链接库 (DLL)。使用 DLL 确实管用，毕竟 Windows 本身就主要是一组 DLL。但是，还有一些问题。首先，DLL 不是独立于编程语言的。即使是使用 C 语言编写的 DLL，也很容易更改调用约定（按什么顺序将什么参数入栈），从而使该 DLL 只能用在 C 程序中。就算 Windows 使用的调用约定已作为 Windows 系统的标准规定得很完备，但是，医生仍遇到过由于调用约定不匹配而导致的 DLL 失败。为 DLL 编写一个 C 语言的接口有一些重要限制。首先，这限制了您进行面向对象编程，因为，C++ 的面向对象特性需要对函数名进行修饰，名称修饰没有统一的标准。有些情况下，甚至同一编译器的不同版本对名称的修饰也会不同。第二，实现多态性将很困难。通过创建包装类，您可以解决这些问题，但是这样做是痛苦的。GUI 医生没有痛苦过。（起码没有太痛苦过。）即使您解决了名称修饰问题，并进而成功地链接到了 DLL，当更新对象时也会出现其他问题。首先，如果当您更新对象时要向其中添加任何虚函数，那么您就会像浑身插满软管的病人一样动弹不得。您可能会认为在对象的末尾添加新函数不会出问题，但是实际上并非如此：这样会将所有从您的对象派生的对象的虚函数表入口平移。并且，因为调用虚函数需要使用虚函数表中的固定偏移，以便调用正确的函数，所以您不能对虚函数表进行任何更改——至少不重新编译每个有关的程序（这些程序使用您的对象或任何从您的对象派生的对象），就不能进行更改。很明显，每次更新您的对象时都重新编译全世界，不是个好主意。其次，如果您在客户程序中使用 new 来分配对象，那么您要更改该对象的大小（即添加任何数据），就必须重新编译全世界。最后（也是最重要的），更新 DLL 简直就是一场恶梦，因为您处于两难境地，两种选择都很令人倒胃口：要么通过覆盖 DLL 来“就地”更新该 DLL，要么重新命名一个新的版本。就地更新 DLL 很糟糕：即使您保持接口的统一，DLL 的某些用户程序也会被破坏，这样的几率很高。GUI 医生就不必一一告诉您业界（包括 Microsoft 在内）因此问题而遇到的所有麻烦了。另一种方法，即使用一个新的 DLL 名称，至少能让原来正常运转的系统继续正常运转。但是，代价是需要占用硬盘空间（也许当普通的硬盘有 3GB 左右大小时，这不是个大问题），而第二个代价是：增加了内存的使用。如果用户使用了两种版本的 DLL，那么在用户的工作集内就会存在两个代码极其相似的复本。例如，通常，当您检查用户内存的使用情况时，就会发现两三个版本的 Visual Basic 运行时模块或 Microsoft Foundation Class (MFC) DLL。既然几乎所有的 Windows 系统通常都使用比物理内存更多的虚拟内存，增加工作集的大小就意味着严重的性能问题，表现在增加了交换到硬盘上的虚拟内存的大小。（这就为 Brook 定律提供了反例：向一个慢的系统添加更多的内存反而会使它更快。）在理想情况下，您希望能让用户（或应用程序）来选择使用哪个版本。这对于静态链接的 DLL 是极其困难的，但是对动态加载的 DLL 就很容易了。公平地讲，应该指出，C++ 从来也没打算解决这类问题。C++ 的原本用途是在只有一个文件的程序中重用代码，这样所有的对象是同时编译的。C++ 并不打算提供一种建立可重用二进制组件的方法，以便可以混合使用不同版本和时间的组件。顺便说一句，Java 的缔造者注意到了这些问题，这些不足是开发 Oak 的主要原因，Oak 后来变成了 Java。
COM (Component Object Model) is Microsoft's framework for developing and
supporting program component objects. It is aimed at providing similar
capabilities to those defined in CORBA (Common Object Request Broker
Architecture), a framework for the interoperation of distributed objects in a
network that is supported by other major companies in the computer industry.
Whereas Microsoft's OLE provides services for the compound document that
users see on their display, COM provides the underlying services of interface
negotiation, life cycle management (determining when an object can be removed
from a system), licensing, and event services (putting one object into
service as the result of an event that has happened to another object).
COM includes COM+, DCOM, and ActiveX interfaces and programming tools.