Learning DCOM

Class Factories

So far, you’ve learned how to specify your interfaces and learned how to implement a COM object that supports a couple of interfaces. You’ve got an object, but how do you bring it to life? Technically, you can create and use your COM object as a normal C++ object. However, the goal is to expose this object to the world so that everyone, who has the correct permissions, can use the services exposed by our object.

As is, your COM object cannot be used in a distributed environment. For example, how will a remote client create a new object, using C++’s operator new, on a machine that is 200 miles away? They can’t, so remote clients can’t use your COM object just yet. You need a class factory: a COM object whose sole purpose in life is to manufacture COM objects of a specific COM class. Like interfaces, a COM class has an associated class identifier (CLSID). The CLSID is in fact a GUID, and therefore, it is a globally unique name of a class, which universally prevents name collisions. Figure 3-12 shows a class factory and its manufactured COM objects, which are instances of a COM class known to the class factory (this will be clear in Chapter 4).

Figure 3-12. A class factory and its manufactured COM objects

A class factory is a vital element in a distributed environment, because it adds another level of indirection that allows COM to arbitrate and coordinate dynamic and remote ...