Introduction
The French philosopher, Émile-Auguste Chartier, said that "nothing is more dangerous than an idea, when you have only one idea" (or, to be precise, "rien n'est plus dangereux qu'un idée, quand on n'a qu'une idée"). The same can be said of books: they do not know design patterns that only Design Patterns know.
The Gang-of-Four's Design Patterns [1] is a classic, and a book that every C++ developer should read and have access to, but it's neither the first nor the last word on design patterns. It is a landmark in the development of patterns as a design idea for software. A lot of water has passed under the bridge since it was published, and a lot of understanding has flowed into that river. The twenty-three patterns in the book are a staging post, and often a starting point, on a journey, but are neither the whole journey nor its destination.
Design Patterns has helped a lot of people to improve their designs, raising the level of communication and design thinking for many. But there still seems to be widespread misunderstanding as to the role that patterns can play in software architecture. For one, there is the quaint but lingering belief that the twenty-three patterns in the book are the only patterns you need to know for effective software development. They are a taster, some of them common and some of them less so; don't mistake the set meal or chef's recommendation for the full à la carte menu.
State Legislation
One of the important features of any design is its context, which gives rise to the forces that motivate the pattern, constraints, characteristics, and challenges that make a particular design problem a design problem. The context also offers, and restrains, some of the means of solution. C++ itself offers part of a problem and solution context: some patterns address working with the language itself and some are based on solutions only possible given the nature of the language.
Some designs appear to be general purpose and largely independent of their solution technology. For instance, some design ideas move easily and relatively unaffected from C++ to Java or C#. However, it is faulty — but alas common — logic to then deduce that design is — or should be — context independent. A tidy fiction, but it is still a fiction. Some practices considered good in the context of C++ either have no meaning in another context or just look like bad design when teleported elsewhere. Take a fish out of water, and what do you expect? Dish of the day?
OK, let's mix some concrete to cover this abstract thinking.
Around the Clock
Consider a simple digital clock:
- It displays hours and minutes in normal 24-hour time.
- It has two buttons: one button to change the mode and another to increment the hour or minute, depending on the mode.
- A heartbeat event once a second is generated internally to allow the clock to update.
The clock has three specific modes:
- Displaying the time, in which the increment button is ignored and the update event advances the stored time.
- Setting the hours, in which the clock ignores the update event and the increment button increments the displayed hour value.
- Setting the minutes, in which the clock ignores the update event and the increment button increments the displayed minute value.
The button to change mode cycles through these specific modes in order. These modes can also be considered more abstractly as two general modes:
- Displaying the time, in which the increment button is ignored and the update event is not.
- Setting the time, in which the update event is ignored and the increment button is not.
This is not exactly complex state behavior, but there is enough here to get your teeth into. What are the options for implementing such a model in C++? Let's start with a flag-and-switch approach.
State Flags
The following code shows the essential public interface and a simple representation:
class clock { public: void change_mode(); void increment(); void tick(); ... private: enum mode { displaying_time, setting_hours, setting_minutes }; mode behavior; int hour, minute, second; };
The clock has a simple lifecycle model: the only behavioral changes come from the change-mode button, and they are independent of data values or any intermediate behavior. Therefore, only the change_mode function affects behavior:
void clock::change_mode() { switch(behavior) { case displaying_time: behavior = setting_hours; break; case setting_hours: behavior = setting_minutes; break; case setting_minutes: behavior = displaying_time; break; } }
A table lookup is perhaps a little more elegant:
void clock::change_mode() { static const mode next[] = { setting_hours, setting_minutes, displaying_time }; behavior = next[behavior]; }
Alternatively, the cycling property can be exploited directly:
void clock::change_mode() { behavior = mode((behavior + 1) % 3); }
The realization of increment is less open to alternatives:
void clock::increment() { switch(behavior) { case displaying_time: break; case setting_hours: hour = (hour + 1) % 24; break; case setting_minutes: minute = (minute + 1) % 60; break; } }
The empty case for display_time is included for completeness, demonstrating explicitly statewide coverage for the event. The event response for tick can be seen as complementary:
void clock::tick() { switch(behavior) { case displaying_time: if(++second == 60) { second = 0; if(++minute == 60) { minute = 0; hour = (hour + 1) % 24; } } break; case body::setting_hours: break; case body::setting_minutes: break; } }
Objects for States
There is a temptation to tow an orthodox hard-line and come down hard on flags and switchs as always being a sign of deficient design. However, this line is a narrow and not always convincing one. For the scope and scale of the given problem, almost any other solution not based on explicit selection will be longer and more intricate. In spite of the clumsiness of C++'s switch statement — quite possibly the most inept piece of control-flow design in a modern language — it is not worth pursuing an alternative design at this level.
However, if we imagine a slightly broader version of the problem, the context shifts and the flag-and-switch solution becomes increasingly — indeed, exponentially — inappropriate. Consider adding an alarm feature to the clock, and perhaps a date feature. Taking it further, a digital watch typically offers all these features and more: stopwatch, multiple time zones, phone book, etc. The flag-and-switch design will collapse under its own weight, acquiring the flexibility of a block of concrete, the cohesiveness of loose sand, and the plot comprehensibility of a telephone directory. Such consequences would justify the pursuit of alternative approaches.
The Objects for States pattern [1] offers itself up as a likely candidate. It is also known as the State pattern, but this name is misleading and not particularly descriptive. It is misleading because it is often mistaken as definitive: the State pattern. It is not particularly descriptive because there is no suggestion of the solution structure in the name, just a hand-waving reference to the problem. The Objects for States name is listed in Design Patterns as a synonym for the pattern. It more accurately captures the intent and structure and should be preferred.
Delegation and Hierarchy
The organizing principle behind the pattern is the introduction of an object to represent the behavior of the main object — the clock in this case — in each mode. The behavioral object offers a method for each event the main object can respond to — in this case change_mode, increment, and tick. Here is a sketch of this from the main object's perspective:
class clock { public: void change_mode() { behavior->change_mode(this); } void increment() { behavior->change_mode(this); } void tick() { behavior->tick(this); } ... class mode { public: virtual void change_mode(clock *) const = 0; virtual void increment(clock *) const = 0; virtual void tick(clock *) const = 0; ... }; const mode *behavior; ... };
All the responsibility for behavior is forwarded to the behavior object. For each mode of behavior, there is a class derived from clock::mode. Explicit switch-like selection has been replaced by run-time polymorphism. The behavior for each mode has been localized and encapsulated rather than scattered across different cases in many functions. The reason for the back-pointer argument becomes apparent when you consider that the behavioral objects must also affect the state of the clock object's data:
class clock { ... class displaying_time : public mode { public: static const displaying_time instance; virtual void change_mode(clock *that) const { that->behavior = &setting_hours::instance; } virtual void increment(clock *) const { } virtual void tick(clock *that) const { if(++that->second == 60) { that->second = 0; if(++that->minute == 60) { that->minute = 0; that->hour = (that->hour + 1) % 24; } } } ... }; class setting_time : public mode { public: virtual void tick(clock *) const { } ... }; class setting_hours : public setting_time { public: static const setting_hours instance; virtual void change_mode(clock *that) const { that->behavior = &setting_minutes::instance; } virtual void increment(clock *that) const { that->hour = (that->hour + 1) % 24; } ... }; class setting_minutes : public setting_time { public: static const setting_hours instance; virtual void change_mode(clock *that) const { that->behavior = &displaying_time::instance; } virtual void increment(clock *that) const { that->minute = (that->minute + 1) % 60; } ... }; };
The union of both the setting hours mode and the setting minutes mode under the banner of setting time allows the common update behavior to be factored out into an abstract base class so that tick is provided in clock::setting_time.
The behavioral object is sometimes also known as the state object, but this name is confusing: as you can see from the code, the state object is often stateless. In this case, because the state object is stateless and immutable, a single instance for each concrete class will suffice, avoiding the need for dynamic object creation. The appropriate solution in this case is simply to use a static. There is a temptation to use a Singleton [1], but this temptation should be resisted. In this case, it overcomplicates the design. (As an aside, avoiding the use of Singleton is generally a good design idea. It is an overused technique that very few designs genuinely need, and most would be better off without — they would become more loosely coupled, easier to test, easier to extend, etc. The book, column, and newsgroup space and amount of developer effort devoted to Singleton often makes it appear more significant than it really is or should be.)
Cooking Down the Source
The implementation of the state model using objects and polymorphism is elegant, albeit longer than the explicit-conditional approach. Its broader benefits are not as easily discernible as they would be in a more extensive state model.
It is possible to boil off a little bit of the implementation:
- The clock::setting_time class exists to classify commonality, but can be folded away: the clock::mode class can be made concrete with empty definitions for all the member functions. This is not a massive saving in source code — and it does go against the concrete leaves recommendation for hierarchies [2] — but it is certainly one that can be considered.
- Because of its simplicity, the change_mode functionality can be centralized into a single function using RTTI. A single definition in clock::mode without any overriding can cover all the required behavior. It is tempting to introduce a table lookup mechanism, but, unless you have the code already lying around, setting it up will generally be wordier than performing the tests explicitly. Because this is not a time-critical piece of code, the additional time overhead introduced by RTTI in contrast to virtual function lookup will not be significant. However, whichever way you look at it, there is little to be gained by such centralization.
Better Encapsulation
OK, I've been holding back a few details. The definition shown for clock, using nested classes, is neat, but it is not possible to implement it in a properly encapsulated manner. This is an oversight in the language rather than a fault in the design thinking.
If you look back over the code, it would be natural to assume that all the internal detail was, well, internal: all of those nested classes should be private. However, if you do that, the code will fail to compile. Although all the features — member functions and static data — are public in each nested class, because the classes themselves are private to clock, the other classes cannot see them! This is, to say the least, slightly bizarre and has been almost unanimously acknowledged by the C++ standardization committee as an oversight to be fixed.
With the sole exception of type members, class members — member functions and data — can depend on nested types. Nested classes, if private, cannot inherit from one another or refer to one another in any way. This roundly defeats the benefits of encapsulation that they could otherwise offer.
You might be thinking that friend would be a solution. There are, however, two problems with this: (1) granting friendship to internal features seems like the wrong use of the feature — friendship is all about granting permission externally — and (2) it's not legal C++. Sure, you will find a number of compilers that allow friendship to be granted inwards, but this is actually disallowed by the Standard. The idea of patching the oversight by further hacking friend lacks both taste and methodological soundness.
There are a few programmers who would prefer to see inward friendship rather than straightening out the scope and access rules. I have heard the claim that adopting the scope-based approach would reduce encapsulation, but I can only presume that this conviction is based on a misunderstanding of encapsulation — not an understanding based on information hiding and modularity principles.
There is a simple demonstration of why encapsulation is better served by the regular scope-based approach than by the further abuse of friend: How can you fully hide the implementation of clock so that the class definition seen by the programmer and the compiler is unaffected by internal design decisions? For instance, using a header file that would be suitable for both the flag-and-switch implementation and the Objects for States implementation. The Cheshire Cat idiom offers the most discreet answer to this question [3]. An important but often forgotten part of this idiom is its ability to hide static member and nested type details, and not just ordinary data member representation. Effective use of this idiom does not even depend on having a pointer to an implementation body; you can simply use the type and static privacy offered by the forward-declared nested type. (If you had wondered why I still prefer the traditional name for the idiom rather the more recently coined Pimpl term [4], you now have your answer: not only does the idea of naming the practice after a wart lack appeal and send out the wrong message — it is after all a good practice — but the name suggests a narrower use for the technique than is appropriate.)
The header file would be defined as follows:
class clock { public: void change_mode(); void increment(); void tick(); ... private: class body; body *self; };
In the source file, the definition of clock::body is elaborated according to preference. For the flag-and-switch approach:
class clock::body { ... enum mode { displaying_time, setting_hours, setting_minutes }; mode behavior; int hour, minute, second; };
And, assuming more regular scope and access rules, a sketch of Objects for States:
class clock::body { ... class mode { public: virtual void change_mode(clock::body *) const = 0; virtual void increment(clock::body *) const = 0; virtual void tick(clock::body *) const = 0; ... }; class displaying_time : public mode {...}; ... const mode *behavior; int hour, minute, second; };
How would you make Objects for States work using inward friendship, assuming that the language was extended in that direction instead? You wouldn't: it would not be possible. You would have to start including friendship details in the clock class definition in the header. In other words, you would not be able to fully contain and isolate the internal details using that approach; it would therefore support a less-encapsulated style of programming.
Functions for States
I have seen developers make the mistake of assuming that Objects for States is the "one true way" to realize state models in code. This is partly because of its inclusion in Design Patterns as the only object lifecycle pattern and partly because of its branding as the State pattern. The pattern is powerful and certainly not trivial; applying it uniformly to code as a cure-all for all state models is sure to complicate the source and confuse the reader.
A good pattern name tells you something about what you are getting and gives you a handle to distinguish it from other competing solutions in the same space. And that is the key: competing solutions. What is missing from many pattern descriptions is the recognition of the competition. It is the presence of alternatives that offers different tradeoffs and puts design into tension that makes a design decision a design decision. If you are familiar with Design Patterns, you start to get a sense of this when you see how the creational patterns interact and play off one another. This competition and counterpoint is missing from most of the other patterns in the catalog. Previous columns have demonstrated that such opposition and diversity is a healthy sign — and even an essential part — of design [3, 5].
Objects for States is not the only game in town. For example, Collections for States [6] addresses the slightly different problem of dealing with the collective modal behavior of many objects. The state model is driven and managed externally rather than internally, a quite different — and sometimes complementary — solution to Objects for States. However, Collections for States is not the appropriate alternative here.
For the clock example, we can make a couple of observations that will nudge us in the direction of a viable competitor:
- Each mode object is stateless.
- The behavior in each mode affects the state of the main object.
These two properties are at odds with one another: a conflict that is resolved by passing the state into each mode function explicitly.
Function Pointers Considered Useful
Riddle me this: What kind of function has no state of its own but can access the state of an object without the aid of arguments? A member function. How can you change a feature of an object without replacing the main object? A pointer. Put the two together and you find yourself composing do-it-yourself vtables with pointers to member functions. Each public member function forwards its call to the relevant member function pointer in a struct indicative of the current mode:
class clock { public: void change_mode() { (this->*(behavior->change_mode))(); } void increment() { (this->*(behavior->increment))(); } void tick() { (this->*(behavior->tick))(); } private: typedef void (clock::*function)(); struct mode { const function change_mode, increment, tick; }; static const mode displaying_time static const mode setting_hours; static const mode setting_minutes; const mode *behavior; int hour, minute, second; ... };
A palette of suitable behavior is provided:
class clock { ... private: ... template<const mode *next_mode> void change_to() { behavior = next_mode; } void increment_hours() { hour = (hour + 1) % 24; } void increment_minutes() { minute = (minute + 1) % 60; } void update_time() { if(++second == 60) { second = 0; if(++minute == 60) { minute = 0; hour = (hour + 1) % 24; } } } void do_nothing() { } };
And the rest is down to initialization, letting the data do the work:
const clock::mode clock::displaying_time = { &clock::change_to<&setting_hours>, &clock::do_nothing, &clock::tick<br> }; const clock::mode clock::setting_hours = { &clock::change_to<&setting_minutes>, &clock::increment_hours, &clock::do_nothing<br> }; const clock::mode clock::setting_minutes = { &clock::change_to<&displaying_time>, &clock::increment_minutes, &clock::do_nothing<br> };
With Functions for States, common behavior is capitalized on more readily than in other designs, whether in the form of doing nothing or changing mode in a consistent fashion. The more that event responses between different modes overlap, the more suitable this pattern becomes.
Conclusion
Patterns become more powerful through diversity rather than through uniformity. They encourage architectural discourse rather than design by diktat. There is often a tension between trying to shoehorn an attractive general solution into the boots of a given language versus the adoption of a more specific native idiom.
In the case of Functions for States, it is not merely a tweaking of Objects for States for C++, it is a different design with different tradeoffs. The same pattern can, for example, be applied conveniently in C#, but not in Java. On the other hand, there are various features of Java that open up many variations of Objects for States that are not convenient for C++ or C# users [7]. Design that tries to gloss over such issues of context is also likely to gloss over effective solutions.
References
[1] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995).
[2] Kevlin Henney. "From Mechanism to Method: Total Ellipse," C/C++ Users Journal C++ Experts Forum, March 2001, <www.cuj.com/experts/1903/henney.htm>.
[3] Kevlin Henney. "From Mechanism to Method: Generic Decoupling," C/C++ Users Journal C++ Experts Forum, November 2001, <www.cuj.com/experts/1911/henney.htm>.
[4] Herb Sutter. Exceptional C++ (Addison-Wesley, 2000).
[5] Kevlin Henney. "From Mechanism to Method: The Safe Stacking of Cats," C/C++ Users Journal C++ Experts Forum, February 2002, <www.cuj.com/experts/2002/henney.htm>.
[6] Kevlin Henney. "Collections for States," Java Report, August 2000, <www.curbralan.com>.
[7] Kevlin Henney. "Matters of State," Java Report, June 2000, <www.curbralan.com>.
Kevlin Henney is an independent consultant and trainer specializing in C++, Java, OO design, patterns, and software architecture. He can be reached at [email protected].
