Hoofdstuk 6 - Design By Contract Flashcards
Why are redundant checks not a good way to support Design by Contract?
- extra complexity: extra code that needs to be verified as well
- performance penalty: extra execution time
- wrong context
You’re a project manager for a weather forecasting system, where performance is a real issue. Set-up some guidelines concerning assertion monitoring and argue your choice
Rule of thumb: at least monitor pre-conditions. Make sure that verifying pre-conditions is fast! Do not rely on switching off monitoring to gain efficiency. Profile performance to see where you loose efficiency.
If you have to buy a class from an outsourcer in India, would you prefer a strong precondition over a weak one? And what about the postcondition?
A combination of both: Strong preconditions make a component more reusable, weak precondition will mean less effort to reach the state where you can call the method.
Do you feel that design by contract yields software systems that are defect free? If you do, argue why. If you don’t, argue why it is still useful.
There will be less defects, but it won’t be defect free.
How can you ensure the quality of the pre- and postconditions?
Make sure they are reasonable
Why is (consumer-driven) contract testing so relevant in the context of micro-services?
Assume you have an existing software system and you are a software quality engineer assigned to apply design by contract. How would you start? What would you do?
