In this module we will study aggregation. Aggregation is COM's reuse mechanism that fulfills the true definition of object reuse. In an aggregation scenario multiple COM objects compose themselves into one larger,
more functional COM object. Typically, one COM object, an outer COM object, aggregates one or more inner COM objects to expose interfaces implemented in the inner COM objects. Unlike containment/delegation where the outer COM object mirrors interfaces in the inner COM object - the interfaces of inner COM objects appear to be part of outer COM object.
As you go through this module - do not worry if aggregation seems difficult to grasp the first time you study it.
When looking at the various guidelines keep in mind the following points:
- The reason we are using aggregation is to build a more functional COM object that implements the interfaces of the outer COM object and all of the inner COM object's interfaces.
- The development guidelines for aggregation support multiple COM objects combining their functionality in such a way that they act as if they are one COM object.
COM does not support implementation inheritance because implementation inheritance binds one object closely to another object.
If the implementation of a base object changes the derived objects break and must be changed too. The same Gang of Four mentioned earlier also tells us to favor object composition over class inheritance.
By not supporting implementation inheritance, COM enforces this design principle as well.
COM developers have two flavors of object composition,
- containment and
- aggregation (or a mix thereof),
to choose from for code reuse.