Introduction

Pattern Intents

Overall, this pattern language deals with one aspect of C++ design: In particular, it deals with that aspect that focuses on algebraic types. C++ is rich in features that support algebraic types, including operator overloading and a good family of built-in numeric types. The idioms surrounding the algebraic view are strong enough that the tradition carries on in libraries for strings and other non-numeric types. There are many non-numeric and, properly, non-algebraic types to which many of these patterns may apply.

This pattern language does not focus on techniques based on templates. One can view templates largely as a macro facility that transforms an existing inheritance structure into an isomorphic structure. However, there are some idiomatic uses of templates that might be considered in later iterations of this pattern language.

These are the pattern intents, a quick index of the patterns in this paper.

The pattern language structure

A Spatial Progression

One can view these patterns as a way to guide the geometry of an inheritance hierarchy in C++. Geometry is an essential consideration in patterns, a fact most contemporary software patterns fail to heed. Inheritance structures are one of the most accessible structures of object-oriented software design, though they are less evident in code than implementation hierarchies or other direct geometric properties like indentation (and what it portends for scope and other semantic properties).

Most of the crisp idioms of Advanced C++ Programming Styles and Idioms deal with class structures and, in particular, inheritance structures. They are the foundations of flexible object-oriented programming in C++.

Here, we both develop a pattern language based on problems, solutions, and intents, and we develop the corresponding progression of geometric structures as in Table 1: Progression of Geometric Structure in the Patterns. Only the more basic patterns are depicted here. Each shows two ellipses, one ellipse representing the interface class, and another, the representation class. Objects (the rectangles) are members of the set defined by the class. The arrows show the relationships between objects or classes as appropriate.

Advanced C++ programs using user-defined classes which should behave like built-in types as much as possible.

How do you separate interface from implementation in C++ objects?

Split a design class into two implementation classes. One takes on the role of an identifier and presents the class interface to the user. We call this first class the handle. The other class embodies the implementation and is called the body. The handle forwards member function invocations to the body.

Example:

The implementation becomes "more hidden" behind a pointer.

The extra level of indirection has a performance cost.

Also known as: Counted Handle/Body

Naive implementations of assignment in C++ are often inefficient or incorrect.

Add a reference count to the body class to facilitate memory management; hence the name "Counted Body."

Memory management is added to the handle class, particularly to its implementation of initialization, assignment, copying, and destruction.

It is incumbent on any operation that modifies the state of the body to break the sharing of the body by making its own copy. It must decrement the reference count of the original body.

Example:

Gratuitous copying is avoided, leading to a more efficient implementation.

Sharing is broken when the body state is modified through any handle. Sharing is preserved in the more common case of parameter passing, and so forth.

Special pointer and reference types are avoided.

Smalltalk semantics are approximated; garbage collection builds on this model.

Additional patterns are necessary to make such code thread-safe.

Reference counting is efficient and spreads the overhead across the execution of real-time programs. This implementation is a variation of shallow copy with the semantics of deep copy and the efficiency of Smalltalk name-value pairs.

• However, we may not add a reference count to a library abstraction, since we only have object code and a header file. We could solve this with an added level of indirection,

but that adds a extra level of indirection to each dereference, and may be too expensive.

Associate both a shared count, and a separate shared body, with each instance of a common handle abstraction:

Example:

Now we can access the body with a single level of indirection, while still using only a single indirection for the count.

Also known as: Bridge

A C++ program in which the Handle/Body idiom has been applied, in which some classes have subtyping relationships and implementation-sharing relationships that do not correspond with each other.

• You might want to inherit interface without inheriting implementation.
• In exceptional cases, you might want to inherit implementation without inheriting interface. For example, a base class member function may take one parameter for each of the degrees of freedom in its state space. Because the derived class is a subtype of the base class, it has fewer degrees of freedom than the base class. To inherit a base class operation whose parameters map onto degrees of freedom in the state space, the derived class must elide one argument (or otherwise constrain the arguments). But a base class operation inherited by the derived class should exhibit the same signature in both classes.
• If you inherit from a C++ class, you inherit its implementation.
• We usually use (public) inheritance (in the languages defined in the context) to express subtyping.

class Ellipse {
public:
	Ellipse(Pdouble majorAxis,
	Pdouble minorAxis, Point center);
	virtual void resize(Pdouble majorAxis, Pdouble minorAxis);
	. . . .
private:
	// representation is in terms of two
	// foci, the constant sum of the distance 
	// between any point on the ellipse and
	// each of the two centers
	Point center1, center2, sum;
};

class Circle: public Ellipse { // because a
	// Circle IS-A
	// Ellipse
public:
	Circle(Pdouble radius, Point center): 
	Ellipse(radius, radius, center) { }
	void resize( ? );
private:
	// can reuse sum as the radius, and one
	// of the centers as the center, but the
	// other center is wasted
};
 

Maintain separate inheritance hierarchies for handle classes and body classes. The base interface class contains a reference to the base implementation class.

At first glance, resize(Pdouble,Pdouble) seems to apply to Ellipses but not to Circles. It is easy to conclude this, because resize is closed under Ellipse, but not under Circle. However, resize applies equally to Circles as to Ellipses, and is closed under Ellipses in general. This means that any attempt to resize a Circle changes it into an Ellipse. Such dynamic retyping is difficult to support in the given context of statically typed languages. To overcome this restriction, use idioms (like the Envelope/Letter idiom) or design patterns (like the GOF Bridge [GOF1995]) that allow dynamic retyping of an object at run time. Here, the type is a function of the number of degrees of freedom in the state. This is a subtle difference from the GOF State pattern [GOF1995] alone, where type depends on value.

Compare Rungs of a Dual Hierarchy from [Martin1997].

A program using Handle/Body pairs and/or Counted Body pairs

• Multiple implementations of an ADT share signature: we want to capture that in the design and code.
• All implementations (bodies) of a given ADT share signature with the ADT's interface (handle): we want to capture that.
• Adding a new operation to a handle/body pair causes redundant update to both classes.
• The handle implementation is coupled to the implementations of all possible bodies.

Derive all solution body classes from a common base class. To reflect the commonality in signature between the handle and the body, use the handle class as the common base class for alternative bodies. Make handle member functions virtual. Each alternative implementation derived from the handle class (in its role as the class defining the interface to the implementations) overrides suitable virtual functions. The base class implementation of these member functions defines the handle class functionality: it forwards requests to its associated body class instance.

The solution is weakly reflexive.

Example:

Consider a Shape library with code to support Circles and Ellipses. Consider an Ellipse that is resized so it becomes a Circle. We could leave it as an Ellipse, but changing the type to Circle allows for significant optimizations. For example, rotation can now be done much more efficiently. We can implement this either through changing type in place through a function like:

which would change the type of the body object pointed to by *this; or we could have resize return a value whose type is determined at run time:

This pattern is the basis for Virtual Constructors.

In Algebraic Hierarchy, this pattern forms the basis for a Promotion Ladder.

A particular client wants to create an object of an unspecified class chosen from a specified class hierarchy. Once created, any object created from the classes in the hierarchy can be used interchangeably by the client. The particular class is chosen from an arbitrary global context according to the needs of the client. The Handle/Body pattern has been applied.

• You want to hide the implementation of the inheritance hierarchy from the user of the hierarchy's objects: only the base class interface should be published.
• Code must be written to select the most appropriate derived class. The code should be associated with the abstraction that minimizes coupling between all classes involved.
• The client must be able to use the services of any derived class object.

Just use the Envelope/Letter pattern structure. The base class is an intermediary agent that selects the appropriate derived type from context. The notion of supporting multiple implementations of an object across its lifetime generalizes to selecting the appropriate initial implementation, even in the degenerate case that the body instance doesn't change over the lifetime of the Handle/Body pair.

Consider a Message class with a constructor:

whose intent is to create a message of a suitable type according to the header information that appears in the body of an in-memory message image of length nbytes at address ptr. The concrete type of the message is unknown until run time, but it will always be some class derived from Message. The class Message can be made an envelope class, and the constructor can instantiate a body of a suitable type derived from Message.

Interface and implementation are now separate, and we can capture the subtyping semantics in the C++ inheritance hierarchy. Commonality between the implementation parts can be captured in a separate inheritance hierarchy if desired.

You need to distribute responsibilities to the objects; i.e., the addition operation. How many addition operations are there, and where do they belong?

The solution generalizes to other binary operations.

How do you do heterogeneous addition?

C++ in particular is rich in language features that support promotions involving both user-defined types and built-in types.

The pattern generalizes beyond addition to other binary operations.

Where do you put the knowledge of type promotion?

Each class should know how to promote itself to its own base class type. Promotions that involve more than two levels of the inheritance hierarchy can be handled by multiple successive promotions.

Detect cases in which neither type can be promoted to the other. Promote both to a more general type and retry the operation.

Promotion between objects of different but related C++ types, zero or one of which is a built-in type.

A program should promote a class object type to a built-in type using a member conversion operator:

Coupling (and, in general, friend relationships) are still necessary between types; the force is resolved only to the extent that the conversion is firmly associated with a single type. The pattern does guarantee that the type bearing the conversion is always a class object type, however.

The pattern avoids most conversion ambiguities. An additional pattern must deal with the case:

A given type cannot know about every (more general) type in the universe whose instances might be created as generalizations of itself; the onus is on the type of the newly created object to understand its own initialization parameters.

Primitive types form an exceptional subpattern because their semantics are built into the compiler for efficiency, and their semantics are not as generally subject to change as those of user-defined types.

Acknowledgements

Many thanks to Steve Berczuk who was the EuroPLoP '98 shepherd for this paper.

References

[Cargill1996] Cargill, Tom. Localized Ownership: Managing Dynamic Objects in C++. Pattern Languages of Program Design — 2. John M. Vlissides et al., eds. Reading, MA: Addison-Wesley, 1996.

[Coplien1992] Coplien, J. O. Advanced C++ Programming Styles and Idioms. Reading, Ma: Addison-Wesley, 1992.

[GOF1995] Gamma, E., et al. Design Patterns: Elements of Re-Usable Object-Oriented Software. Reading, Ma.: Addison-Wesley, 1995.

[Ingalls1986] Ingalls, Daniel H. A Simple Technique for Handling Multiple Polymorphism. Proceedings of OOPSLA '96, September 1986, ACM Press.

[Koenig1995] Koenig, Andrew R. "Variations on a Handle Theme." JOOP 8(5), 1995, 77-80. New York: SIGS Publications.

[Martin1997] Martin, R. Design Patterns for Dealing with Dual Inheritance Hierarchies in C++. In C++ Report 9(4), April, 1997. New York: SIGS Publications.