OOPortal OOPortal


Basic COM   «Prev 

COM as component technology

Let us examine COM as a software component technology. First, COM provides a binary standard via its
  1. method calling conventions and
  2. vtables.
For example, a COM client only needs an object's CLSID, interface IDs, and interface specifications. The client does not need the internal layout of a COM object. Nor does the client have to link to a library to access a COM object. From the C++ development perspective this means that, besides the object and interface IDs, a client only needs access to a C++ class specification for each interface. Recall that these specifications contain all pure virtual functions.
To load and access a specific COM object, a client directly or in-directly obtains the class factory associated with that object. Using the class factory, instances of the COM object can be created. The client's only access into a COM object is through its interface pointers. The client has no idea of how the COM object is actually implemented.
COM's ability to de-couple client client-side code from server-side implementation internals is an example of how COM supports binary-level integration of software components.

Pure Virtual Function

A pure virtual function is a virtual function that is required to be implemented by a derived class if the derived class is not abstract . Classes containing pure virtual methods are termed "abstract" and they cannot be instantiated directly. A subclass of an abstract class can only be instantiated directly if all inherited pure virtual methods have been implemented by that class or a parent class. Pure virtual methods typically have a declaration (signature) and no definition (implementation).
As an example, an abstract base class MathSymbol may provide a pure virtual function doOperation(), and derived classes Plus and Minus implement doOperation() to provide concrete implementations.
Implementing doOperation() would not make sense in the MathSymbol class, as MathSymbol is an abstract concept whose behaviour is defined solely for each given kind (subclass) of MathSymbol. Similarly, a given subclass of MathSymbol would not be complete without an implementation of doOperation().