The previous lesson discussed how a client creates an instance of a COM object and obtains its first interface pointer into the object, using either CoGetClassObject followed by a call to IClassFactory::CreateInstance or CoCreateInstance.
Using this interface pointer, a client can make calls into the interface and, by calling QueryInterface, obtain other interface pointers into the current instance of the COM object.
Do not confuse a COM call with a C++ call.
Calls into a COM interface look just like calls into a virtual member function of a C++ class. Even if the COM object uses a C++ class to implement a COM interface and returns a this pointer to the client, the client can only see what is in the vtable.

The client and the server have a split view of a COM interface. The server/object sees the interface as virtual functions within an instance of a C++ class. The client sees a COM interface pointer, i.e., a pointer to a vtable pointer. Data and nonvirtual methods within the instance of the C++ class implementing the COM interface are not visible to the client.

COM objects are well encapsulated. You cannot gain access to the internal implementation of the object. That means for example you have no way of knowing what data structures the object might be using.
Objects "live" through interfaces. An interface is the object’s point of contact to the outside world. The outside world in terms of COM are various application programs. They act as clients asking the server object for some kind of service. All what a client gets from COM is a pointer to the interface.

Click the Exercise link below to apply what you have learned about COM interface pointers.
COM Interface Pointer - Exercise