This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 24 Using inheritance well L earning all the technical details of inheritance and related mechanisms, as we did in part C, does not automatically mean that we have fully grasped the methodological consequences. Of all issues in object technology, none causes as much discussion as the question of when and how to use inheritance; sweeping opinions abound, for example on Internet discussion groups, but the literature is relatively poor in precise and useful advice. In this chapter we will probe further into the meaning of inheritance, not for the sake of theory, but to make sure we use it best to benefit our software development projects. We will in particular try to understand how inheritance differs from the other inter-module relation in object-oriented system structures, its sister and rival, the client relation: when to use one, when to use the other, when both choices are acceptable. Once we have set the basic criteria for using inheritance — identifying along the way the typical cases in which it is wrong to use it — we will be able to devise a classification of the various legitimate uses, some widely accepted (subtype inheritance), others, such as implementation or facility inheritance, more controversial. Along the way we will try to learn a little from the experience in taxonomy, or systematics , gained from older scientific disciplines. 24.1 HOW NOT TO USE INHERITANCE To arrive at a methodological principle, it is often useful — as illustrated by so many other discussions in this book — to study first how not to do things. Understanding a bad idea helps find good ones, which we might otherwise miss. In too constantly warm a climate, a pear tree will not flower; it needs the jolt of Winter frost to attain full bloom in the Spring. Here the jolt is obligingly provided by a widely successful undergraduate textbook, used throughout the world to teach software engineering to probably more computing science students than any other. Already in its fourth edition, it introduced some elements of object orientation, including a discussion of multiple inheritance. Here is the beginning: Multiple inheritance allows several objects to act as base objects and is supported in object-oriented languages such as [the notation of the present book] [M 1988] . The bibliographic reference is to the first edition of the present book. Apart from the unfortunate use of “objects” for classes, this is an auspicious start. The extract continues: The characteristics of several different object classes (classes, good!) Extracts from “Soft- ware Engineering” by Ian Sommerville , Fourth edition , Add- ison-Wesley , 1993 . USING INHERITANCE PROPERLY § 24.1 810 can be combined to make up a new object ....
View Full 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.
- Spring '09