1 / 16

Computer Science 340 Software Design & Testing

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

jglover
Download Presentation

Computer Science 340 Software Design & Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Science 340Software Design & Testing Inheritance & Design By Contract

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Inheritance & DBC • Our previous treatment of DBC ignored inheritance • DBC leads to a better understanding of inheritance, and helps us use it correctly

  8. Inheritance & DBC INVA PREA.M A Client M POSTA.M A a = new A(); a.M();

  9. Inheritance & DBC INVA PREA.M A Client M POSTA.M INVB ? PREB.M B M POSTB.M A a = new B(); a.M();

  10. 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.

  11. 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”

  12. 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

  13. 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)

  14. 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)

  15. Another Example • Stack example

  16. 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.

More Related