To illuminate the purpose of this book, let’s compare the evolution of data structures with that of design patterns.
Early books on data structures described such generally useful structures as stacks and queues, using prose, diagrams, and notations. These descriptions included the abstract structure, thoughts on when it was appropriate, and an informal recipe for implementing concrete instances of the structure. For example, if you want a stack, you might use an array and a counter. At the programming language level, programs from this period were nothing but big blobs of arrays and scalars. Only comments or variable names would clue the human reader in to the underlying abstractions: this array and this scalar form a stack, whereas this other array and these other two scalars form a queue.
As programming and programming language design advanced, this situation changed. Today, a program has variables of type “stack,” with a single definition specifying how a stack is represented. The representation is generally packaged into a library; if the representation’s design can’t be equally suitable for all applications, the library provides control parameters that allow you to “tune” it for your circumstances.
Books on design patterns have largely recapitulated the style of early texts on data structures. They present generally useful patterns such as Visitor or Abstract Factory, with descriptions and diagrams, not only of the pattern per se, but also of how you can hand craft specific instantiations in your programs. A contemporary C++ program is, at the programming language level, a big blob of classes and virtual methods, with only suggestive names and comments to let the reader know what elements form an instance of the Visitor pattern, and what others form an Abstract Factory.
It should be obvious what the next evolutionary step is. Concrete instances of design patterns need to be abstracted, so that they can take tangible, programming-language-supported form and be packaged into libraries, with tunable representation choices. This is Alexandrescu’s goal.
The conceptual tools Alexandrescu uses are abstraction and recursion, while the primary language tool is C++’s template facility. The conceptual material should be familiar to a well-educated computer scientist, but will be mind-expanding for most programmers. The template facility is a favorite example for both those who love C++ and those who hate it, and both camps will find ammunition in Alexandrescu’s book. However, this is beside the point, because the intended audience consists of those already committed to using C++, who want to make the best of it. For these pragmatists, the issue is that Alexandrescu uses more of the language than many compilers will compile. Regarding audience, I disagree with Alexandrescu’s preface: “A degree of familiarity with templates” is mandatory, not just “desirable.”
Books, like programs, can be reviewed for quality at both the macroscopic “design” level and the detailed “coding” level. At the macroscopic level, Alexandrescu does a competent job of achieving his goals. The biggest complaint I have at this level is that he completely fails to tie together the chapter on the Visitor pattern with the following chapter on multimethods. Actually, visitors are simply one variation on the general multimethod theme, and the form of double dispatch shown in the Visitor chapter (two single dispatches, each done using virtual methods) is an alternative to the following chapter’s techniques. Failure to point this out is a significant flaw in an otherwise well-designed book.
Although the “design” of the book is generally high quality, the same cannot be said for the “coding.” The book is riddled with errors. More seriously, there is still no errata list, months after the book was published. Not only could I not find one on the Web: an email query to the author revealed that he had not yet put one together, but rather planned to do so at some unspecified point in the future. Nor is there any obvious channel for reporting errors, such as a Web form or a published email address. This lack of concern for quality is unacceptable. No author of a technical book can avoid errors, but we all can, and should, take responsibility for our errors becoming known. I admit that the vast majority of the errors I found were either inconsequential to the main thrust of the book or obvious enough that a careful reader could spot the problem and figure out the correction. However, for readers who are on the edge of their comfort zones, even these “obvious” errors will pose a hardship.
For advanced C++ programmers, familiar with templates and comfortable debugging someone else’s minor but frequent errors, I can recommend Alexandrescu’s book as a good illustration of how design pattern instantiations can be abstracted into libraries. If your compiler can cope with Alexandrescu’s library (Loki), you will also have a broadly useful tool.
