Chair of Software Engineering ATOT - Lecture 9, 30 April Advanced Topics in Object Technology Bertrand Meyer

Chair of Software Engineering ATOT - Lecture 9, 30 April Lecture 9: Inheritance

Chair of Software Engineering ATOT - Lecture 9, 30 April Typing vs. binding  What do we know about the feature to be called?  Static typing: At least one  Dynamic binding: The right one  Example: my_aircraft.lower_landing_gear

Chair of Software Engineering ATOT - Lecture 9, 30 April Example hierarchy AIRCRAFT * PLANE * COPTER * BOEINGAIRBUS A_320 B_747B_737 B_747_400 * deferred + effected ++ redefined lower_landing_gear* lower_landing_gear++ lower_landing_gear+

Chair of Software Engineering ATOT - Lecture 9, 30 April (After Barry W. Boehm) RequirementsDesignCodeDevelopmentAcceptanceOperation test SMALL PROJECTS LARGE PROJECTS

Chair of Software Engineering ATOT - Lecture 9, 30 April Multiple inheritance  A class may have two or more parents.  What not to use as an elementary example: TEACHING_ASSISTANT inherits from TEACHER and STUDENT. TEACHERSTUDENT TEACHING_ ASSISTANT

Chair of Software Engineering ATOT - Lecture 9, 30 April The teaching assistant example  This is in fact a case of repeated inheritance: TEACHERSTUDENT TEACHING_ ASSISTANT UNIVERSITY_ PERSON id ?? ????

Chair of Software Engineering ATOT - Lecture 9, 30 April Common examples of multiple inheritance  Combining separate abstractions:  Restaurant, train car  Calculator, watch  Plane, asset

Chair of Software Engineering ATOT - Lecture 9, 30 April Multiple inheritance: Combining abstractions COMPARABLENUMERIC STRINGCOMPLEX INTEGER REAL DOUBLE **

Chair of Software Engineering ATOT - Lecture 9, 30 April Multiple inheritance: Nested windows  ‘‘Graphical’’ features: height, width, change_height, change_width, xpos, ypos, move...  ‘‘Hierarchical’’ features: superwindow, subwindows, change_subwindow, add_subwindow... class WINDOW inherit RECTANGLE TREE [WINDOW] feature... end

Chair of Software Engineering ATOT - Lecture 9, 30 April Multiple inheritance: Composite figures A composite figure Simple figures

Chair of Software Engineering ATOT - Lecture 9, 30 April Defining the notion of composite figure FIGURE LIST [FIGURE] COMPOSITE_ FIGURE * display hide rotate move … count put remove …

Chair of Software Engineering ATOT - Lecture 9, 30 April Defining the notion of composite figure through multiple inheritance FIGURE LIST [FIGURE] COMPOSITE_ FIGURE * OPEN_ FIGURE CLOSED_ FIGURE SEGMENT POLYLINE POLYGON ELLIPSE RECTANGLE SQUARE CIRCLE TRIANGLE … perimeter+ perimeter* perimeter++ perimeter+ diagonal …

Chair of Software Engineering ATOT - Lecture 9, 30 April A composite figure as a list start item forthafter

Chair of Software Engineering ATOT - Lecture 9, 30 April Composite figures class COMPOSITE_FIGURE inherit FIGURE redefine display, move, rotate,... end LIST [FIGURE] feature display is -- Display each constituent figure in turn. do from start until after loop item.display forth end end... Similarly for move, rotate etc.... end

Chair of Software Engineering ATOT - Lecture 9, 30 April Complex figures  Note: a simpler form of procedures display, move etc. can be obtained through the use of iterators.  Exercise: Use agents for that purpose.

Chair of Software Engineering ATOT - Lecture 9, 30 April Name clashes under multiple inheritance A C foo B

Chair of Software Engineering ATOT - Lecture 9, 30 April Resolving name clashes A C foo B rename foo as fogrename foo as zoo

Chair of Software Engineering ATOT - Lecture 9, 30 April Resolving name clashes (cont’d) class C inherit A rename foo as fog end B rename foo as zoo end feature...

Chair of Software Engineering ATOT - Lecture 9, 30 April Results of renaming a1: A b1: B c1: C... c1.fog c1.zoo a1.foo b1.foo Invalid: a1.fog, a1.zoo, b1.zoo, b1.fog, c1.foo

Chair of Software Engineering ATOT - Lecture 9, 30 April Another application of renaming  Provide locally better adapted terminology.  Example: child (TREE); subwindow (WINDOW).

Chair of Software Engineering ATOT - Lecture 9, 30 April The marriage of convenience class ARRAYED_STACK [G] inherit STACK [G] ARRAY [G] feature... end class LINKED_STACK [G] inherit STACK [G] LINKED_LIST [G] feature... end

Chair of Software Engineering ATOT - Lecture 9, 30 April The need for deferred classes  In the scheme seen earlier: f: FIGURE; c: CIRCLE; p: POLYGON... create c.make (...); create p.make (...)... if... then f := c else f := p end... f.move (...); f.rotate (...); f.display (...);...  How do we ensure that a call such as f.move (...) is valid even though there is no way to implement a general-ee- purpose feature move for class FIGURE?

Chair of Software Engineering ATOT - Lecture 9, 30 April Deferred classes deferred class FIGURE feature move (v: VECTOR) is deferred end rotate (a: ANGLE; p: POINT) is deferred end... display, hide,... end Not permitted: create f...

Chair of Software Engineering ATOT - Lecture 9, 30 April Example hierarchy FIGURE * OPEN_ FIGURE * CLOSED_ FIGURE * SEGMENTPOLYLINEPOLYGONELLIPSE CIRCLE RECTANGLETRIANGLE SQUARE extent* barycenter* … display* rotate … perimeter* perimeter+ perimeter++ diagonal... perimeter++

Chair of Software Engineering ATOT - Lecture 9, 30 April Deferred classes and features  A feature is either deferred or effective.  To effect a inherited feature (deferred in the parent) is to make it effective. No need for redefine clause.  Like a feature, a class is either deferred or effective.  A class is deferred if it has at least one deferred feature (possibly coming from an ancestor) that it does not effect. It is effective otherwise.  A deferred class may not be instantiated.  BUT: A deferred class may have assertions (in particular, a deferred routine may have a precondition and a postcondition, and the class may have a class invariant).

Chair of Software Engineering ATOT - Lecture 9, 30 April Deferred classes  Compare with Ada-Modula 2-Java interface/body separation:  May contain both deferred and non-deferred elements.  More than one implementation is possible.  Formal semantic specification (assertions).

Chair of Software Engineering ATOT - Lecture 9, 30 April Table variants TABLE * SEQUENTIAL_ TABLE * LINKED_ TABLE + ARRAY_ TABLE + FILE_ TABLE +

Chair of Software Engineering ATOT - Lecture 9, 30 April Don’t call us, we’ll call you deferred class SEQUENTIAL_TABLE [G] inherit TABLE [G] feature has (x: G): BOOLEAN is -- Does x appear in table? do from start until after or else equal (item, x) loop forth end Result := not after end

Chair of Software Engineering ATOT - Lecture 9, 30 April SEQUENTIAL_TABLE (cont’d) forth is require not after deferred ensure position = old position + 1 end start is deferred ensure empty or else position = 1 end

Chair of Software Engineering ATOT - Lecture 9, 30 April SEQUENTIAL_TABLE (end) position: INTEGER is deferred end... empty, found, after,... invariant 0 <= position position <= size + 1 empty implies (after or before) end

Chair of Software Engineering ATOT - Lecture 9, 30 April Descendant implementations TABLE * SEQUENTIAL_ TABLE * LINKED_ TABLE + ARRAY_ TABLE + FILE_ TABLE + has+ forth* item* start* forth+ item+ start+ after+ forth+ item+ start+ after+ forth+ item+ start+ after+ after* has*

Chair of Software Engineering ATOT - Lecture 9, 30 April Descendant implementations (cont’d) SEQUENTIAL_ TABLE * LINKED_ TABLE + ARRAY_ TABLE + FILE_ TABLE + has+ forth* item* start* forth+ item+ start+ after+ forth+ item+ start+ after+ forth+ item+ start+ after+ after*

Chair of Software Engineering ATOT - Lecture 9, 30 April Implementation variants Array Linked list File startforthafterfound (x) c := first_cell rewind i := 1 c := c.right i := i + 1 readend_of_file c := Void f = x c.item = x i > countt [i] = x

Chair of Software Engineering ATOT - Lecture 9, 30 April End of lecture 9