我注意到COM上的大量书籍等指出，实现一个可以在COM聚合中用作内部对象的对象相对容易。但是，除非我遗漏了某些内容，否则聚合似乎只能在非常有限的情况下成功，因此只有在特别认可这种情况时才应提供对它的支持。
困扰我的部分如下。 COM聚合将内部对象的标识与外部对象的标识相结合。外部对象的实现者选择内部对象的接口的子集，并将对这些接口的请求转发到内部对象。内部对象将所有接口请求转发给外部对象。现在假设内部对象作为其实现的一部分构造子COM对象。假设接口指针被传递给该COM对象，因此它可以与其父对象通信。内部对象对它实现的接口有一些了解。但是，外部对象可能已选择不转发其中一些接口。实际上，文档指出外部对象不应盲目转发接口。这似乎暗示内部对象通常不能将接口指针移交给其他COM对象，除非特别要求外部对象将所有这些接口转发到内部对象。这不仅限于子对象场景。实际上，内部对象实现通过接口指针的任何地方似乎都会受到影响。
因此，似乎聚合不是通用的，因为 - 在内部对象必须与其他COM对象通信的情况下 - 它对外部对象提出了严格的要求，即哪些接口必须最低限度地转发，而更多的接口不能在内部对象的未来版本中添加到此列表中，而不会破坏与不转发这些接口的现有外部对象的兼容性。
这是一个正确的（并且很少有文件记录）描述事物的实际存在方式或是否有更多的故事？
答案 0 :(得分：4)
发现你的线程在这里萎靡不振，以为我会回应。对于初学者来说，聚合与OOP中的封装相比较，但存在一些显着差异。有趣的是，外部接口需要很少的工作来公开聚合接口。不太好的是，接口需要设计为从一开始就可以聚合，这是OOP封装所不具备的要求。这限制了你有一个COM类放在架子上的可能性，准备好了。从我自己的工作来看，当面对是否支持聚合的问题时，我还没回答“是的，有朝一日可能会有用”。实施授权和非授权IUnknowns的头痛使我“不”。
关于创建对象的内部接口的问题很容易回答。内部接口不应该知道它已经聚合。更重要的是，它无法知道谁汇总了它。因此，它不能知道外部是否对物体有用，或者它是否适当地委托QI。这不是一个真正的问题，它可以简单地将一个接口指针交给它自己的一个接口。聚合不会禁止它。只需要转发未知的接口。
但是，聚合不太实际。
答案 1 :(得分：1)
我实现或实现的每个COM对象都在其create方法中进行了无聚合检查。 MSFT发布的大多数COM对象不支持聚合。