Component Object Model

The subject matter here usually covers whole books, I have typically here so far reached chapter 2 or 3.

Assumptions:

• a good understanding of C++
• in particular class inheritance
• paramount, pure virtual functions, abstract classes

Component Object Model is the study of interfaces. An interface is an abstract class consisting of solely pure virtual functions and no repeat no data. What does all that mean, some of it is repetitive, that is an abstract class is a class with at least one pure virtual function, so lets remove that bit.

An interface is a class consisting of solely pure virtual functions and no repeat no data. Remember though it is an abstract class.

The first think you learn about an abstract class is that you can not instantiated it, how can you, it has no definitions of its pure functions. What is not made clear is that you can define a pointer to such a beast and that such beast has substance.

An interface is a pointer to part of an object implementing our class.

Lets consolidate the last step

File InterfaceODBC.h
class InterfaceOdbc{
// no data and only prototypes of member functions defined. no data no logic. easy eh!
dbConnect(char * name) = 0;
dbPrepare()=0;
dbExecute()=0;
...
}

File ImplementODBC.cpp
#include InterfaceODBC.h
class ImplementODBC: public InterfaceOdbc{
// data and logic
ImplementODBC(){}
dbConnect(char * name){ code code ...}
dbPrepare(){ code code ...};
dbExecute(){ code code ...}
Handle stmt;
Handle env;
...
}
InterfaceOdbc* GetPointer(){static ImplementODBC Impdb();
pIdb = (InterfaceOdbc*) &Impdb(); // I will use RTTI latter
}

Though the above is simple consider the following.

• InterfaceOdbc has no substance, it defines no logic and no data. In COM talk it defines an interface or a contract.
• ImplementODBC does contain data and logic for all, repeat all, functions in InterfaceOdbc. ImplementODBC is a fairly normal class whose only peculiarity is that it is derived from an abstract class and once the functions are defined this abstractness has no significance.
• It is not possible to instantiate a member of the class InterfaceOdbc. BUT it is possible to define a pointer to InterfaceOdbc and point it to part of an instance of ImplementODBC
• The pointer can then be used to access the implementation, e.g. pIdb->dbExecute()

Consider the 3 files

• InterfaceODBC.h defines the interface, the contract or the abstract class consisting of solely pure virtual functions and no repeat no data.
• ImplementODBC implements a class ImplementODBC which is derived from InterfaceODBC and fleshes out the methods. Note the last procedure GetPointer(), this provides linkage between implementor and user. It hides from the user the existence of the class ImplementODBC.
• User.cpp is where the user requests a pointer to the InterfaceODBC and then uses it. He is not interested how this interface is implemented.

The normal approach

This would have emphasised the following

• COM is a binary standard. I have defined it in terms of an abstract class. Most texts define both and then bring them together.
• COM is defined to cross language barriers.
• COM is much more.

Back to our simple example.

The interface file InterfaceODBC.h is nice and clean, it is used by both implementor and user in the same form. The other two files are fairly independent except for the procedure GetPointer(). COM has a COM library, of which one of its main function is to provide interface pointers between user and implementor and it does not use a procedure called Getpointer().

Lets rewrite our program

File User.cpp
#include InterfaceODBC.h
#include COMHeaderFiles
main(){
InterfaceOdbc* pIdb;
CoInitialize(0);
CoCreateInstance(rClassId,0,CLSID_ODBC,IIID_ODBC, &pIdb);
if (pIdb){ // COM has found by magic my interface
pIdb->dbConnect("Lottery");
pIdb->dbPrepare();
pIdb->dbExecute()
}

....
pIdb->Release();
CoUninitialize();
}

Before, even though this was the user section, we had to know of the existence and the how of the implementation file. Now I know nothing of the implementation file, I hope it exists and has been integrated into the system under the rules of COM, which rules at this stage I do not need to understand.

Let me be extremely boring and say the whole thing again. In the above version I have never seen or will see the file ImplementODBC.cpp. The implementor has taken care of all these details and has provided my system with a module (module is deliberately vague to allow several types of implementation) and told the system it is there and that it implements implements the InterfaceODBC. The only change in the program is to check that an interface is returned, that is the implementor did do his job.

The file InterfaceODBC.h will now be provided by the implementor and on the whole will resemble our earlier version, but it will contain some rather strange extra bits. How else can the COM library work its magic without strange extra bits. As a user we are above this and can ignore them. In fact these strange bits provide the parameters for CoCreateInstance as below.

CoCreateInstance(rClassIdODBC // found in InterfaceODBC.h provided by implementor
,0
,CLSID_ODBC // found in InterfaceODBC.h provided by implementor
,IIID_ODBC // found in InterfaceODBC.h provided by implementor
, &pIdb);

The above will allow you to use COM, this is akin to crawling, you will get from A to B but it is more efficient to walk or run.

To the Mighty Dwarf's cave

End

E-Mail - Dave Weatherall

@Copyright 2003  by Dwarf .