com - 大多数对象不支持 COM 聚合吗？

Question

我注意到许多关于 COM 的书籍等都指出，在 COM 聚合中实现一个可用作内部对象的对象相对容易。但是，除非我遗漏了什么，否则聚合似乎只能在极其有限的场景中成功，因此只有在明确识别出这种场景时才应提供对它的支持。

困扰我的部分如下。 COM 聚合将内部对象的身份与外部对象的身份相结合。外部对象的实现者选择内部对象接口(interface)的子集，并将这些接口(interface)的请求转发给内部对象。内部对象将所有接口(interface)请求转发给外部对象。现在假设内部对象，作为其实现的一部分，构造子 COM 对象。大概一个接口(interface)指针被传递给该 COM 对象，以便它可以与其父对象通信。内部对象对它实现的接口(interface)有一些想法。然而，外部对象可能选择不转发其中一些接口(interface)。实际上，文档指出外部对象不应盲目转发接口(interface)。这似乎意味着内部对象通常不能将接口(interface)指针传递给其他 COM 对象，除非特别要求外部对象将所有这些接口(interface)转发给内部对象。这不限于子对象方案。实际上，内部对象实现传递接口(interface)指针的任何地方似乎都可能受到影响。

因此，聚合似乎不是通用目的，因为在内部对象必须与其他 COM 对象通信的情况下，它对外部对象提出了严格的要求，即必须最少转发哪些接口(interface)，并且不能添加更多接口(interface)。此列表在内部对象的 future 版本中不会破坏与不转发这些接口(interface)的现有外部对象的兼容性。

这是对事物实际情况的正确(并且很少记录)描述还是故事还有更多内容？

Answer 1

发现你的线程在这里萎靡不振，以为我会回应。对于初学者来说，聚合与 OOP 中的封装相比，但有一些显着差异。好的是在外部接口(interface)中需要很少的工作来公开聚合接口(interface)。不好的是，接口(interface)需要从一开始就设计为可聚合的，而 OOP 封装没有这种要求。这限制了您将 COM 类放在架子上的可能性，准备好了。从我自己的工作来看，当面临是否支持聚合的问题时，我还没有回答“是的，有一天可能会有用”。实现委托(delegate)和非委托(delegate)的 IUnknowns 让我感到头疼，这让我选择了“不”。

您关于创建对象的内部接口(interface)的问题很容易回答。内部接口(interface)不应该知道它已聚合。更重要的是，它不知道是谁聚合的。因此，它无法知道外部是否对对象有用，或者它是否会正确委托(delegate) QI。这不是一个真正的问题，它可以简单地将接口(interface)指针传递给它自己的接口(interface)之一。聚合并不禁止它。只需要转发未知接口(interface)。

但是，是的，聚合不是很实用。