[Home Page] - [Reviews Main]

Multi-Paradigm Design for C++ by James O. Coplien Highly Recommended

ISBN: 0-201-82467-1       Publisher: Addison-Wesley       Pages: 280pp       Price: £23.99

Categories:   advanced c++     object oriented

Reviewed by Ian Bruntlett in Overload OL33 (Aug 1999)

This book doesn't want to be a "method book". Sometimes, in its attempts to avoid that label, it obscures its own message. At times, you have to read carefully, review previous chapters and hope that later chapters will make things clearer. Code fragments are scattered about the book to provide examples. I'd like to have seen some complete examples.

"Multi-Paradigm Design" is a technique that looks beyond the problem being solved. This broader vision is then split into areas of specialisation or interest (domains). It even considers the programming language used a domain - a whole chapter is devoted on performing an analysis of the facilities provided by C++. There are a couple of omissions - multiple inheritance, namespaces, exceptions and STL weren't considered. Section 6.3 (Data) also overlooked unions and dynamically allocated data (pointers to structs or arrays). Despite these omissions, after reading that chapter, I had a much better grasp of how C++ fits together. I got my money's worth from that chapter alone. I now want to read Coplien's solution domain analyses on other languages.

It is widely accepted that a good system is weakly-coupled and highly cohesive. The world that these good systems have to work is complicated, inter-connected and just plain messy. Instead of "real world" analysis producing neatly packaged domains, the final analysis often shows interdependent domains. A given problem area will typically have several applications (a family of applications) produced for it.

If the initial analysis only considers the requirements of the first application, the resulting abstractions, modules and libraries will depend on good luck when code re-use is considered. This is why multi-paradigm design produces application frameworks, and, given the chance, application oriented languages (AOL). Designing and implementing a framework, then producing the first application, is harder work than just producing the first application from scratch. From what I've seen so far, this seems to be an ideal use for C++ object-oriented and generic programming facilities. Building a framework is a big job. This book goes into detail about it - a bibliography is provided in case more detail is required.

As well as frameworks, this book looks at how patterns can be mixed with multi-paradigm design (a partial solution domain analysis is provided and will help me apply patterns). This is a rich topic, with potential for more articles.

Multi-paradigm design begins with the business domain being identified - this usually involves taking a broader view of the problem being solved. A common ground for discussion is created (a domain dictionary / vocabulary).

Then the designer's experience and intuition is called upon to split the business domain into sub-domains. This is a topic I will have to read more about.

Sub-domain analysis is a fundamental part of multi-paradigm design. It may look a little complicated but it isn't. It is simply a matter of finding the common features (chapter 2, commonality analysis) and applying variability analysis (chapter 3) to discover where the differences lie.

Moving on to implementation, a C++ language feature is chosen based on the results of commonality analysis, variability analysis and the requirements for binding time, instantiation and default values (these requirements being covered by chapter 6 Solution Domain analysis). The process of choosing a C++ feature is called transformational analysis here - phrases like this make a glossary necessary.

A spectrum complexity is covered - from simple systems (Single domain, Single paradigm) through to complex systems (co-dependent domains, design patterns used to break circular dependencies). This is a good book that should be read by intermediate to advanced C++ developers.

If you don't have time to read it then at least have a quick look through. You're bound to find a chapter that attracts your attention and enlightens you.

Comment: A note from Kevlin Henney. On Multi-Paradigm Design (MPD) and patterns I feel that the book actually says more about it than Ian is hinting at here. Whilst I don't particularly agree with all of Coplien's observations, his view is much more that patterns (a la GOF) often cover exceptions to conventional design practice, ie they deal with negative variability. This is where the Bridge example fits in. And hence why he views the GOF patterns as adjuncts to OOD, rather than as a necessary part of its core. For many of the rest, he reduces GOF patterns to MPD concepts, in other words they simply converge and become names for common products of MPD. He also draws attention to differences in a patterns based development approach and MPD based development.