ArcGIS Engine Developer Guide

THE MICROSOFT COMPONENT OBJECT MODEL
An interface’s permanence is not restricted to
simply its method signatures, but extends to its
semantic behavior as well. For example, an
interface defines two methods, A and B, with no
restrictions placed on their use. It breaks the
COM contract if, at a subsequent release,
Method A requires that Method B be executed
first. A change like this would force possible
recompilations of clients.
The name IUnknown came from a 1988
internal Microsoft paper called Object Architecture:
Dealing with the Unknown – or –
Type Safety in a Dynamically Extensible Class
Library.
• Interfaces are strongly typed. Every interface has its own interface identifier,
thereby eliminating the possibility of a collision between interfaces of the
same human-readable name.
• Interfaces are immutable. Interfaces are never versioned. Once defined and
published, an interface cannot be changed.
Once an interface has been published, it is not possible to change the external
signature of that interface. It is possible at any time to change the implementation
details of an object that exposes an interface. This change may be a minor
bug fix or a complete reworking of the underlying algorithm; the clients of the
interface do not care since the interface appears the same to them. This means
that when upgrades to the servers are deployed in the form of new DLLs and
EXEs, existing clients need not be recompiled to make use of the new functionality.
If the external signature of the interface is no longer sufficient, a new
interface is created to expose the new functions. Old or deprecated interfaces are
not removed from a class to ensure all existing client applications can continue to
communicate with the newly upgraded server. Newer clients will have the choice
of using the old or new interfaces.
THE IUNKNOWN INTERFACE
All COM interfaces derive from the IUnknown interface, and all COM objects
must implement this interface. The IUnknown interface performs two tasks: it
controls object lifetime and provides runtime type support. It is through the
IUnknown interface that clients maintain a reference on an object while it is in
use—leaving the actual lifetime management to the object itself.
Object lifetime is controlled with two methods, AddRef and Release, and an
internal reference counter. Every object must have an implementation of
IUnknown to control its own lifetime. Anytime an interface pointer is created or
duplicated, the AddRef method is called, and when the client no longer requires
this pointer, the corresponding Release method is called. When the reference
count reaches zero, the object destroys itself.
Clients also use IUnknown to acquire other interfaces on an object. QueryInterface is
the method that a client calls when another interface on the object is required.
When a client calls QueryInterface, the object provides an interface and calls
AddRef. In fact, it is the responsibility of any COM method that returns an
interface to increment the reference count for the object on behalf of the caller.
The client must call the Release method when the interface is no longer needed.
The client calls AddRef explicitly only when an interface is duplicated.
When developing a COM object, the developer must obey the rules of
QueryInterface. These rules dictate that interfaces for an object are symmetrical,
transitive, and reflexive and are always available for the lifetime of an object. For
the client this means that, given a valid interface to an object, it is always valid to
ask the object, via a call to QueryInterface, for any other interface on that object
including itself. It is not possible to support an interface and later deny access to
that interface, perhaps because of time or security constraints. Other mechanisms
62 • ArcGIS Engine Developer Guide