Questions: On Design By Contract Inheritance Issue..?
By Angsuman Chakraborty, Gaea News NetworkWednesday, November 10, 2004
Questions for all Design By Contract practitioners -
If my class ( E ) implements three interfaces (A, B & C) and extends class D, each with its own pre-conditions and post-conditions and some invariants.
Class E also has few pre-conditions and post-conditions and some invariants.
Pre-conditions can be weakened. So presumably it is an OR clause binding all the pre-conditions of A, B, C, D & E. The question is in what order?
Post-conditions can be strengthened.
So presumably I should AND all the pre-conditions of A, B, C, D & E. Is that correct?
Nothing I could find aboout inheritance of Invariants. How would you join all the invariants of A-E classes? AND clause?
Looking forward for your responses….
|
November 11, 2004: 5:10 am
The preconditions and postconditions are associated with methods. Any given method in Java can only be inherited from a single interface or class, so there is no question about ANDing and ORing. When an overriding method modifies the precondition or postcondition of its parent method: For preconditions, the parent precondition is tested first. If that precondition fails, then the precondition of the current class’s method is tested, and if either succeeds and if the call was from outside the current class then the class invariant is tested. For postconditions, the parent postcondition is tested first. If that postcondition succeeds, then the postcondition of the current class’s method is tested, and if that succeeds and if the call was from outside of the current class then the class invariant is tested. For constructors, however, the rules are different. Only the precondition is tested on entry, not the class invariant because the point of the constructor is to establish the class invariant. On exit, the class invariant is tested first, and if that succeeds then the postcondition is tested. Note: constructors are not inherited, they’re chained; inheritance rules don’t apply. The invariant for a class is the combination of its class invariant and the class invariant(s) for its parent class(es). All invariants must always be true, so the ordering is somewhat irrelevant. Still, Eiffel specifies the following order: this class’s invariant, then parent invariants, then invariants associated with any methods redefined as attributes (something you can’t do in Java). |
Doug