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
- in-process objects and
- 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.