Lesson 1

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:

1. Explain what aggregation does.
2. Describe how interface navigation and reference counting work under aggregation.
3. Understand the guidelines for inner and outer objects under aggregation

The following information is of historical importance when considering Microsoft Middleware Technologies.

A component is a reusable piece of software in binary form (as opposed to source code) that can be plugged into other components from other vendors with relatively little effort. Microsoft developed COM, a specification of how to build components that can be dynamically interchanged, a standard that 1) components and 2) clients follow to ensure that they can operate together. COM was very efficient, yet extremely flexible and provided mechanisms for creating and controlling objects from scripting languages such as VBScript. COM made it possible for applications from one vendor to activate itself inside the user interface of another vendor's application. It facilitated communication between components in different address spaces and threading models, and it took the pain out of distributing objects across networks. COM is a binary standard, and as such, it is not limited to only one programming language.
COM components can be implemented in several different languages, including (but not limited to) C/C++, Visual Basic, Delphi and Java. COM conforms well to the object-oriented paradigm. In addition, COM enforces use of the two principles of reusable object-oriented design presented by the Gang of Four:

1. Program to an interface, not to an implementation and
2. Favor object composition over class inheritance.

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:

1. 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.
2. 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,

1. containment and
2. aggregation (or a mix thereof),

to choose from for code reuse.