1 / 9

Computer Science 340 Software Design & Testing

Computer Science 340 Software Design & Testing. Inheritance & Design By Contract. Inheritance & DBC. Our previous treatment of DBC ignored inheritance Now that you’ve had time to internalize DBC, let’s throw inheritance into the mix

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. Inheritance & DBC • Our previous treatment of DBC ignored inheritance • Now that you’ve had time to internalize DBC, let’s throw inheritance into the mix • DBC leads to a better understanding of inheritance, and helps us apply it more effectively

  3. Inheritance & DBC INVA PREA.R A Client R POSTA.R A a = new A(); a.R();

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

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

  6. 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 R’s pre-conditions • PREB.R can place fewer requirements on clients than PREA.R, but not more • PREB.R <= PREA.R • PREA.Rlogically implies PREB.R

  7. 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 R’s post-conditions, but not weaken • POSTB.R can promise more to clients than POSTA.R, but not less • POSTB.R >= POSTA.R • POSTB.R logically implies POSTA.R • B can strengthen A’s class invariants, but not weaken • INVB can promise more to clients than INVA, but not less • INVB >= INVA • INVB logically implies INVA

  8. Another example • Stack example

  9. Liskov Substitution Principle • Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

More Related