Up to this point, we have looked at aggregation guidelines for both the inner and the outer objects. The inner object needs the outer object's IUnknown pointer for use with its delegating IUnknown interface. The outer object needs the inner object's nondelegating IUnknown pointer for interface navigation and to release the aggregated object. The inner and outer COM objects need to exchange IUnknown pointers. That is exactly what the last aggregation guideline states:

Specifically, the inner object gives the outer object its nondelegating IUnknown pointer, receiving the outer object's IUnknown pointer in exchange. This happens when the outer object creates the inner object.

As part of its instantiation process, the outer object creates an instance of the inner object. The inner and outer objects exchange IUnknown pointers at this time. CoCreateInstance and IClassFactory::CreateInstance take a parameter specifically dedicated to supporting aggregation. To aggregate an object, the outer object passes in a pointer to its IUnknown pointer and asks the inner object for its IUnknown pointer.
The aggregated (inner) object's class factory sees a request for aggregation in its implementation of CreateInstance.
Notice how the creation and destruction of the inner objects and the outer object are kept in synch. The outer object creates inner objects when it is created. The outer object will destroy inner objects when it is destroyed (recall from the previous lesson that the outer object releases aggregated objects when it is released). These steps, along with the inner object's delegating IUnknown interfaces and the outer object's uses of the aggregated object's nondelegating IUnknown interface, support the goal of aggregation: multiple objects combining into a composite object.

Click the Exercise link below to apply what you've learned to fixing a buggy inner COM object.
Analyze Inner Com Object - Exercise