Footnotes

1. Note that IClassFactory would be more appropriately be named IObjectFactoy since using it one creates objects, not classes. But IClassFactory remains for historical reasons. [Back]

2. For example, the remoting architecture described in Chapter 7 uses a different type of "factory" interface. [Back]

3. For example, in OLE 2, built on top of COM, there is an interface called IViewObject through which a client can ask an object to draw its graphical presentation directly to a Windows device context (HDC) through IViewObject::Draw. However, an HDC cannot be shared between processes, so this interface can only be implemented inside as part of an in-process object. When an object server wishes to provide optimized graphical output but does not wish to completely implement the object in-process, it can use a lightweight object handler to implement just the drawing functionality where it must reside, relying on the local server for the full object implementation. [Back]

4. In some cases the object server may already be running and may allow its class factory to be used multiple times in which case the COM Library simply establishes another connection to the existing class factory in that server, eliminating the need to launch another instance of the server applications entirely. While this can improve performance significantly, it is the option of the server to decide if its class factory is single- or multiple-use. See the function CoRegisterClassObject in Chapter 6 for more information. [Back]

5. This abstraction is still under design. [Back]