Coclass

We saw earlier that COM Interfaces can be perceived as views of a component. This conceptual representation actually maps the implementation of an EiffelCOM component. This is because the coclass inherits from the interfaces and implements their deferred features. Indeed, interfaces are deferred classes with all features deferred that are accessible by clients. The coclass is an Eiffel class that inherits from these interfaces and implements all the features. This design is not specific to Eiffel though, and can be found in other languages as well. The coclass defines the behavior of the interface functions.

Class Object

Also, we have seen that interfaces are accessed through interface pointers. But how does a client obtain one of these? The answer lies in the class object. The name of this module should really be coclass factory since its goal is to spawn instances of the coclass on request. Class objects are accessed by COM whenever a client requests a new instance of the associated component. COM loads the class object and asks it to provide the interface pointer requested by the client.

The way a class object is loaded in memory (this process is called activation) depends on the location of the component (See Location for a description of the possible locations of a component). If the component is an in-process server, then the class object is called directly through the functions exported from the DLL. If the component is an out-of-process server, then it provides COM with a pointer to the class object. In both cases, once the component is loaded, COM has access to the class object and can call it, should a client request a new instance of a component.

The code for the class object is generated by the EiffelCOM wizard so that Eiffel programmers will not have to worry about it.

See Also: EiffelCOM wizard
EiffelCOM library
Introduction
COM Concepts
COM Interfaces
Component Location
Access Type
Deeper into COM