reviewed by Conrad Weisert, November 2011
copyright 2002, 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.
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.
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.
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.
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 viewd 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 somwhow 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()) strongly implies manipulation of the private
member data item, which 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.
Recommended
Return to book reviews.
Return to table of contents.
Last modified Novembe 21, 2011