Design by Contract

What Hacker News says

1. rramadassOct 2026
   You need to study Bertrand Meyer's "Design by Contract" and "Applying Design by Contract" papers - https://news.ycombinator.com/item?id=48358691

   There are also ways to turn runtime contract checks into static verification checks. See my other comment for details/links - https://news.ycombinator.com/item?id=50108112

   thread
2. rramadassJan 2025
   There is no confusion if you understand that Inheritance is just a "mechanism" to express three (and maybe more) different kinds of "policies" and a single class may implement any or all of them in which case it becomes important to disambiguate which methods/functions express which "policies". There is a abstract concept and a syntactical expression of that concept which needs to be clear in one's mind.

   Again, asserts are just the "mechanism" to express pre/post/inv "policies" in code. Without having an understanding of pre/post/inv from the pov of Hoare Logic, merely using asserts will not give you much benefit. Documentation is quite important here.

   Both the above can be seen in the design of the Eiffel Language where they are integrated into proper syntactical mechanisms. Once you understand the concepts here, you can apply them explicitly even if your language does not support the needed syntax (eg. Contracts). See Bertrand Meyer's OOSC2 for details - https://bertrandmeyer.com/oosc2/ Specifically "Design-by-Contract (DbC)" and "Inheritance Techniques" and "Using Inheritance well".

   Also relevant is my other comment here - https://news.ycombinator.com/item?id=42788947

   Show morethread
3. rramadassNov 2024
   Interesting. I am a fan of DbC (following Meyer's Applying "Design by Contract" - pdf at https://se.inf.ethz.ch/~meyer/publications/computer/contract...) though due to runtime costs (as you point out) i limit it to pre-conditions only everywhere (almost all "policy" part of the code and less on the "mechanism" side) and tighter pre/post-conditions on module boundaries only.

   > programmers won't write them, or will write them incorrectly.

   I think this is a matter of education and discipline and not an argument for not using DbC.

   If it is okay with you could you share your dissertation and maybe highlight the key points which led you to your conclusion of "They are generally useless"? I think it would be useful to know.

   Show morethread
4. rramadassJun 2023
   It is great that you are looking into OOSC2. Yes Meyer is somewhat difficult to read since he is so thorough, precise and detail-oriented that it can become tedious at times. Take your time going through the book to get the big picture of his OO design/implementation arguments rather than the details of the Eiffel language (not necessary during the first pass). It is a huge book so skip topics as needed to focus on the essential concepts.

   You should also look into Meyer's "Design By Contract" technique for writing "correct" OO and other-paradigm programs. This is of great value in real-world programming.

   PS: You might also find another Meyer's book Agile! The Good, the Hype and the Ugly quite instructive - https://learning.acm.org/techtalks/agile

   Show morethread
5. renoxJan 2023
   If I remember well(), the idea between contracts is that they can be enabled at runtime, so very different from UT.

   Also different from assertions in that 'class' invariants applies to every public method of the class.

   : All I know about 'Design by Contract' I learned it in the (very good IMHO) book Object Oriented Software Construction by Bertrand Meyer (he made the Eiffel language).
   thread
6. rramadassMay 2022
   PSA: The above DbC wikipedia page contains a link to the paper Applying Design by Contract by Bertrand Meyer which is THE paper to read to learn usage.
   thread