Chapter16 - 16 Inheritance techniques From the last two...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
16 Inheritance techniques F rom the last two chapters we have learned to appreciate inheritance as a key ingredient in the object-oriented approach to reusability and extendibility. To complete its study we must explore a few more facilities — something of a mixed bag, but all showing striking consequences of the beauty of the basic ideas: • How the inheritance mechanism relates to assertions and Design by Contract. • The global inheritance structure, where all classes fit. • Frozen features: when the Open-Closed principle does not apply. • Constrained genericity: how to put requirements on generic parameters. • Assignment attempt: how to force a type — safely. • When and how to change type properties in a redeclaration. • The mechanism of anchored declaration, avoiding redeclaration avalanche. • The tumultuous relationship between inheritance and information hiding. Two later chapters will pursue inheritance-related topics: the review of typing issues in chapter 17 , and a detailed methodological discussion of how to use inheritance (and how not to misuse it) in chapter 24 . Most of the following sections proceed in the same way: examining a consequence of the inheritance ideas of the last two chapters; discovering that it raises a challenge or an apparent dilemma; analyzing the problem in more depth; and deducing the solution. The key step is usually the next-to-last one: by taking the time to pose the problem carefully, we will often be led directly to the answer. 16.1 INHERITANCE AND ASSERTIONS Because of its very power, inheritance could be dangerous. Were it not for the assertion mechanism, class developers could use redeclaration and dynamic binding to change the semantics of operations treacherously, without much possibility of client control. But assertions will do more: they will give us deeper insights into the nature of inheritance. It is in fact not an exaggeration to state that only through the principles of Design by Contract can one finally understand what inheritance is really about.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
INHERITANCE TECHNIQUES § 16.1 570 The basic rules governing the rapport between inheritance and assertions have already been sketched: in a descendant class, all ancestors’ assertions (routine preconditions and postconditions, class invariants) still apply. This section gives the rules more precisely and uses the results obtained to take a new look at inheritance, viewed as subcontracting. Invariants We already encountered the rule for class invariants: The parents’ invariants are added to the class’s own, “addition” being here a logical and then . (If no invariant is given in a class, it is considered to have True as invariant.) By induction the invariants of all ancestors, direct or indirect, apply. As a consequence, you should not repeat the parents’ invariant clauses in the
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 10/02/2009 for the course CS 4376 taught by Professor Christeansan during the Spring '09 term at Dallas Colleges.

Page1 / 44

Chapter16 - 16 Inheritance techniques From the last two...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online