代码之家 › 专栏 › 技术社区 › Jason Kresowaty

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

aggregation com

Jason Kresowaty · 技术社区 · 15 年前

我注意到,在COM上有许多书等指出,实现一个可以在COM聚合中用作内部对象的对象相对容易。但是,除非我遗漏了一些东西,否则聚合似乎只能在非常有限的场景中成功,因此只有在特定地识别出这种场景时才应该提供对它的支持。

困扰我的部分如下。COM聚合将内部对象的标识与外部对象的标识组合在一起。外部对象的实现者选择内部对象接口的子集,并将这些接口的请求转发给内部对象。内部对象将接口的所有请求转发到外部对象。现在假设内部对象作为其实现的一部分构造子COM对象。大概有一个接口指针被传递给那个COM对象,这样它就可以和它的父对象通信了。内部对象对它实现的接口有一些概念。然而,外部对象可能选择不转发其中一些接口。事实上,文档说明外部对象不应该盲目地转发接口。这似乎意味着内部对象通常无法将接口指针传递给其他COM对象,除非外部对象被特别要求将所有这些接口转发给内部对象。这不限于子对象场景。实际上,任何内部对象实现传递接口指针的地方似乎都可能受到影响。

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

这是一个正确的(很少记录)描述事情的实际情况,还是有更多的故事?

2 回复 | 直到 15 年前

Hans Passant 15 年前

我以为我会回应你,却发现你的线在这里枯萎。对于初学者来说,聚合与OOP中的封装相比,但是有一些显著的区别。好的是,在外部接口中只需要很少的工作就可以公开一个聚合接口。不好的是,一个接口需要设计成从一开始就可以聚合,而OOP封装没有这样的要求。这限制了你有一个COM类放在架子上,随时可以被借用的可能性。从我自己的工作中,当面对是否支持聚合的问题时,我还没有回答“是的,有一天可能会有用”。执行委派和不委派的工作让我很头疼,所以我选择了“不”。

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

但是的,聚合并不是很实际。

i_am_jorf 15 年前

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