Elvis does not have to rebuild his code because it has no
source-code based dependencies on any interfaces or objects in CBIComp.dll. The include files used for interface definitions contained in COM objects within CBIComp.dll define only
vtable order and parameters.
Recall that these methods are all defined as pure virtual, and COM interface pointers are not instantiated by
new.
Instead, the address of the pointer is passed into
IClassFactory::CreateInstance (directly or via
CoCreateInstance) or
IUnknown::QueryInterface.
These calls are implemented by a class factory or COM object within the server. The server allocates memory for the COM object and its interfaces, and assigns the interface pointer into the caller's pointer. The integration between a COM object and client is through the object's CLSID and interface specifications only--that is, a COM class.
The actual hookup of client code to a COM object is done at runtime. As long as the object's CLSID and interface definitions remain unchanged, component users can safely integrate with components without rebuilding their applications.
To support this, we say that all
COM interfaces are immutable that is, once a COM interface is published or distributed, it can't change.
This lesson demonstrated how COM clients and objects integrate at a binary level. In following lessons, we will examine how software components support
reusability.
From a client's point of view, a component is a unit of object instantiation at run time. From the point of view of the code, a component is a house for a collection of interfaces. A compiled and linked component is stored in a container file with extension
.exe or .dll that can be accessed during run time by a client. Every container is equipped
with an instantiator that is called by the operating system when needed.
