Author:halw

Date:2008-10-22T21:23:04.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@94 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki

@@ -4,7 +4,7 @@
 [[Property:uuid|acf84989-0e7c-f2f7-427a-19e7fce404ce]]
 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. <code> LIST </code>, as noted, describes lists in any 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 <code> LIST </code> and <code> ARRAY </code>, as follows: 
+The following simple example, from the Data Structure Library in EiffelBase, is typical. <code>LIST</code>, as noted, describes lists in any 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 <code>LIST</code> and <code>ARRAY</code>, as follows: 
 <code>
 class ARRAYED_LIST [G]
     inherit
@@ -19,7 +19,7 @@ feature
 end -- ARRAYED_LIST
 </code>
 
-The <code> inherit </code> ... 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 <code> ARRAYED_LIST </code> as shown ensures that all the features and properties of lists and arrays are applicable to arrayed lists as well. Since the class has more than one parent, this is a case of multiple inheritance. 
+The <code>inherit</code> ... 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 <code>ARRAYED_LIST</code> as shown ensures that all the features and properties of lists and arrays are applicable to arrayed lists as well. Since the class has more than one parent, this is a case of multiple inheritance. 
 
 Standard graphical conventions -- drawn from the Business Object Notation or BON, a graphical object-oriented notation based on concepts close to those of Eiffel, and directly supported by EiffelStudio -- illustrate such inheritance structures:
 
@@ -27,7 +27,7 @@ Standard graphical conventions -- drawn from the Business Object Notation or BON
 [[Image:invitation-4]]  
 
 
-An heir class such as <code> ARRAYED_LIST </code> 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, <code> ARRAYED_LIST </code> will export only the exported features of <code> LIST </code>, making those of <code> ARRAY </code> unavailable directly to <code> ARRAYED_LIST </code> 's clients. The syntax to achieve this is straightforward: 
+An heir class such as <code>ARRAYED_LIST</code> 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, <code>ARRAYED_LIST</code> will export only the exported features of <code>LIST</code>, making those of <code>ARRAY</code> unavailable directly to <code>ARRAYED_LIST</code> 's clients. The syntax to achieve this is straightforward: 
 <code>
 class ARRAYED_LIST [G]
     inherit
@@ -39,7 +39,7 @@ class ARRAYED_LIST [G]
     ... The rest as above ...
 </code>
 
-Another example of multiple inheritance comes from a windowing system based on a class <code> WINDOW </code>, close to actual classes in EiffelVision 2. 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 sub windows and the parent window, adding a sub window, deleting a sub window, attaching to another parent and so on. Rather than writing complex class that would contain specific implementations for all of these features, it is preferable to inherit all hierarchical features from <code> TREE </code> (a class in EiffelBase describing trees), and all graphical features from a class <code> RECTANGLE </code>. 
+Another example of multiple inheritance comes from a windowing system based on a class <code>WINDOW</code>, close to actual classes in EiffelVision 2. 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 sub windows and the parent window, adding a sub window, deleting a sub window, attaching to another parent and so on. Rather than writing complex class that would contain specific implementations for all of these features, it is preferable to inherit all hierarchical features from <code>TREE</code> (a class in EiffelBase describing trees), and all graphical features from a class <code>RECTANGLE</code>. 
 
 Inheritance complements the "client" relation by providing another form of reuse that yields remarkable economies of effort -- for analysis, design, implementation, evolution -- and has a profound effect on the entire software development process. 
 
@@ -62,9 +62,9 @@ class C
 feature ...
 </code>
 
-Here, if both <code> A </code> and <code> B </code> have features named <code> x </code> and <code> y </code>, class <code> C </code> would be invalid without the renaming. 
+Here, if both <code>A</code> and <code>B</code> have features named <code>x</code> and <code>y</code>, class <code>C</code> would be invalid without the renaming. 
 
-Renaming also serves to provide more appropriate feature names in descendants. For example, class <code> WINDOW </code> may inherit a routine <code> insert_subtree </code> from <code> TREE </code>. For clients of <code> WINDOW </code>, however, such a routine name is no longer appropriate. An application that uses this class needs coherent window terminology, and should have to concern itself with the inheritance structure that led to the class. So you may wish to rename <code> insert_subtree </code> as <code> add_subwindow </code> in the inheritance clause of <code> WINDOW </code>. 
+Renaming also serves to provide more appropriate feature names in descendants. For example, class <code>WINDOW</code> may inherit a routine <code>insert_subtree</code> from <code>TREE</code>. For clients of <code>WINDOW</code>, however, such a routine name is no longer appropriate. An application that uses this class needs coherent window terminology, and should have to concern itself with the inheritance structure that led to the class. So you may wish to rename <code>insert_subtree</code> as <code>add_subwindow</code> in the inheritance clause of <code>WINDOW</code>. 
 
 As a further protection against misusing multiple inheritance, the invariants of all parent classes automatically apply to a newly defined class. So classes may not be combined if their invariants are incompatible.