FAQ 34.18 How are interfaces versioned?

This is one of the more straightforward elements of COM YOU CAN'T.

Interface versioning refers to the COM conventions for changing and modifying interfaces. COM's rule for versioning interfaces is simple: interfaces cannot be versioned; a modified interface is a new interface with a new and unique IID.

In this context, modifying an interface includes any change to the interface's specification, including adding or removing methods, adding or removing parameters, or changing the contract for a method (even if none of its parameters change). At the same time, the rule does not prevent multiple implementations for the same interface, as long as all the implementations satisfy the interface's contract.

The reasoning behind the rule regarding versioning interfaces is to maintain backward compatibility and guarantee that there are no conflicts between existing interfaces and new interfaces. The rule makes a lot of sense since it allows callers to program to a well-defined interface knowing that the interface will never change.

The fact that COM interfaces can't be versioned is really no different from the current situation with C++ class libraries, except that it is presented in a slightly different way. Suppose a system defines a COM interface called IDate for handling date-related information. Later the interface is modified, producing IDate2. Also suppose that there is a C++ class library that has a Date class and people write programs using the Date class. Now the vendor of the class library releases a new and improved C++ class library (version 2) with a Date class with a modified interface. Under these circumstances, what are the trade-offs between the C++ approach and the COM approach?

First, suppose the new version of Date simply adds methods so that it is completely substitutable with the earlier version. In the case of COM, existing callers continue to use IDate and new callers can choose between IDate and IDate2. In the case of the C++ class library, existing callers and new callers simply use version 2 of class Date. Easy.

Second, suppose the new version of Date is not completely backward compatible with the older version. In the case of COM, existing callers continue to use IDate and new callers can choose between IDate and IDate2. We might also decide to review some of the existing caller code and revise it to use IDate2. The choices are almost the same for the caller code using the C++ class library. Existing callers continue to use class Date Version One and new callers can choose between class Date Version One and class Date Version Two. We might also decide to review some of the existing caller code and revise it to use class Date Version Two (instead of class Date Version One).

In some ways, the COM approach is better. If one subsystem of a program uses the COM interface IDate and another subsystem of a program uses the COM interface IDate2, no incompatibilities occur when the subsystems are linked together. In contrast, if the two subsystems use different and incompatible versions of the C++ class Date, linking the two subsystems probably will create some conflicts. Typically this sort of problem forces the users of the C++ class library to choose between the two incompatible versions of the Date class, which may require one of the subsystems to be updated.

In the case of COM the two interfaces are distinguished using 128-bit IIDs, and in the case of C++ the two interfaces need to be distinguished by their names. In the end, both approaches amount to pretty much the same thing, and each has its champions.