Inheritance Readings: OOSCS2 Chapters 14 – 16
EECS3311 A & E: Software Design Fall 2020
CHEN-WEI WANG
Aspects of Inheritance
● Code Reuse ● Substitutability
○ Polymorphism and Dynamic Binding[ compile-time type checks ]
○ Sub-contracting 3 of 21
[ runtime behaviour checks ]
Learning Objectives
Upon completing this lecture, you are expected to understand:
1. Design Attempts without Inheritance (w.r.t. Cohesion, SCP)
2. Using Inheritance for Code Reuse
3. Static Type & Polymorphism
4. Dynamic Type & Dynamic Binding
5. Type Casting
6. Polymorphism & Dynamic Binding:
Routine Arguments, Routine Return Values, Collections
2 of 21
Why Inheritance: A Motivating Example
Problem: A student management system stores data about students. There are two kinds of university students: resident students and non-resident students. Both kinds of students have a name and a list of registered courses. Both kinds of students are restricted to register for no more than 30 courses. When calculating the tuition for a student, a base amount is first determined from the list of courses they are currently registered (each course has an associated fee). For a non-resident student, there is a discount rate applied to the base amount to waive the fee for on-campus accommodation. For a resident student, there is a premium rate applied to the base amount to account for the fee for on-campus accommodation and meals. Tasks: Design classes that satisfy the above problem statement. At runtime, each type of student must be able to
register a course and calculate their tuition fee.
4 of 21
The COURSE Class
class
COURSE
create — Declare commands that can be used as constructors make
feature — Attributes title: STRING
fee: REAL
feature — Commands
make (t: STRING; f: REAL)
— Initialize a course with title ’t’ and fee ’f’.
do
title := t
fee := f end
end
5 of 21
No Inheritance: NON RESIDENT STUDENT Class
7 of 21
class
create make
feature — Attributes
name: STRING
courses: LINKED_LIST[COURSE]
discount rate: REAL
feature — Constructor make (n: STRING)
do name := n ; create courses.make end feature — Commands
set dr (r: REAL) do discount rate := r end
register (c: COURSE) do courses.extend (c) end feature — Queries
tuition: REAL local base: REAL do base := 0.0
across courses as c loop base := base + c.item.fee end
Result := base * discount rate end
end
NON RESIDENT STUDENT
No Inheritance: RESIDENT STUDENT Class
6 of 21
class
create make
feature — Attributes
name: STRING
courses: LINKED_LIST[COURSE]
premium rate: REAL
feature — Constructor make (n: STRING)
do name := n ; create courses.make end feature — Commands
set pr (r: REAL) do premium rate := r end
register (c: COURSE) do courses.extend (c) end feature — Queries
tuition: REAL local base: REAL do base := 0.0
across courses as c loop base := base + c.item.fee end
Result := base * premium rate
end end
RESIDENT STUDENT
No Inheritance: Testing Student Classes
test_students: BOOLEAN local
c1, c2: COURSE
jim: RESIDENT_STUDENT jeremy: NON_RESIDENT_STUDENT
do
create c1.make (“EECS2030”, 500.0) create c2.make (“EECS3311”, 500.0) create jim.make (“J. Davis”) jim.set_pr (1.25)
jim.register (c1)
jim.register (c2)
Result := jim.tuition = 1250
check Result end
create jeremy.make (“J. Gibbons”) jeremy.set_dr (0.75) jeremy.register (c1) jeremy.register (c2)
Result := jeremy.tuition = 750
end
8 of 21
No Inheritance:
Issues with the Student Classes
● Implementations for the two student classes seem to work. But can you see any potential problems with it?
● The code of the two student classes share a lot in common.
● Duplicates of code make it hard to maintain your software!
● This means that when there is a change of policy on the common part, we need modify more than one places.
⇒ This violates the Single Choice Principle :
when a change is needed, there should be a single place (or a minimal number of places) where you need to make that change.
9 of 21
No Inheritance: Maintainability of Code (2)
What if a new way for base tuition calculation is to be implemented?
e.g.,
tuition: REAL
local base: REAL
do base := 0.0
across courses as c loop base := base + c.item.fee end Result := base * inflation rate * …
end
We need to change the tuition query in both student classes.
⇒ Violation of the Single Choice Principle 11 of 21
No Inheritance: Maintainability of Code (1)
What if a new way for course registration is to be implemented? e.g.,
register(Course c) do
if courses.count >= MAX_CAPACITY then — Error: maximum capacity reached.
else
courses.extend (c) end
end
We need to change the register commands in both student classes!
⇒ Violation of the Single Choice Principle 10 of 21
No Inheritance:
A Collection of Various Kinds of Students
How do you define a class StudentManagementSystem that contains a list of resident and non-resident students?
class STUDENT_MANAGEMENT_SYSETM
rs : LINKED_LIST[RESIDENT STUDENT]
nrs : LINKED_LIST[NON RESIDENT STUDENT]
add_rs (rs: RESIDENT STUDENT) do … end
add_nrs (nrs: NON RESIDENT STUDENT) do … end register_all (Course c) — Register a common course ’c’.
do
across rs as c loop c.item.register (c) end across nrs as c loop c.item.register (c) end
end end
But what if we later on introduce more kinds of students?
Inconvenient to handle each list of students, in pretty much the
same manner, separately! 12 of 21
Inheritance Architecture
STUDENT
inherit
inherit
RESIDENT STUDENT NON RESIDENT STUDENT
13 of 21
Inheritance:
The RESIDENT STUDENT Child Class
class
RESIDENT_STUDENT
inherit
STUDENT
redefine tuition end
create make
feature — Attributes
premium rate : REAL feature — Commands
set pr (r: REAL) do premium_rate := r end feature — Queries
tuition: REAL
local base: REAL
do base := Precursor ; Result := base * premium rate end
end
1 2 3 4 5 6 7 8 9
10 11
12 13 14 15
● L3:RESIDENTSTUDENTinheritsallfeaturesfromSTUDENT.
● Thereisnoneedtorepeattheregistercommand
15of21 ● L14:PrecursorreturnsthevaluefromquerytuitioninSTUDENT.
Inheritance: The STUDENT Parent Class
1 2 3 4 5 6 7 8 9
10
11
12
13
14
15
16
17
class
create make
feature — Attributes
name: STRING
courses: LINKED_LIST[COURSE]
feature — Commands that can be used as constructors.
make (n: STRING) do name := n ; create courses.make end feature — Commands
register (c: COURSE) do courses.extend (c) end feature — Queries
tuition: REAL local base: REAL do base := 0.0
across courses as c loop base := base + c.item.fee end
Result := base end
end
STUDENT
14 of 21
Inheritance:
The NON RESIDENT STUDENT Child Class
class
NON_RESIDENT_STUDENT
inherit
STUDENT
redefine tuition end
create make
feature — Attributes
discount rate : REAL feature — Commands
set dr (r: REAL) do discount_rate := r end feature — Queries
tuition: REAL
local base: REAL
do base := Precursor ; Result := base * discount rate end
end
1 2 3 4 5 6 7 8 9
10
11
12
13
14
15
● L3:NONRESIDENTSTUDENTinheritsallfeaturesfromSTUDENT.
● Thereisnoneedtorepeattheregistercommand
16of21 ● L14:PrecursorreturnsthevaluefromquerytuitioninSTUDENT.
Inheritance Architecture Revisited
inherit
inherit
RESIDENT STUDENT NON RESIDENT STUDENT ● The class that defines the common features (attributes,
commands, queries) is called the parent , super , or ancestor class.
● Each “specialized” class is called a child , sub , or
descendent class. 17 of 21
STUDENT
Testing the Two Student Sub-Classes
test_students: BOOLEAN local
c1, c2: COURSE
jim: RESIDENT_STUDENT ; jeremy: NON_RESIDENT_STUDENT do
create c1.make (“EECS2030”, 500.0); create c2.make (“EECS3311”, 500.0) create jim.make (“J. Davis”)
jim.set_pr (1.25) ; jim.register (c1); jim.register (c2)
Result := jim.tuition = 1250
check Result end
create jeremy.make (“J. Gibbons”)
jeremy.set_dr (0.75); jeremy.register (c1); jeremy.register (c2) Result := jeremy.tuition = 750
end
maintainable using inheritance . 19 of 21
● The software can be used in exactly the same way as before (because we did not modify feature signatures).
● But now the internal structure of code has been made
Using Inheritance for Code Reuse
Inheritance in Eiffel (or any OOP language) allows you to:
○ Factor out common features (attributes, commands, queries) in a
separate class.
e.g., the STUDENT class
○ Define an “specialized” version of the class which:
● inheritsdefinitionsofallattributes,commands,andqueries e.g., attributes name, courses
e.g., command register
e.g., query on base amount in tuition
This means code reuse and elimination of code duplicates!
● definesnewfeaturesifnecessary
e.g., set pr for RESIDENT STUDENT e.g., set dr for NON RESIDENT STUDENT
● redefinesfeaturesifnecessary
e.g., compounded tuition for RESIDENT STUDENT e.g., discounted tuition for NON RESIDENT STUDENT
18 of 21
Index (1)
Learning Objectives
Aspects of Inheritance
Why Inheritance: A Motivating Example
The COURSE Class
No Inheritance: RESIDENT STUDENT Class
No Inheritance: NON RESIDENT STUDENT Class
No Inheritance: Testing Student Classes
No Inheritance:
Issues with the Student Classes
No Inheritance: Maintainability of Code (1)
No Inheritance: Maintainability of Code (2)
20 of 21
Index (2)
No Inheritance:
A Collection of Various Kinds of Students
Inheritance Architecture
Inheritance: The STUDENT Parent Class
Inheritance:
The RESIDENT STUDENT Child Class
Inheritance:
The NON RESIDENT STUDENT Child Class
Inheritance Architecture Revisited
Using Inheritance for Code Reuse
Testing the Two Student Sub-Classes
21 of 21