| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Interface

The interface defines the class, one or more methods that can be invoked on a class, as well as the parameters for the method. Client processes invoke classes via interfaces.

For example:

Figure 3.2 Example of an Interface

Every interface has a name (which by convention usually begins with I). The name is used in the program source code, but internally, all interfaces have identifiers based on the GUID. Interfaces are described using Microsoft’s Interface Definition Language (IDL). More details of this are provided in Chapter Five.

Unlike CORBA, a class can have more than one interface. Each of the interfaces describes only that class, but each interface can describe a sort of view of the class’s methods and parameters.

All interfaces are “strongly typed” which means that once they have been implemented they cannot be changed. (Microsoft uses the term “immutable.”) They obtain an identifier and a name, and once the GUID has been allocated the contents must remain fixed.

If used correctly, clients see only the methods they use in an interface. We can see that this approach is exactly the same principle as that used by DBMSs when they use “sub-schemas” and “views.” So what happens if the class is enhanced to support more methods or the operation of an existing method is changed?

Figure 3.3 Interfaces

Where new methods are added, a new interface to the class is added. By doing this any existing client using the class can continue using the existing interface without needing any change to its code, but new clients that use the new methods can be added.

Figure 3.4 New clients can be added without affecting other existing clients

Where the existing method of the class is altered, the developer must see which interfaces are affected and then find all the clients that use these interfaces to see if they still operate correctly. These sorts of changes may result in recompilation of classes and clients with the new interface.

Thus, new methods may not affect a client, as it can be shielded from change by the creation of new interfaces. But changes to an existing method (new parameters, new error messages) may well result in both a new interface or even interfaces and change to all the clients.

The purpose of this approach is thus fairly clear—to provide a form of version control and to protect clients from some types of change. But the class developer has to ensure he keeps all these interfaces in step, and he also needs to know which clients are using which interfaces if there is a change.

### Polymorphism and Encapsulation

Microsoft states that all interfaces are polymorphic in DCOM and also support encapsulation. Polymorphism describes the ability to have a single statement invoke different function implementations at different times. As such, COM interfaces are polymorphic because the developer can replace the methods/functions in the class over time but still keep the same interface.

Similarly, the interface encapsulates the behavior.

Figure 3.5 Methods can be replaced over time, but the interface can stay the same

### Inheritance

The word inheritance in object-oriented programming is usually used to mean that one “object” inherits from another object. Thus a little red widget, for example, may inherit its actual code (methods) from a perhaps more general object called the widget.

This is inheritance of the code itself and is designed to help save effort when programming. The programmer writes a general purpose object, then gradually specializes it with inherited objects each with their own special methods, until a hierarchy of objects results. The main widget, for example, may depress when clicked by the mouse (method “depress”), but the little red widget may turn red when clicked and also emit a sound such as a piercing shriek (methods, “turn red” and “emit piercing shriek”).

This approach has obvious advantages, but it is a problem to control. If one programmer decides to change the base object, all the other objects will be changed automatically even if their programmers didn’t want them to be. If the widget designer added a method to emit a beep when the widget was pressed, the little red widget would not only emit a piercing shriek but a beep as well!

If object inheritance is used you need a really good change and version control system to keep things under control. Microsoft believes that this approach to inheritance is perhaps too risky and thus decided that they would not support object (in their case class) inheritance.

Instead, they recommend that to achieve similar results without the possible side effects, the best approach may be to copy the class and rename it, adding to it or adapting it as necessary, or alternatively use the base class and simply invoke other extra classes if additional functionality is needed. This latter approach provides similar effects to inheritance, but uses the concepts of containment and aggregation (more in a few paragraphs).

Although class inheritance is not supported, Microsoft does support interface inheritance. Interface inheritance is only applied to reuse the definition of the base interface. The programmer may start from one base interface, then add a new one with new methods which is, in effect, inherited from the base one. If one interface inherits from another, it includes all the functions that the other interface defines.

All interfaces, however, inherit directly from IUnknown (of which more later).

### Interface Containment and Aggregation

A class can delegate some of its functionality to other classes.

Where the interface to the calling class describes only its methods, not those of its called/delegated classes, the COM model refers to this as containment.

Where the class actually exposes some of the functionality of the called objects in its interface, COM refers to this as aggregation.

Figure 3.6 Containment

Figure 3.7 Aggregation

Previous | Table of Contents | Next