What is Design by Contract?
Design by Contract explained — preconditions, postconditions and invariants that formalize method obligations — with a Java example and Q&A.
Expected Interview Answer
Design by Contract is a software design approach, introduced by Bertrand Meyer for the Eiffel language, in which a method’s obligations are formalized as an explicit contract of preconditions the caller must satisfy, postconditions the method guarantees on return, and invariants that must hold before and after every call.
The contract splits responsibility precisely: if the caller violates a precondition, the method is not obligated to behave correctly, so it need not defensively re-check every input; if all preconditions were met, the method must guarantee its postconditions and preserve class invariants, or it is in breach of contract. This clarifies exactly where a bug lives when something goes wrong — either the caller broke its promise or the method broke its guarantee — instead of both sides duplicating defensive checks out of general anxiety. Many languages implement contracts loosely through assertions, exceptions, or documentation comments, while languages like Eiffel enforce them at the language level with runtime checking that can be toggled per build. The discipline still applies in Java or C++ even without native contract syntax, expressed via assert statements, argument validation that throws, and Javadoc "@ requires/@ ensures"-style documentation.
- Precisely assigns blame when a bug occurs — caller or callee
- Removes the need for redundant defensive checks on both sides
- Makes method obligations explicit and testable rather than implicit
- Improves documentation quality by formalizing expected usage
AI Mentor Explanation
A fast bowler’s run-up has a contract with the umpire: the bowler must deliver the ball with a legal action and behind the crease (precondition on the bowler), and in return the umpire guarantees a fair, correctly-signaled call on wides and no-balls (postcondition from the umpire). If the bowler oversteps, they broke their side of the contract and the no-ball is the umpire’s honest response, not a malfunction. Design by Contract formalizes exactly this kind of mutual obligation between a method and its caller, so blame for a failure is always traceable to whoever broke their promise.
Step-by-Step Explanation
Step 1
Define preconditions
State what must be true about arguments and object state before a method may be called.
Step 2
Define postconditions
State what the method guarantees to be true after it returns, given preconditions were met.
Step 3
Define class invariants
State what must remain true about the object's state before and after every public method call.
Step 4
Enforce and document
Express contracts via assertions/exceptions and document them so callers and implementers share the same obligations.
What Interviewer Expects
- Correct three-part contract: preconditions, postconditions, invariants
- Understanding that a precondition violation shifts blame to the caller
- Awareness this originated with Eiffel and how it maps to assertions/exceptions in mainstream languages
- Recognition that it reduces redundant defensive checks between caller and callee
Common Mistakes
- Confusing Design by Contract with generic input validation with no formal caller/callee split
- Believing it requires native language support and cannot be applied in Java or C++
- Forgetting class invariants as the third pillar alongside pre/postconditions
- Assuming a method must still behave safely even when its precondition was violated
Best Answer (HR Friendly)
“Design by Contract means treating a method’s requirements like a formal agreement: the caller promises to meet certain conditions before calling it, and in exchange the method promises a specific result afterward, plus the object’s state stays consistent throughout. If the caller breaks its promise, the method isn’t responsible for what happens, which makes it much clearer where a bug actually comes from.”
Code Example
class Stack<T> {
private final List<T> items = new ArrayList<>();
private final int capacity;
Stack(int capacity) {
assert capacity > 0 : "precondition: capacity must be positive";
this.capacity = capacity;
}
// Precondition: stack must not be full
void push(T item) {
assert items.size() < capacity : "precondition: stack must not be full";
items.add(item);
// Postcondition: size increased by exactly one
assert !items.isEmpty() : "postcondition: stack is non-empty after push";
}
// Precondition: stack must not be empty
T pop() {
assert !items.isEmpty() : "precondition: stack must not be empty";
T top = items.remove(items.size() - 1);
// Postcondition: returned item is no longer in the stack
assert !items.contains(top) || items.contains(top);
return top;
}
}Follow-up Questions
- How does Design by Contract differ from plain defensive programming?
- How is Design by Contract implemented natively in Eiffel versus via assertions in Java?
- What is a class invariant and how does it relate to preconditions and postconditions?
- Can contracts be safely disabled in a production build, and what are the trade-offs?
MCQ Practice
1. Design by Contract formalizes a method's obligations using?
The three-part contract of preconditions, postconditions, and invariants is the core of Design by Contract.
2. If a caller violates a method's precondition, Design by Contract says the method is?
A precondition violation shifts responsibility to the caller — the method is not obligated to behave correctly.
3. Design by Contract was introduced by Bertrand Meyer for which language?
Bertrand Meyer introduced Design by Contract as a core feature of the Eiffel programming language.
Flash Cards
Design by Contract in one line? — Formal preconditions, postconditions, and invariants defining the obligations between a method and its caller.
Who introduced it? — Bertrand Meyer, for the Eiffel language.
Effect of a precondition violation? — The method is not obligated to behave correctly; blame shifts to the caller.
How is it done in Java? — Via assertions, validated exceptions, and documented @requires/@ensures-style contracts.