COM aggregation is not supported by most objects?

Question

I noticed that numerous books, etc. COM indicates that it is relatively easy to implement an object that can be used as an internal object in COM aggregation. However, if I am missing something, it seems that aggregation can only be successful in extremely limited scenarios, and therefore support for it should only be provided when such a scenario is definitely recognized.

The part that bothers me is this. COM aggregation combines the identifier of an internal object and an external object. The developer of the external object selects a subset of the interfaces of the internal objects and forwards requests for these interfaces to the internal object. The internal object forwards all requests for interfaces to the external object. Now suppose that an internal object, as part of its implementation, constructs child COM objects. Presumably, the interface pointer is passed to this COM object so that it can communicate with its parent. An internal object has some idea of ​​the interfaces that it implements. However, the external entity may have decided not to forward some of these interfaces. In fact, the documentation states that an external entity should not blindly forward interfaces. This, apparently, means that the internal object often cannot pass interface pointers to other COM objects, unless the external object is required to forward all of these interfaces to the internal object. This is not limited to the script of child objects. Indeed, at any place where the implementation of an internal object passes an interface pointer, it looks like they might be affected.

So, it seems that aggregation is not a common goal, because - in cases where the internal object must interact with other COM objects - it makes strict demands on the external object as to which interfaces should be minimally redirected and no more interfaces can be added to this list in future versions of the internal object without compromising compatibility with existing external objects that do not forward these interfaces.

Is this a correct (and rarely documented) description of how things actually exist or are there more in history?

Answer 1

Found your thread, thinking that I will answer. First, aggregation is compared to encapsulation in OOP, but with some significant differences. It's nice that a little work is required in the external interface to expose the aggregated interface. What's bad is that the interface has to be designed to be aggregable using get-go, a requirement that is not in OOP encapsulation. This limits the chances when you have a COM class lying on a shelf ready to rush. From my own work, when I come across the question of whether to support aggregation or not, I still need to answer "yes, maybe someday it will be useful." Headaches from the implementation of delegating and non-delegating IUnknowns led me to no.

The question of the internal interfaces that create the objects is easy to answer. The internal interface does not need to know that it has been aggregated. Moreover, he cannot know who generalized it. Thus, he cannot know if the external object is really useful for the object or if it properly delegates QI. Not a real problem, it can just pass it an interface pointer to one of its own interfaces. Aggregation does not prohibit it. Only unknown interfaces need to be redirected.

But yes, aggregation is not very practical.

Answer 2

Every single COM object that I have ever implemented or seen implemented has a check for lack of aggregation in the create method. Most MSFT ship COM objects do not support aggregation.