Comparison
Design by contractvsLiskov substitution principle
Design by contract
the method states what must be true when you call it and what will be true when it returns, and it checks both.
Specifying a method by a precondition the caller must satisfy, a postcondition the method guarantees, and an invariant the object maintains throughout. It makes the division of blame explicit — a precondition violation is the caller's bug, a postcondition violation is the callee's — which is why it clarifies Liskov substitution so well. Few languages support it directly, so it usually survives as argument checks at the top of a method and assertions in tests.
Full entry →Liskov substitution principle
the subclass threw on a method the parent promised, and every caller written against the parent was suddenly wrong.
The rule that an instance of a subtype must be usable anywhere the supertype is, without the caller having to know. Violations are easy to spot once you know the shape: a subclass that strengthens a precondition, weakens a guarantee, or throws where the parent returned. The square-and-rectangle example is the standard illustration, but the version you meet in real code is a read-only collection that inherits from a mutable one.
Full entry →