8 INHERITANCE 

Inheritance, the other fundamental generalization mechanism, makes it possible to define a
new class by combination and specialization of existing classes rather than from scratch. 

The following simple example, from the Data Structure Library in EiffelBase, is typical.
LIST, as indicated, describes lists in any meaningful representation. One such representation
if the lists have a fixed number of elements uses an array. We may define the corresponding
class by combination of LIST and ARRAY, as follows: 

     class ARRAYED_LIST [G] inherit 

          LIST [G]; 

          ARRAY [G] 
               export ... See below ...end 

          feature 

               ... Specific features of fixed-size lists ... 

          end -- class ARRAYED_LIST 

The inherit... clause lists all the "parents" of the new class, which is said to be their "heir".
(The "ancestors" of a class include the class itself, its parents, grandparents etc.; the reverse
term is "descendant".) Declaring ARRAYED_LIST as shown ensures that all the features
and properties of lists and arrays are applicable to fixed lists as well. Since the class has
more than one parent, this is a case of multiple inheritance. 

Standard graphical conventions serve to illustrate such inheritance structures: 

                                      

                       An inheritance structure

An heir class such as ARRAYED_LIST needs the ability to define its own export policy. By
default, inherited features keep their export status (publicly available, secret, available to
selected classes only); but this may be changed in the heir. Here, for example,
ARRAYED_LIST will export only the exported features of LIST, making those of ARRAY
unavailable directly to ARRAYED_LIST's clients. The syntax to achieve this is
straightforward: 

     class ARRAYED_LIST [G] inherit 

          LIST [G]; 

          ARRAY [G] 
               export {NONE} all end 


     ... The rest as above ... 

Another example of multiple inheritance comes from a windowing system based on a class
WINDOW, close to actual classes in EiffelVision. Windows have graphical features: a
height, a width, a position, routines to scale windows, move them, and other graphical
operations. The system permits windows to be nested, so that a window also has
hierarchical features: access to subwindows and the parent window, adding a subwindow,
deleting a subwindow, attaching to another parent and so on. Rather than writing a complex
class that would contain specific implementations for all of these features, it is preferable to
inherit all hierarchical features from TREE (a class in EiffelBase describing trees), and all
graphical features from a class RECTANGLE. 

Inheritance yields remarkable economies of effort -- whether for analysis, design,
implementation or evolution -- and has a profound effect on the entire software
development process. 

The very power of inheritance demands adequate means to keep it under control. Multiple
inheritance, in particular, raises the question of name conflicts between features inherited
from different parents; this case will inevitably arise in practice, especially for classes
contributed by independent developers. Such a name conflict may be removed through
renaming, as in 

     class C inherit 

          A rename x as x1, y as y1 end; 

          B rename x as x2, y as y2 end 

     feature... 

Here, if both A and B have features named x and y, class C would be invalid without the
renaming. 

Renaming also serves to provide more appropriate feature names in descendants. For
example, class WINDOW may inherit a routine insert_subtree from TREE. For clients of
WINDOW, however, such a routine name is no longer appropriate. An application using this
class for window manipulation needs coherent window terminology, and should not be
concerned with the inheritance structure that led to the implementation of the class. So you
may wish to rename insert_subtree as add_subwindow in the inheritance clause of
WINDOW. 

As a further facility to protect against misusing the multiple inheritance mechanism, the
invariants of all parent classes automatically apply to a newly defined class. So classes may
not be combined if their invariants are incompatible. 

     