Emphasizing component development . . . .

More sound advice for the C++ Programmer

reviewed by Conrad Weisert, November 2011
copyright 2012, Information Disciplines, Inc.

If you found the volumes by Scott Meyers and Joshua Bloch valuable in your software development work, you'll want to add this book to your collection. Insiders know, of course, that "API1 Design" just means an emphasis on components rather than complete applications, but anyone who develops applications in an object-oriented language will need to create well-designed components along the way.

Although C++ is in the title, some of the examples use pure, old-fashioned C.  Chapter 5, "Styles" begins with a thorough treatment of the ANSI C API.

Occasional warnings convey a sense of adversarial relationship between the class designer and the class-user programmer. Client programmers will do all kinds of mischief, the author worries, if we don't take strict precautions to protect our classes. There may be organizations where that's a serious ongoing problem; I'm glad I never worked in one. A competent programmer who understands the reasons behind standards of good practice, will gladly cooperate. Perhaps such problems arise with contract programmers, especially in remote countries.

Structure and style

Twelve chapters address major topic areas. The chapters don't form a cumulative body of knowledge, so you can browse selectively depending on your immediate interest.

The writing is generally clear and friendly, and the examples, with a few exceptions, are easy to grasp.

Frequent TIP boxes contain short bits of advice that are easy to remember. Some organizations might want to adopt some of them as standards or conventions.

The typography is attractive and easy to read, except for the too-light monospaced code examples, which are hard to read except in bright light.

Extraneous Systems Analysis material

Sections 4.2, "Gathering Functional Requirements", and 4.3, "Creating Use Cases", are a regrettable distraction. They have little to do with the subject matter of the book, and the techniques they promote are at best controversial.

We welcome, however, the warnings to keep requirements documentation free of internal design and system architecture.

The mysterious Currency class

I was baffled by the Currency class in chapter 5, pages 191-195. I still can't figure out what it's for or what it does, a failing that would have been avoided if the author had followed his own Chapter 9 recommendations for documentation.

At first I thought it must be for amounts of money, a desirable and necessary class in most business applications. But that guess was quickly shot down by the discovery that Currency is closed under multiplication and division! Therefore Currency must be some kind of pure number class lacking any unit of measure.

Further confusion arises from the internal representation initialized from unsigned int. That wouldn't support either amounts of money or anything else I could think of having anything at all to do with currency.

The example was intended to clarify operator overloading but served only to confuse the reader. After careful study, I came away with absolutely no idea what this example is about.

What's the value of an object?

A sure mark of an amateurish class design is an accessor method named getValue(). I first noted it more than a dozen years ago when object-oriented programming was viewed as a novelty, but the practice keeps growing.

It's disappointing to see it from otherwise sensible authors such as Reddy. If programmers think of the value of an object as a property somehow distinct from the object itself, they have already undermined the object paradigm.

The internal representation of objects is supposed to be hidden from users. The name value is perfectly acceptable for a private member data item. But a public getValue() (or worse setValue(exp)) strongly implies manipulation of the private member data item, which then isn't so private after all.


With the exceptions noted above and a few minor quibbles, API Design for C++ is a fine book that will be a valuable addition to any programmer's library.

1—Application Program Interface.


Return to book reviews.
Return to table of contents.

Last modified May 3, 2015 (minor corrections)