Understand some of the issues encountered when using containment/delegation.
Containment and Delegation Issues in COM
Using containment/delegation, we can reuse any COM object. First, we design the outer COM object with interfaces that mirror one or more interfaces in an inner COM object. Next, we write code in the outer COM object that creates an instance of the inner COM object and, in the mirrored interfaces, delegates calls into the inner COM object.
One issue with using containment/delegation is that we always have to add additional interfaces into the outer object.
If the outer object simply passes calls through to the inner object (that is, the outer object does not filter data or method calls), we incur a development time and performance penalty. We lose time on the development side specifying and implementing pass-through interfaces in the outer COM object. We lose time when the object is running code that simply passes through calls into the inner COM object. The performance problem incurred when using containment/delegation is especially acute when the level of nested containment is deep.
For example, consider a case where object A uses B, object B uses C, and object C uses D:
Notice how calling methods in Interface4 require three pass-through delegation calls in objects A, B, and C.
Is there a way to create a composite COM object without incurring the development and performance overhead depicted in the nested containment/delegation scenario presented above?
Yes. COM's other reusability mechanism which is aggregation, provides a mechanism that allows us to create such an object.