Microsoft’s Component Object Model (COM) is the dominant object model for the Microsoft Windows family of operating systems. COM encourages each object to support several views of itself, i.e. interfaces. Each interface represents a collection of logically related functions. A COM object is not allowed to expose multiple interfaces using multiple inheritance, however, as some languages do not support it and those that do are not guaranteed to do so in a binary-compatible way. Instead, an object exposes interfaces via a function called QueryInterface(). An object implements QueryInterface() to allow a client to ask what other interfaces the object supports at run-time.
This run-time type discovery scheme has three important characteristics. One, it allows an object to add additional functionality at a later date without disturbing functionality expected by an existing client. Two, it provides for language-independent polymorphism. Any object that supports a required interface can be used in a context that expects that interface. Three, it provides an opportunity for the client to degrade gracefully should an object not support requested functionality. For example, the client may request an alternate interface, ask for guidance from the user or simply continue without the requested functionality.
COM attempts to provide its services in as efficient a means as possible. For example, when an object server shares the same address space as its client, the client calls the functions of the object directly with no third-party intervention and no more overhead than calling a virtual function in C+ +. However, when using COM with some programming languages, this efficiency has a price: language integration. COM does not integrate well with a close-to-the-metal language like C+ +. In many ways COM was designed to look and act just like C + + , but C + + provides its own model of polymorphism, object lifetime control, object identity and type discovery. Of course: since C+ + is not language-independent or location transparent. it was designed differently. Because of these contrasting design goals, a C+ + programmer using COM often has a hard time reconciling the differences between the two object models.
To bridge the two object models, I have developed an abstraction for this purpose that I call a faux-object class. In this thesis, I illustrate the use of a specific instance of the faux-object idiom to provide an object model bridge for COM that more closely integrates with C+ +. By bundling several required interfaces together on the client side, a faux-object class provides the union of the operations of those interfaces, just as if we were allowed to use multiple inheritance in COM. By managing the lifetime of the COM object in the faux-object’s constructor and destructor, it maps the lifetime control scheme of C+ + onto COM. And by using C+ + inline functions, a faux-object can provide most of these advantages with little or no additional run-time or memory overhead.
COM provides a standard Interface Definition Language (IDL) to unambiguously describe COM interfaces. Because IDL is such a rich description language, and because faux-object classes are well defined, I was able to build a tool to automate the generation of faux-object classes for the purpose of bridging the object models of COM and C+ +. This tool was used to generate several faux-object classes to test the usefulness of the faux-object idiom.
Enjoy.
