Sponsored Link •
Bertrand Meyer talks with Bill Venners about Design by Contract and the limits of formal languages for expressing contracts.
Bertrand Meyer is a software pioneer whose activities have spanned both the academic and business worlds. He is currently the Chair of Software Engineering at ETH, the Swiss Institute of Technology. He is the author of numerous papers and many books, including the classic Object-Oriented Software Construction (Prentice Hall, 1994, 2000). In 1985, he founded Interactive Software Engineering, Inc., now called Eiffel Software, Inc., a company which offers Eiffel-based software tools, training, and consulting.
On September 28, 2003, Bill Venners conducted a phone interview with Bertrand Meyer. In this interview, which will be published in multiple installments on Artima.com, Meyer gives insights into many software-related topics, including quality, complexity, design by contract, and test-driven development.
Bill Venners: In your book, Object-Oriented Software Construction, you write, "For a system of any significant size, the individual quality of the various elements involved is not enough. What will count most is the guarantee that for every interaction between two elements there is an explicit roster of mutual obligation and benefits, the contract." What is the contract? Why is it important?
Bertrand Meyer: There are two quite separate points in that extract. The first
point is that when you're building a library, it's not enough to just accumulate good
components. Take a data structure library as an example. You might have excellent classes
for lists, stacks, files, and btrees, but taken together they don't make an excellent library
if they are inconsistent. If they use different conventions, they aren't part of a single
design. For example, when you're putting an element into an array, you might have an
insert operation that takes
is the element and
i is the index. For the hash table class you might have
an insert operation that takes
key is the key and
x is the element. The order of
arguments is reversed. The order of arguments might make perfect sense within each class,
but when you start approaching the library as a whole, you're in new territory each time
you look at a new class. You don't get a feeling of consistency. Instead you get a feeling of
a mess—something that is a collection of pieces rather than a real engineering
design. What we found many years ago when we started focusing seriously on libraries is
that just as much attention has to be devoted to the construction of the library as a whole
as to the construction of the individual elements. That's one point.
The second point pertains to how a library needs to be consistent, how its various elements can fit together like the pieces of a puzzle. It's not just a matter of defining consistent interfaces, order of arguments, things like that. It's also a matter of defining precisely how the various elements are going to communicate with each other and making sure that the conditions of this communication is very precisely defined. This is, of course, where the techniques of Design by Contract come in.