The definition of a COM object includes its contained interfaces and CLSID. COM literature calls these definitions a COM class. A COM class is like a "type" definition for a COM object. The interfaces and CLSID of a COM class define a COM object's type. We create instances of a COM object using the interface specifications and the CLSID declaration in the COM class. We do not directly use the COM class to create an instance of a type of COM object. Instead, an intermediate object called a class object is used to create instances of a COM object.

A class object is a specialized type of COM object that knows how to create a specific type of COM object. There is a one-to-one relationship between a class object and a COM object. Every type of class object knows how to create only one type of COM object. For example, if two COM objects, called O1 and O2, are implemented within a COM server, two class objects must also be implemented, one that knows how to create O1 and one that knows how to create O2.
A class object can be thought of as a "creator" object. It exists only to create instances of a COM object. The only way to talk to a class object, as with all COM objects, is through its interfaces. Each class object must implement a COM interface that is used to create instances of its COM object. Clients obtain a pointer to a class object's interface by asking the COM subsystem for a specific class object that can create the COM object they want. Using this interface pointer, clients have the class object create one or more instances of their associated COM object.
The COM specification defines a COM object creation interface called IClassFactory. Class objects that implement IClassFactory as their object creation interface are called class factories. The next lesson will discuss class factories.

The CoCreateInstance() function does not itself create the instance of the component. Behind the scenes, it gets some help from a special kind of object called a class factory. Why do we need class factories? Why not simply call a magic function to directly instantiate the object? Class factories are necessary since object creation may require acquisition of system resources, coordination among objects, etc. The class factory is, in most cases, contained in the same DLL or EXE as the component. And since both the class factory and the component it creates are developed by the same person, the class factory can, and does have, special knowledge of the component it creates. With this approach, it is only the factory object that has to be explicitly created by the COM subsystem.
Another responsibility of the object factory is to maintain location transparency. As we shall see later, COM components come in many flavors; in-process (same process), local-server (different address space) and remote-server (different machine). Clients must be able to reach objects easily, regardless of where they reside. If a component is running in a separate address space or on a remote computer, then the client cannot directly allocate memory for the component. The answer to this issue is the class factory.
The picture below illustrates what happens when a client creates an in-process component. The process of creating a local-server or a remote-server is, needless to say, more complicated.

Click the Quiz link below to check your understanding of COM classes, class objects, and class factories.
Com Classes ObjectFactories - Quiz