|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Summary
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:
interface, and points out a schism in
the focus of the C++ and other prominent development communities.
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.
|
Sponsored Links
|