Surrogate objects

Sometimes it is more useful to deal with a reference to an object than to directly create and manipulate the object itself. Other times, it's your only choice, such as for objects in another address space. Objects that act as stand-ins for other objects are surrogates. Surrogates are useful in many different situations and can operate in several different ways.

Taxonomy of surrogates

Though it is an incomplete list, this chapter describes five kinds of surrogates:

An explicit master--Where the programmer can create and manipulate a master object, and can also create a surrogate object that can be used to manipulate or refer to the master. Usually, the only way to release resources is to destroy the master. The name for this type of surrogate should be the master object's name, followed by Surrogate, as in TFooSurrogate.

A handle to an explicit master--Where the programmer can't explicitly create or manipulate the master object (although this is not a requirement for this model). Instead, creating the surrogate creates a new master object. The semantics are explicitly shared semantics, and the master object might be reference-counted and deleted when the last surrogate is destroyed. Because this type of surrogate is a conduit to the real object, end the name of these surrogates with Handle, as in TFooHandle. Do this even if TFoo doesn't appear in a public header file.

A hidden master--Where the master object's existence is transparent to the programmer. This is similar to the previous case, but the semantics are not shared semantics. Sharing occurs behind the scenes to avoid overhead, but modifying the surrogate object does not modify the master object; instead, a new copy of the master is made and modified (copy on write semantics). This surrogate has no specific naming convention because the existence of a master object is transparent to the client. Thus, it's an implementation technique and not part of the class interface. If you have a modifier, put it on the internal class. For example, if the surrogate is TFoo, the internal class is TFooImplementation or TFooStorage or whatever.

A surrogate that views the master--Like the first case, but the surrogate isn't a direct stand-in for the master object. Instead, it is a synthetic or virtual perspective on that object, a satellite of the master object. It's used to encapsulate information about an aspect of the master object. After a massive thesaurus overdose, the conclusion is that the name for this kind of surrogate depends on the situation. The name of the viewed class should have something in common with the surrogate (for example, TUpdateRegion and TUpdateRequest).

Objects used to get other objects--An object that can be used as a compact reference to another object, which could itself be a surrogate. This surrogate has no protocol other than to obtain the referenced object (which could even be created). The name of this surrogate should end with Reference.


[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker