Windows COM背后的动机

我正在努力学习COM
我想我大致了解了COM的体系结构，
但我觉得我没有完全理解它背后的动机

维基百科说：

对于编写良好的组件，COM允许在不了解其内部实现的情况下重用对象，因为它迫使组件实现者提供与实现分离的定义良好的接口。

我的问题是：当我创建一些.dll文件时，
此dll的客户端也不公开于实现，
只有界面，意思，他可以使用什么功能和他们的签名

如果有人能向我解释一下COM背后的动机，我会很高兴的
它解决了什么问题

它解决了什么问题

当然。这可能比你要求的要多，但这一直是我想写一篇博客文章的主题

组件对象模式COM有一些优点。它还因为多年的边缘文档、实现的复杂性和开发人员的挫败感而饱受诟病

COM本质上是一组设计模式：

• 在其核心，它鼓励使用（仅使用纯虚拟方法的C++类）进行设计

• 参考计数。当引用计数在当时被引入C/C++开发人员时，它类似于古罗马人了解数字0

• 鼓励

• 这是一个应用程序的实现

• 它可以用作本地和远程的面向对象抽象 过程调用（也称为“进程外COM”和“DCOM”）

• 显式链接的位置透明度。应用程序不一定需要知道特定代码模块（DLL）在磁盘上的“位置”，就可以从中实例化对象

• 执行和语言透明度。COM对象的调用代码和该对象的实现不需要用相同的语言编写

它的功能：

• 对于本机C++开发，它是实例化一个在DLL中实现的具体C++类的一种非常有效的方法，但是它作为纯虚拟方法的抽象基类返回。它使您（开发者）能够在代码中从我的DLL中消费我的C++类，而不必包含一堆杂乱的实现特定的头文件。我可以给你一个简单的头文件，它不显示我的类和COM GUID的任何成员变量。然后，您只需使用类id和接口id调用CoCreateInstance。我还可以完全重新编写DLL，以及完全不同的类的具体实现——但只要我公开相同的接口，它就不会破坏您的使用

• 不同的跨语言场景。托管C++代码调用到本机C++代码中。或将对象投影到脚本语言环境的本机代码

• 插件模型。假设您的应用程序是照片渲染器，您希望支持第三方代码，以便能够与您的应用程序集成，在工具栏上添加一个按钮，并具有执行某些图像处理的代码。通过标准化接口，例如：

  class ImageProcessor : public IUnknown
  {
  public:
       void ApplyEffect(BitmapData* pBitmap) = 0;
  };
  

  供应商只需提供使用COM（注册表项）注册的新DLL，并在应用程序中注册其COM类guid

• 在进程（本地过程调用）之间进行跨进程通信（在C++中）的一种明智方法

• 微软在允许高级语言（C#和Javascript）使用用低级语言（C++）编写的COM对象方面做了大量工作

难以使用的地方：

• GUID+注册表是一个设计错误。（好了，我说了，来吧，兄弟！）

• 进程外COM调用本来应该是一种异步调用模式，但COM默认使其同步

• 将COM对象注册添加到应用程序设置是一件繁琐的事情

• 微软的IDL文件格式是非标准的，MIDL工具使用起来并不有趣，文档也很简洁

• “编组”和代理/存根DLL。这通常是一本书的一整章。现在，有一些标准的封送员可以帮助消除混乱

>P>大量的开销以获得从DLL导出的基本C++对象。在某些情况下，更容易坚持基于和IUnkown的实现，但只需从DLL中导出自己的工厂函数，而不是通过CoCreateInstance加载它。ATL模板类使这更容易
• 进程外的线程模型。我站在篱笆上。他们选择了一个比“公寓”更糟糕的比喻，将线程模型引入COM。大多数书在解释STA和MTA之间的差异方面做得很糟糕。但是，一旦你了解了这些差异并阅读了足够多的雷蒙德·陈的博客文章，你就能真正欣赏它，并知道如何利用它进行设计。我只花了20年的时间就明白了这一点

• Out-of-proc COM调用pump窗口消息，并在应用程序中引入意外错误。这就是为什么进程内COM对象和进程外COM对象之间的位置透明性在某种程度上是一个神话的原因之一

---

微软使用C++作为它们的库，一种众所周知的互操作性较差的语言。然而，他们希望使这些库不仅用于另一个C++编译器实现，而且可以用于任何语言。COM确定了实现这一目标所需的最低规则。没有异常、没有实现继承、标准调用约定、定义良好的字符串和数组类型以及线程模型。这是有成本的，很少有程序员喜欢使用它，尤其是