Browse Books

Reviewer: Jeffrey B. Putnam

“Multi-paradigm” has usually been used to mean incorporating rather different models of programming—for example, functional, logic, and object-oriented programming—in a single project. In contrast, this book uses the term rather differently. Here it seems to mean “using all the features of C++ in a project.” Coplien specifically mentions things like “inheritance,” “procedural programming,” and “templates” as the “multi-paradigms” of interest. Those seeking information on what has been referred to elsewhere as multi-paradigm programming will therefore not find this book to be of much interest. The book is very specific to implementation techniques in C++<__?__Pub Fmt kern Amount="0.5pt">—predominantly templates and the inheritance structure. This intense focus on C++ and its features seems particularly odd in light of the author's statement in the preface that “multi-paradigm design tries to dig deeper than any single technology or technique.” So, who would be interested in this book__?__ It will probably not appeal to anyone doing high-level domain analysis and design, since the focus is very much on the programming level. It will probably not interest programmers and designers who have a lot of experience. They will have already found their own idioms and methods for solving the kinds of problems considered. It will probably not interest people who are programming in other languages, because the techniques discussed are almost exclusively specific to C++. Indeed, the constructs used in many of the code examples have no close analogs in other languages. The book will certainly not interest novices or students. It assumes readers have a considerable amount of programming experience; specifically, ex<__?__Pub Caret>tensive programming experience in C++ using templates is assumed. I have been programming in C++ (at least off and on) for quite a few years, and I found many of the examples confusing. Would students find them any less so__?__ The people most likely to get something out of this book are dedicated C++ programmers who are no longer novices but not yet experts. These readers have reached the point at which the basic language does not provide quite the expressiveness needed, but are not yet experienced enough to find solutions on their own. The book does provide some interesting and informative reading. The discussion of variability analysis is good. An interesting extended example presented in the chapter “Codependent Domains” shows a cute trick that might be of use to C++ hackers. The book's flaws seem to outweigh its virtues, however. Contravariance is discussed briefly and confusingly. One section contrasts a method with a “functor,” but the term “functor” is not indexed or otherwise described except implicitly, with a brief snippet of code; it certainly does not seem to mean what it does in ML or Prolog. It is entirely possible that I have missed the point somewhere, despite a close reading, some intense browsing through the book, and some more focused checking into specific sections. But even after all that, I am not entirely sure what the book is about. It is certainly about C++ templates and C++ inheritance. It includes a bit about variability analysis. It is less surely about design, except as design is reflected in a C++ implementation. The book would have been much stronger had the techniques and discussions been more general. The same kinds of problems occur in other languages, but the different semantics of other languages change the problems slightly and the solutions greatly. If there is any generality to “multi-paradigm” design, surely it can be discussed and illustrated in a more general context.

Reviewer: Ronald Thomas House

This is an intriguing book about design principles as applied to projects programmed in C++. As such, it contains elements that are more specific than is usual for texts on analysis or design. The author explains his own theories on design methodology, which are based on employing multiple paradigms (as opposed to some popular methods that are explicitly single-paradigm, commonly using the object-oriented paradigm). The book's topics include the need for many paradigms; commonality analysis; variability analysis; application domain analysis; object-oriented analysis; solution domain analysis; methods for mixing paradigms; and the use of patterns. “C++” is in the title because of the author's attraction to the capabilities of C++ as a language that is not limited to object-oriented programming styles, and, indeed, the text includes code sketches (but not complete programs) in C++. While the book is not limited to C++, it may be overlooked by some people who would find material of interest here, in particular, managers who might feel disposed to delegate language issues to subordinates. The author's theories may well be of wider interest than the title of the book would indicate; he covers a wide range of topics that are relevant to (for example) programmers, analysts, designers, theoreticians, and language designers. The text does not lend itself easily to a short summary; it resembles an apprenticeship in the author's methods, and I suspect a fair evaluation of their worth could only come from trying them out in a real situation. However, I immediately noticed the author's charming practice of putting nuggets of sound advice in aphorisms that are then blended into the text without any highlighting whatso<__?__Pub Caret>ever. For example, on page 46, he writes, “I will be quick to point out that data design often does line up with good object partitioning. The point I am trying to make here is that we shouldn't presume such alignment. Rather, we should come by it honestly.” This is easy to miss, and easy to dismiss as a general motherhood statement, but its merit is revealed by the general horribleness of so many systems that pass themselves off as “object-oriented.” On page 76, buried as an entry in a table, is the statement “Debugging traps should be present for in-house development and should remain permanently in the source.” How often have we seen exactly the opposite (terrible) advice lead to the public release of products that crash with segmentation faults rather than assertion failure messages__?__ Inheritance leads to problems when “negative variability” is involved, such as when a square, which is a particular type of rectangle, loses an independent parameter (length and breadth being conflated). The author gives one of the best analyses I have seen of this kind of problem, illustrating with the case of numbers subtyping to complex, subtyping to integer. He has motivated me to study his ideas on this issue in greater depth. The wide range of issues covered makes it hard to confidently promise that the entire book is sound; in some sense, it leaves the impression of asserting rather than proving the case. All I can say is that, in the topics covered that I have investigated, I agree with the author's philosophy, and where I have not, his assertions nevertheless look plausible. I recommend that you find out for yourself. The book is, at the very least, well written and makes an enjoyable and challenging read.