COM Aggregation Review

Before jumping into the technical details of aggregation, let us step back and summarize aggregation:

1. Aggregation supports a composition of objects where the outer object appears to implement the inner object's interfaces. The collection of aggregated objects and the outer object act as one COM object.
2. Aggregated objects (inner objects) directly expose their interfaces. Unlike containment/delegation, there is no intermediate interface in the outer object that stands between the client and the inner object's interface.
3. Even though an aggregated/inner object's interfaces are directly exposed to the client, the client is not aware of the aggregated (inner) objects.
4. Aggregation scenarios can be multilevel. For example, in the example presented in the previous module, the client uses FileManager. FileManager aggregates the FindFile, ReadWriteFile, and ArchiveFile components. The FindFile component aggregates LocalFindFile and RemoteFindFile.

There are times when an object's implementor would like to take advantage of the services offered by another, prebuilt object. In addition, it would like this second object to appear as a natural part of the first. COM achieves both of these goals through containment and aggregation. Aggregation means that the containing (outer) object creates the contained (inner) object as part of its creation process and the interfaces of the inner object are exposed by the outer. An object allows itself to be aggregatable or not. If it is, then it must follow certain rules for aggregation to work properly. Namely, all IUnknown method calls on the contained object must delegate to the containing object.

A problem related to implementation inheritance is the issue of a single programming model for

1. in-process objects and
2. out-of-process/cross-network objects.

In the former case, class library technology (or application frameworks) permits only the use of features or objects that are in a single address. Such technology is far from permitting use of code outside the process space let alone code running on another machine altogether. In other words, a programmer cannot subclass a remote object to reuse its implementation. Similarly, features like public data items in classes that can be freely manipulated by other objects within a single address space do not work across process or network boundaries. In contrast, COM has a single interface-based binding model and has been carefully designed to minimize differences between the in-process and out-of-process programming model. Any client can work with any object anywhere else on the machine or network, and because the object reusability mechanisms of containment and aggregation maintain a client/server relationship between objects, reusability is also possible across process and network boundaries.