5

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

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

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

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

4

2 回答 2

5

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

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

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

于 2009-04-22T17:57:43.433 回答
1

我曾经实现或看到实现的每一个 COM 对象都在它的 create 方法中进行了非聚合检查。MSFT 提供的大多数 COM 对象不支持聚合。

于 2009-04-22T18:03:27.757 回答