The Artima Developer Community
Sponsored Link

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

<<  Page 2 of 4  >>


Thinking in Contracts

Bill Venners: What about contracts in general? To what extent do you find it helpful to think in terms of contracts when designing? I don't mean Bertrand Meyer's Design by Contract, the preconditions, postconditions, and invariants of the Eiffel language. I mean thinking of design as defining interfaces that are contracts that make promises to clients. Do you think that's helpful?

Scott Meyers: I do. I think a contract is inherent in an interface. An interface says, basically, I will do this if you do this. If you give me this information, I will perform this computation. If you do that, I will have this side effect. The contract says, if you call me and give me this stuff, and as long as you hold up your end of the bargain, this is what I promise in return. I think that does make a lot of sense, because contracts really are just specifications.

Bill Venners: I agree with you, but not everyone does. I know many developers who don't think in those terms. It's not the way they approach design, or the way they put their systems together. They put the pieces together to make the system work, but they don't find it helpful to think in terms of formal contracts for each piece.

Scott Meyers: I don't think you can deal with software systems without having some notion of an agreement between the caller and the callee. You must have some agreement about who has to do what and who will do what in response to what. Once you've reached that point, it's just a matter of naming that understanding. I don't happen to use the word "contract," but I'm comfortable with it. I think it is a perfectly natural word to apply, though it does carry a bit of the Design by Contract baggage.

<<  Page 2 of 4  >>

Sponsored Links

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