COM Aggregation Introduction
In the previous module, we discussed reusability in a general context with software components. We also examined how to reuse COM (Component Object Model) objects with containment/delegation. In this module, we will continue our exploration of COM's reusability mechanisms by studying aggregation.
Reusing COM objects via aggregation requires some additional coding in inner COM objects, but does not require the outer COM object to mirror interfaces implemented in the inner COM object. The inner COM object is fully aware that it is being reused and its interfaces are exposed directly to the client. The client is not aware of aggregated COM objects. The client thinks the outer COM object implements all accessible interfaces. At the end of this module, you will be able to:
- Explain what aggregation does.
- Describe how interface navigation and reference counting work under aggregation.
- Understand the guidelines for inner and outer objects under aggregation
The following information is of historical importance when considering Microsoft Middleware Technologies.
COM Reuse Mechanism
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.
Inside Microsoft Programming