Bertrand Meyer talks with Bill Venners about Design by Contract and the limits of formal languages for expressing contracts.

Read this Artima.com interview with the creator of Eiffel:

http://www.artima.com/intv/contracts.html

What do you think of Bertrand's comments?

I think that Meyer is overstating the differences beween Design by Contract (DBC) and using asserts and throwing exceptions. The main advantage of DBC is bettter syntax and that pre, post, and invarients are inherited and therefore don't need restating in a derived class. I don't get why Meyer doesn't just say this, if DBC wasn't so shrouded in mystry people would use it more.

> I think that Meyer is overstating the differences beween
> Design by Contract (DBC) and using asserts and throwing
> exceptions. The main advantage of DBC is bettter syntax
> and that pre, post, and invarients are inherited and
> therefore don't need restating in a derived class. I don't
> get why Meyer doesn't just say this, if DBC wasn't so
> shrouded in mystry people would use it more.


I agree with your main advantages but there is also the very important difference of documentation and self reveling code. If you have it as explicit pre and post conditions and you think of that as part of the interface there is a big payoff. Assertions with thrown exceptions does not do this for you.

Also, as with any programming construct you want to separate the abstract mechanism from the implementation. Dealing with assertions and exceptions is dealing with the implementation and not the abstracted concept. DBC is the abstracted concept. It may be implemented with an assertion and exception mechanism in a given language.

One little additional remark about pre- and post- conditions. Bertrand Meyers mentioned the possibility of calling boolean functions from within condition checking code in the context of graph algorithms. The mere fact of being able to theoretically invoke some function to check a condition is not sufficient to make the use of pre-conditions usable.

The big question behing usability is also complexity. If the checking condition has a bigger computational complexity (in the information theoretical sense) that the routine it is supposed to check, then it is practically unsable. A famous example was known in C++ some years ago, with the Rogue Wave Tools.h++ library, who had post-condition checks in debug mode in every significant method, so in that sense it fully implemented the pre- and post-condition policy advocated by M. Meyer. The library offered the notion of a sorted container and the insertion operation post-condition implemented just what Bertrand Meyer mentioned in the article, that is the check that all previous elements were still there in the same relative order. The only problem is that the insertion routine had a linear complexity, whilst the post-condition check was quadratic. The net effect was that we could not use the debug version of the library on this particular container and had to turn off the debug mode explicitly, because turning to debug mode was unacceptybly slow when a lot of elements was involved.

Even more seriously, in the domain of graph theory, most intersting pre- and post-conditions are simply not testable at all, mainly for complexity reasons. There may be for example no better checking algorithm than one with n-p complete complexity. If I say for example that the pre-condition is that my graph should have a Hamiltonian cycle, then I simply just can't check it in a reasonable amount of time, although the service offered by my method could be very simple. Even in the case where I would be ready to take the additional running time complexity into account, it is probably still not usable, because debugging the checking routine would be way much more complex than the simple service I'm attempting to check in the first place.

I'm personnally totally convinced of the effectiveness of pre- and post- conditions in the drastic reduction of debugging effort, and I use it consistently since many years and it really pays off. I'm just attempting to emphasize that it is not always applicable in practice. Most of the time, the pre- and post- conditions are simple enough to be easily implemented and the little extra effort is worth the trouble. But sometimes, you just can't use it. It's not a panacea.

We have to spend time in the classroom destroying students' faith in Design by Contract, among sother academic software engineering concepts.

The idea that clients evaluate all the preconditions of a server before invoking it, and the server is therefore not responsible for doing this, is the reverse of what is needed in programmning a multi-user (perhaps multi-channel) database transaction processing system. It tends to create wasteful duplication of code, and/or performance problems, and/or increase the risk of system failure.

Freeshape offers award winning web design and development services. Best in class content management solutions, website maintenance, branding & identity, graphic design, Flash animation. Design without limits!

www.freeshape.com

Alabama, California, Virginia, Washington, DC,

> The idea that clients evaluate all the preconditions of a
> server before invoking it, and the server is therefore not
> responsible for doing this, is the reverse of what is
> needed in programmning a multi-user (perhaps
> multi-channel) database transaction processing system. It
> tends to create wasteful duplication of code, and/or
> performance problems, and/or increase the risk of system
> failure.

I've seen it stated many times that DbC is not meant to be a substitute for defensive programming. So the cases you describe would still need to be checked by the delivered code. However, there will always be many preconditions that have no need to be checked in delivered code--but that are of value during testing. So I guess I'm saying, don't toss the baby out with the bath water.

Pleas read OOSC 2edition about SCOOP.

I have few questions on Design By contract wrt. inheritance. I have posted the questions on my blog - http://blog.taragana.com/index.php?p=74
I would very much appreciate if you could please post your responses/solutions to the questions on my blog or email me.

Thanks,
Angsuman
http://blog.taragana.com/