The Artima Developer Community
Sponsored Link

Articles Forum
Design by Contract

8 replies on 1 page. Most recent reply: Nov 10, 2004 11:34 PM by Angsuman Chakraborty

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 8 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Design by Contract Posted: Dec 7, 2003 9:00 PM
Reply to this message Reply
Advertisement
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?


Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Design by Contract Posted: Dec 9, 2003 6:27 PM
Reply to this message Reply
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.

David Kempster

Posts: 9
Nickname: dkempster
Registered: Apr, 2003

Re: Design by Contract Posted: Dec 10, 2003 6:44 AM
Reply to this message Reply
> 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.

Jean-Daniel Nicolet

Posts: 13
Nickname: jdnicolet
Registered: Oct, 2003

Re: Design by Contract Posted: Dec 10, 2003 10:52 AM
Reply to this message Reply
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.

graham berrisford

Posts: 1
Nickname: berri
Registered: Dec, 2003

Re: Design by Contract Posted: Dec 16, 2003 3:31 AM
Reply to this message Reply
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.

Irma Brown

Posts: 2
Nickname: freeshape
Registered: Dec, 2003

Web Design by Freeshape Posted: Dec 20, 2003 8:52 AM
Reply to this message Reply
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,

Ken Klein

Posts: 1
Nickname: kenoop
Registered: Feb, 2004

Re: Design by Contract Posted: Feb 12, 2004 1:30 PM
Reply to this message Reply
> 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.

Gerardo

Posts: 1
Nickname: montecrist
Registered: Oct, 2004

Re: Design by Contract Posted: Oct 20, 2004 12:58 PM
Reply to this message Reply
Pleas read OOSC 2edition about SCOOP.

Angsuman Chakraborty

Posts: 19816
Nickname: angsuman
Registered: Dec, 2003

Re: Design by Contract Posted: Nov 10, 2004 11:34 PM
Reply to this message Reply
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/

Flat View: This topic has 8 replies on 1 page
Topic: C++ Coding Standards Previous Topic   Next Topic Topic: A Deeper Look at Metafunctions

Sponsored Links



Google
  Web Artima.com   

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