The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Designing Contracts and Interfaces
A Conversation with Scott Meyers, Part II
by Bill Venners
December 23, 2002

Page 1 of 4  >>


Scott Meyers, C++ expert and author of numerous books, including Effective C++, talks with Bill Venners about interface contracts and designing minimal and complete interfaces.

Scott Meyers is one of the world's foremost experts on C++ software development. He wrote the best-selling Effective C++ series (Addison-Wesley): Effective C++ (1997), More Effective C++ (1995), and Effective STL (2001); wrote and designed the Effective C++ CD; is consulting editor for Addison-Wesley's Effective Software Development Series; and is a member of the advisory board for Software Development magazine. A programmer since 1972, Meyers holds an M.S. in computer science from Stanford University and a Ph.D. from Brown University.

In this four-part interview, which is being published in weekly installments, Meyers gives his views on many object-oriented design topics:

Contracts and Private Data

Bill Venners: Much of my object-oriented design philosophy originally came from your book Effective C++, but since then I've somewhat changed the way I think about design. I'm curious how your ideas of object-oriented design may have changed or evolved since you wrote Effective C++.

One way my design sense has changed is that I now think of design to a great extent in terms of contracts. Most people agree that private data is a good thing. In your Effective C++ guideline, "Avoid data members in the public interface," you give three justifications for private data. You say private data provides consistency, because every accessible member is always a function. You mention private data gives you control over accessibility. Private data can, for example, be read only. But the "big gun," using your words, is that private data provides functional abstraction. I could, for example, replace a function that returns a private data member with a computation that calculates the same value.

Like a good object-oriented programmer who had read your book, I had always tried to make my data private. Making data private was the right thing to do. Nevertheless, in a few cases I had to make some data public.

For example, the Jini API contains a class Entry, whose subclasses form tuples of objects that you can write into a JavaSpace or Jini lookup service. The objects that comprise the tuple are held in the Entry's public fields. Although making non-final fields public is generally a bad idea, in the Entry case there is a good design justification for public fields. All those fields must be readable and writable, in effect public, to facilitate matching serialized forms of individual fields.

On one occasion I designed several Entry subclasses that contained public fields and at least one method. My experience with these Entry classes showed me that when data is public, methods can't promise anything.

I had come to view object-oriented systems as a collection of classes, each of which takes on a certain set of responsibilities through its interface contract. These contracts make promises. If you pass an object to the add method of a Set, for example, that object should show up when you iterate over the Set. If the data of that Set is public, however, someone could actually remove that object without the Set class knowing. So if the data is public, the class can't make any firm promises in its contract.

Scott Meyers: Exactly. That's completely true. And if I didn't mention that in the book, shame on me.

Page 1 of 4  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use