26 CRITERIA FOR OBJECT ORIENTATION $2.2 Every entity(that is to say,every name used in the software text to refer to run-time objects)is explicitly declared as being of a certain type,derived from a class. Every feature call on a certain entity uses a feature from the corresponding class(and the feature is available,in the sense of information hiding,to the caller's class) Assignment and argument passing are subject to conformance rules,based on inheritance,which require the source's type to be compatible with the target's type. In a language that imposes such a policy,it is possible to write a static type checker which will accept or reject software systems,guaranteeing that the systems it accepts will not cause any"feature not available on object"error at run time. A well-defined type system should,by enforcing a number of type declaration and compatibility rules,guarantee the run-time type safety of the systems it accepts. Genericity For typing to be practical,it must be possible to define type-parameterized classes,known as generic.A generic class LIST[G]will describe lists of elements of an arbitrary type represented by G,the "formal generic parameter";you may then declare specific lists through such derivations as LIST [INTEGER]and LIST [WINDOW],using types INTEGER and WINDOW as "actual generic parameters".All derivations share the same class text. It should be possible to write classes with formal generic parameters representing arbitrary types. This form of type parameterization is called unconstrained genericity.A companion facility mentioned below,constrained genericity,involves inheritance. Single inheritance Software development involves a large number of classes;many are variants of others.To control the resulting potential complexity,we need a classification mechanism,known as inheritance.A class will be an heir of another if it incorporates the other's features in addition to its own.(A descendant is a direct or indirect heir;the reverse notion is ancestor. It should be possible to define a class as inheriting from another. Inheritance is one of the central concepts of the object-oriented methods and has profound consequences on the software development process. Multiple inheritance We will often encounter the need to combine several abstractions.For example a class might model the notion of“infant”,which we may view both as a“person”,with the
26 CRITERIA FOR OBJECT ORIENTATION §2.2 • Every entity (that is to say, every name used in the software text to refer to run-time objects) is explicitly declared as being of a certain type, derived from a class. • Every feature call on a certain entity uses a feature from the corresponding class (and the feature is available, in the sense of information hiding, to the caller’s class). • Assignment and argument passing are subject to conformance rules, based on inheritance, which require the source’s type to be compatible with the target’s type. In a language that imposes such a policy, it is possible to write a static type checker which will accept or reject software systems, guaranteeing that the systems it accepts will not cause any “feature not available on object” error at run time. Genericity For typing to be practical, it must be possible to define type-parameterized classes, known as generic. A generic class LIST [G] will describe lists of elements of an arbitrary type represented by G, the “formal generic parameter”; you may then declare specific lists through such derivations as LIST [INTEGER] and LIST [WINDOW], using types INTEGER and WINDOW as “actual generic parameters”. All derivations share the same class text. This form of type parameterization is called unconstrained genericity. A companion facility mentioned below, constrained genericity, involves inheritance. Single inheritance Software development involves a large number of classes; many are variants of others. To control the resulting potential complexity, we need a classification mechanism, known as inheritance. A class will be an heir of another if it incorporates the other’s features in addition to its own. (A descendant is a direct or indirect heir; the reverse notion is ancestor.) Inheritance is one of the central concepts of the object-oriented methods and has profound consequences on the software development process. Multiple inheritance We will often encounter the need to combine several abstractions. For example a class might model the notion of “infant”, which we may view both as a “person”, with the A well-defined type system should, by enforcing a number of type declaration and compatibility rules, guarantee the run-time type safety of the systems it accepts. It should be possible to write classes with formal generic parameters representing arbitrary types. It should be possible to define a class as inheriting from another
$2.2 METHOD AND LANGUAGE 27 associated features,and,more prosaically,as a "tax-deductible item",which earns some deduction at tax time.Inheritance is justified in both cases.Multiple inheritance is the guarantee that a class may inherit not just from one other but from as many as is conceptually justified. Multiple inheritance raises a few technical problems,in particular the resolution of name clashes(cases in which different features,inherited from different classes,have the same name).Any notation offering multiple inheritance must provide an adequate solution to these problems. It should be possible for a class to inherit from as many others as necessary. with an adequate mechanism for disambiguating name clashes. The solution developed in this book is based on renaming the conflicting features in the heir class. Repeated inheritance Multiple inheritance raises the possibility of repeated inheritance,the case in which a class inherits from another through two or more paths,as shown. Repeated inheritance Inherits from In such a case the language must provide precise rules defining what happens to features inherited repeatedly from the common ancestor,4 in the figure.As the discussion of repeated inheritance will show,it may be desirable for a feature of4 to yield just one feature of D in some cases (sharing),but in others it should yield two (replication). Developers must have the flexibility to prescribe either policy separately for each feature. Precise rules should govern the fate of features under repeated inheritance, allowing developers to choose,separately for each repeatedly inherited feature,between sharing and replication. Constrained genericity The combination of genericity and inheritance brings about an important technique, constrained genericity,through which you can specify a class with a generic parameter that represents not an arbitrary type as with the earlier(unconstrained)form of genericity, but a type that is a descendant of a given class
§2.2 METHOD AND LANGUAGE 27 associated features, and, more prosaically, as a “tax-deductible item”, which earns some deduction at tax time. Inheritance is justified in both cases. Multiple inheritance is the guarantee that a class may inherit not just from one other but from as many as is conceptually justified. Multiple inheritance raises a few technical problems, in particular the resolution of name clashes (cases in which different features, inherited from different classes, have the same name). Any notation offering multiple inheritance must provide an adequate solution to these problems. The solution developed in this book is based on renaming the conflicting features in the heir class. Repeated inheritance Multiple inheritance raises the possibility of repeated inheritance, the case in which a class inherits from another through two or more paths, as shown. In such a case the language must provide precise rules defining what happens to features inherited repeatedly from the common ancestor, A in the figure. As the discussion of repeated inheritance will show, it may be desirable for a feature of A to yield just one feature of D in some cases (sharing), but in others it should yield two (replication). Developers must have the flexibility to prescribe either policy separately for each feature. Constrained genericity The combination of genericity and inheritance brings about an important technique, constrained genericity, through which you can specify a class with a generic parameter that represents not an arbitrary type as with the earlier (unconstrained) form of genericity, but a type that is a descendant of a given class. It should be possible for a class to inherit from as many others as necessary, with an adequate mechanism for disambiguating name clashes. Precise rules should govern the fate of features under repeated inheritance, allowing developers to choose, separately for each repeatedly inherited feature, between sharing and replication. Repeated inheritance Inherits from A D