When not to use design-by-contract

Understanding when not to use a practice is as important as knowing when to use it. In this case, I may disappoint you, as I cannot see a single good reason not to use the design-by-contract ideas presented. The development of object-oriented systems is all about ensuring that objects can communicate and collaborate properly. Experience shows me that making the pre-conditions, post-conditions, and invariants explicit in the code is not expensive and does not take a lot of time. Therefore, I recommend that you consider using this approach. (Note that I am not discussing input validation here, which is fundamental and has to be done whether or not you like design-by-contracts.)

I also want to highlight that design-by-contract does not replace the need for testing. Why? Because, to the best of my knowledge and experience, you cannot express all the expected behavior of a piece of code solely with pre-conditions, post-conditions, and invariants. In practice, I suggest that you design contracts to ensure that classes can communicate with each other without fear, and test to ensure that the behavior of the class is correct.