In a containment/delegation reuse scenario, the outer COM object (OuterCOMObj) establishes a client relationship with the inner COM object (InnerCOMObj). The outer COM object implements COM client code (for example, CoCreateInstance) to create an instance of the inner COM object, and obtains an interface pointer into one or more interfaces in the inner COM object. This sets up the containment relationship.

Additionally, the outer COM object delegates calls from some of its methods to methods in the inner COM object. For example, assume the inner COM object implements interface IX1 with methods x1 and x2. The outer COM object can also expose interface IX1. Because COM interfaces are immutable, the outer COM object's IX1 interface must implement the same methods as the inner COM object's IX1 interface.
As calls come into x1 and x2 in interface IX1 in OuterCOMObj, OuterCOMObj calls into InnerCOMObj's IX1::x1 and IX1::x2.
The following diagram depicts the containment/delegation relationship between OuterCOMObj and InnerCOMObj.

From InnerCOMObj's perspective, OuterCOMObj is simply a COM client. InnerCOMObj has no idea that it is being reused. From the client's perspective, OuterCOMObj appears to implement IX1. The client cannot see InnerCOMObj. The outer COM object normally creates the inner COM object as part of its instantiation sequence. The outer COM object is responsible for the lifetime management of the inner COM object. This means that the outer COM object must properly release all interface pointers it has into the inner COM object. This is normally done as part of the outer object's termination sequence.
Neither the client nor the inner COM object is aware of the containment/delegation.

Click the Exercise link below to apply what you've learned about containment/delegation.
Delegation Code - Exercise