Until the contract is signed, nothing is real.
Contracts are used to guarantee rights and responsibilities: even as someone not studying law, I understand their importance.
If they work so well for human interaction, why not apply them to software interaction?
Every component of a software system does something useful, taking the current state of the program, and then making some kind of statement after.
It does no more and no less than it claims to do, and it does it well. Do only what you have to, when you have to, but do it pragmatically.
By designing software with this concept of contracts, components only take in exactly what they need, promising to do as little as possible so they can do it well:
“If either party fails to live up to the terms of the contract, then a remedy (which was previously agreed to) is invoked — maybe an exception is raised, or the program terminates. Whatever happens, make no mistake that failure to live up to the contract is a bug. It is not something that should ever happen, which is why preconditions should not be used to perform things such as user-input validation.”
A nifty application of real world concepts, one I’ll be sure to use for future work.
Thank you for reading, see you next week!
#PathToSWE
