9.2 Mechanistic Design Patterns

Design patterns consist of at least three aspects:

• A common problem, including a common problem context

• A general approach to a solution

• Consequences of the pattern

The problem statement describes the general characteristics of the problem at hand. This description may include context and preconditions. For example:

Problem: When exception handling is used, raw pointers can lead to memory leaks when exceptions are thrown. The use of temporary pointers within normal C++ functions or class member functions may not be properly cleaned up if an exception is thrown because the inline delete operator may be bypassed. This does not apply to objects created on the stack because when objects go out of scope, their destructors are called. Raw pointers do not have destructors.

It should be noted, that this problem as with all problems addressed by design patterns specifies an optimization concern. Design is all about optimization and so is driven by the required or desired quality of service properties of the collaboration. In this case, we are trying to optimize robustness by noting that there is a problem with using standard pointers.

This statement identifies a problem common to many designs within many domains. The context is broad programs using C++ with exception handling. Since a generally applicable solution to this problem is available, it can be reified into a design pattern:

Solution: Rather than use a raw pointer, a "smart" pointer object can be used when a temporary pointer is needed. The smart pointer is responsible for identifying whether a memory must be deallocated when the pointer is destroyed.^[2] This requires an internal mechanism, such as reference counting, to determine whether other smart pointers are referring to the same object in memory.

^[2] There may be other pointers to the memory, so it is not always clear whether the memory being pointed to can be safely deleted along with the pointer.

^[2] There may be other pointers to the memory, so it is not always clear whether the memory being pointed to can be safely deleted along with the pointer.

Naturally, design patterns have pros and cons. These are the consequences of the design pattern:

Consequences: The smart pointer makes the design more robust in the presence of thrown exceptions, but it increases the code complexity somewhat and requires an additional level of indirection for each pointer reference. Although this can be made syntactically invisible to the user, it involves a small runtime overhead. Enforcement of the smart pointer policy cannot be automated, but must be ensured by consensus and review. Further, if smart and raw pointers are both applied against the same object, reference counting should be disabled.

Mechanistic design patterns are medium scale, involving as few as two or as many as a dozen classes. Several patterns are provided in this chapter, but this is a rich area of active research. See the references at the end of this chapter for more patterns.^[3]

^[3] Another good source of patterns is the patterns home page at http://hillside.net/patterns/patterns.html. Other interesting Web pages can be found by looking for design patterns using your favorite Web search engine.

As specified, you may find these patterns too specific or too general. Feel free to adapt these patterns to the particular needs of your system.

This chapter presents the mechanistic patterns listed in Table 9-1.

Table 9-1. Mechanistic Patterns

Category	Pattern Name	Purpose
Simple patterns	Observer	Allows multiple clients to effectively share a server and be autonomously updated.
	Proxy	Provides an observer pattern in a distributed environment.
	Reliable transaction	Controls communication between objects with various levels of reliability.
	Smart pointer	Avoids problems associated with standard pointers.
	Guarded call	Allows robust and timely access to services and data across thread boundaries.
Reuse	Container	Abstracts away data structuring concepts from application domain classes to simply model and facilitate reuse.
	Interface	Abstracts away the type of an object from its implementation to support multiple implementations of a given type and to support multiple types with a common internal structure.
	Rendezvous	Provides a flexible mechanism for lightweight inter-task communication.