Reference counting requires work on the part of both the implementor of a class and the clients who use objects of that class. When you implement a class, you must implement the AddRef and Release methods as part of the IUnknown interface. These two functions have simple implementations:
A common implementation approach for most objects is to have only one implementation of these functions (along with QueryInterface), which are shared between all interfaces, and therefore a reference count which applies to the entire object. Architecturally, however, from a client's perspective, reference counting is strictly and clearly a per-interface-pointer notion, and objects may be implemented which take advantage of this capability by dynamically constructing, destroying, loading, or unloading portions of their functionality based on the currently extant interface pointers. These are colloquially called "tear-off" interfaces.
Whenever a client calls a method (or API function) that returns a new interface pointer, such as QueryInterface, the method being called is responsible for incrementing the reference count through the returned pointer. For example, when a client first creates an object, it receives an interface pointer to an object that, from the client's point of view, has a reference count of one. If the client then calls AddRef on the interface pointer, the reference count becomes two. The client must call Release twice on the interface pointer to drop all of its references to the object.
An illustration of how reference counts are strictly per-interface-pointer occurs when a client calls QueryInterface on the first pointer for either a new interface or the same interface. In either of these cases the client is required to call Release once for each pointer. COM does not require that an object return the same pointer when asked for the same interface multiple times. (The only exception to this is a query to IUnknown, which acts as an object's identity to COM.) This allows the object implementation to manage resources efficiently. Thread-safety is also an important issue in implementing AddRef and Release. For more information, see Processes and Threads.