160 likes | 176 Views
Computer Science 340 Software Design & Testing. Inheritance & Design By Contract. Informal Definition of a Software Class. A class is a collection of members (variables and methods) that is grouped together to form a data type
E N D
Computer Science 340Software Design & Testing Inheritance & Design By Contract
Informal Definition of a Software Class • A class is a collection of members (variables and methods) that is grouped together to form a data type • Classes represent types of things, real or imagined, that can be represented in a computer program • Classes are used to generate objects (instances) of a particular type
A More Formal Definitionof a Class • For any class “G” there is a predicate G(x) where x is a member of the Universe. • G(x) is true if x is a member of “G”, otherwise it is false. • The n properties of the class G are: PG (x), PG (x), …, PG (x) • Every member of G must have these properties G(x) PG (x) PG (x) … PG (x) 1 2 n 1 n 2
Informal Definition of a Subclass • A subclass is a specialized version of it’s super (parent) class • Subclasses contain all of the non-private members and the private variables of their parent class through inheritance • Subclasses may change inherited methods • Subclasses may add members that don’t exist in their parent class
Properties of Subclass S of Parent Class G S(x) G(x) and G(x) PG (x) PG (x) … PG (x) Therefore, by transitivity of implication S(x) PG (x) PG (x) … PG (x) • This is the Substitutability Law • Every member of a specialization must satisfy every property of a generalization • In other words, every member of a specialization cannot contradict the properties of the generalization 2 n 1 1 2 n
More Properties of S • S can have additional properties: PG (x), PG (x), …, PG (x), PS (x), PS (x), …, PS (x) • Because of the substitution law none of S’s additional properties can contradict any of the generalization’s properties • Contradiction only occurs if the generalization’s properties are weakened • Thus, under specialization, they may only be strengthened 1 2 n 1 2 m
Inheritance & DBC • Our previous treatment of DBC ignored inheritance • DBC leads to a better understanding of inheritance, and helps us use it correctly
Inheritance & DBC INVA PREA.M A Client M POSTA.M A a = new A(); a.M();
Inheritance & DBC INVA PREA.M A Client M POSTA.M INVB ? PREB.M B M POSTB.M A a = new B(); a.M();
Specialization • Specialization means that all the properties guaranteed for the generalization (partially or totally defined through pre- and post-conditions and class invariants) must be preserved in the specialization.
Specialization • Furthermore, substitutability must be guaranteed. • That is, instances of the specialization must be able to be used anywhere an instance of the generalization can be used. • For example, given that the class S is a specialization of the class G, and g is a variable of type G, then g = new S() is legal. • Known as the “Liskov Substitution Principle”
Inheritance & DBC • Conceptually, B’s implementation must honor A’s contract; otherwise, clients will break when using a B instead of an A • B can provide a “better” implementation than A, but not a “worse” one • What do “better” and “worse” mean? • Square root example
Subclasses Can Be Less Strict, But Not More Strict • B can be less strict on clients than A, but not more strict • B can weaken M’s pre-conditions • PREB.M can place fewer requirements on clients than PREA.M, but not more • PREA.Mlogically implies PREB.M • Another way to say it: • Satisfying A’s pre-conditions must implicitly satisfy B’s pre-conditions (because B may have fewer but not more)
Subclasses Can Do More,But Not Less • B’s behavior must be consistent with A’s contract • B can do better than A, but not worse • B can strengthen M’s post-conditions, but not weaken • POSTB.M can promise more to clients than POSTA.M, but not less • POSTB.M logically implies POSTA.M • B can strengthen A’s class invariants, but not weaken • INVB can promise more to clients than INVA, but not less • INVB logically implies INVA • Another way to say it: • I may get more by calling the method on a B instead of an A, but I won’t get less (postconditions and invariants are about what WILL happen, they don’t try to enumerate everything that WON’T happen)
Another Example • Stack example
Liskov Substitution Principle • Let q(x) be a property provable about objects x of type G. Then q(y) should be true for objects y of type S where S is a subtype (or specialization) of G.