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

我注意到许多关于COM的书籍等都指出，在COM聚合中实现一个可以用作内部对象的对象相对容易。然而，除非我遗漏了一些东西，否则聚合似乎只能在非常有限的场景中成功，因此只有在明确认识到这种场景时才应该提供对聚合的支持

困扰我的部分如下。COM聚合将内部对象的标识与外部对象的标识相结合。外部对象的实现者选择内部对象接口的子集，并将这些接口的请求转发给内部对象。内部对象将所有接口请求转发给外部对象。现在假设内部对象作为其实现的一部分，构造子COM对象。可能会向该COM对象传递一个接口指针，以便它可以与其父对象通信。内部对象对其实现的接口有一些概念。但是，外部对象可能选择不转发其中一些接口。事实上，文档说明外部对象不应该盲目地转发接口。这似乎意味着内部对象通常不能将接口指针交给其他COM对象，除非明确要求外部对象将所有这些接口转发给内部对象。这不限于子对象场景。实际上，内部对象实现传递接口指针的任何地方似乎都会受到影响

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

---

这是对事情实际情况的正确描述（而且很少有文档记录），还是故事中还有其他内容？

发现你的帖子在这里发呆，我想我会回应。首先，聚合与OOP中的封装相比，有一些显著的区别。好的是，在外部接口中只需要很少的工作就可以公开聚合接口。不好的是，接口需要设计成从一开始就可以聚合，这是OOP封装所没有的要求。这就限制了您将COM类放在架子上，随时准备发布的可能性。从我自己的工作来看，当面临是否支持聚合的问题时，我还没有回答“是的，有一天可能会有用”。实施授权和非授权IUnknowns带来的头痛让我觉得“不”

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

---

但是，聚合不是很实用。

我所实现或看到的每个COM对象在其创建方法中都有无聚合检查。MSFT提供的大多数COM对象不支持聚合

>它可以简单地将一个接口指针交给它自己的一个接口。真正地起初我也这么想，但后来意识到我认为它不能正常工作。聚合时，这些接口不包含转发到控制IUnknown的QueryInterface方法吗？因此，如果控制神经不向前向后，气的反射性就会被破坏。这是我关心的潜在问题的症结所在。基于几个小时的研究，（包括），包括一些直接的修整努力，我幼稚的观察是COM聚合似乎是在设计上过于复杂的多个缺口，超出任何人可能认为广泛采用的现实。在我的努力接近尾声时，我越来越困惑于这样一件脆弱的事情是如何从实验室逃走的。问得好。我在搜索COM聚合时遇到很多麻烦。MSDN声明“聚合的实现几乎和包含一样简单……”。我不同意。