Generic Classes Use Cases Inheritance

1
Generic ClassesUse CasesInheritance
Lecture 20
2
Generic Classes
3
The Scenario

• Imagine that youve just finished writing a
  wonderful NumberQueue class that works perfectly.
• But what about a Queue to hold strings?
• or Booleans?
• or user-defined records?

4
A Proper Balance

• Notice that in the process of creating the
  NumberQueue class
• Weve given too much informationto the class
  (supplier).
• The algorithm (client) should specifywhat to
  hold.
• The Queue shouldnt care about what it holds.
• The Queue should simply hold the items!

5
Achieving Proper Balance

• Hide details from the client
• Using protected section of the class
• Keep certain information in the client
• The object doesnt / shouldnt know about certain
  details
• Better abstraction and makes the class generic
  (more reusable)

6
A StudentCollection
StudentCollection
Initialize

• Head

Add

Remove
RemoveHelper
IsEmpty
7

• class StudentCollection
• public
• procedure Add(toAdd isoftype in Student)
• // contract comments here
• procedure Remove (toRemove isoftype in Student)
• // contract comments here
• function IsEmpty returnsa Boolean
• // contract comments here
• procedure Initialize
• // contract comments here
• protected
• ListNode definesa record
• data isoftype Student
• next isoftype ptr toa ListNode
• endrecord // ListNode
• Head isoftype ptr toa ListNode

8

• // Still in the protected section
• procedure Add(toAdd isoftype in Student)
• temp isoftype ptr toa ListNode
• temp lt- new(ListNode)
• temp.data lt- toAdd
• temp.next lt- Head
• Head lt- temp
• endprocedure // Add
• function IsEmpty returnsa Boolean
• IsEmpty returns (Head NIL)
• endfunction // IsEmpty
• procedure Initialize
• Head lt- NIL
• endprocedure // Initialize

9

• // Still in the protected section
• procedure Remove (toRemove isoftype in Student)
• RemoveHelper (Head, toRemove)
• endprocedure // Remove
• procedure RemoveHelper (current iot in/out ptr
• toa ListNode, toRemove isoftype in Student)
• if (current ltgt NIL) then
• if (current.data toRemove) then
• current lt- current.next
• else
• RemoveHelper(current.next, toRemove)
• endif
• endif
• endprocedure // RemoveHelper
• endclass // StudentCollection

10
Other Collections

• What about other collections?
• String
• Num
• Etc.
• Maintaining multiple classes would be
  counterproductive.

11

• class StudentCollection
• public
• procedure Add(toAdd isoftype in Student)
• // contract comments here
• procedure Remove (toRemove isoftype in Student)
• // contract comments here
• function IsEmpty returnsa Boolean
• // contract comments here
• procedure Initialize
• // contract comments here
• protected
• ListNode definesa record
• data isoftype Student
• next isoftype ptr toa ListNode
• endrecord // ListNode
• Head isoftype ptr toa ListNode

12

• // Still in the protected section
• procedure Add(toAdd isoftype in Student)
• temp isoftype ptr toa ListNode
• temp lt- new(ListNode)
• temp.data lt- toAdd
• temp.next lt- Head
• Head lt- temp
• endprocedure // Add
• function IsEmpty returnsa Boolean
• IsEmpty returns (Head NIL)
• endfunction // IsEmpty
• procedure Initialize
• Head lt- NIL
• endprocedure // Initialize

13

• // Still in the protected section
• procedure Remove (toRemove isoftype in Student)
• RemoveHelper (Head, toRemove)
• endprocedure // Remove
• procedure RemoveHelper (current iot in/out ptr
• toa ListNode, toRemove isoftype in Student)
• if (current ltgt NIL) then
• if (current.data toRemove) then
• current lt- current.next
• else
• RemoveHelper(current.next, toRemove)
• endif
• endif
• endprocedure // RemoveHelper
• endclass // StudentCollection

14
Better Abstraction

• Why not let the class worry only about managing
  the items?
• It should have no concept of what its holding.
• This will dramatically increase reusability.
• Why not specify the type of items to hold via a
  parameter?

15
A Collection
Collection
Initialize

• Head

Add

Remove
RemoveHelper
IsEmpty
16
Making the Class Generic

• Instead of a specific data type to hold, declare
  a magic word on which well later search and
  replace.
• When the class is instantiated later into an
  object, then specify the desired type.
• Use a parameter to the class definition and
  instantiation.

17

• class Collection (DataType)
• public
• procedure Add(toAdd isoftype in DataType)
• // contract comments here
• procedure Remove (toRemove iot in DataType)
• // contract comments here
• function IsEmpty returnsa Boolean
• // contract comments here
• procedure Initialize
• // contract comments here
• protected
• ListNode definesa record
• data isoftype DataType
• next isoftype ptr toa ListNode
• endrecord // ListNode
• Head isoftype ptr toa ListNode

18

• // Still in the protected section
• procedure Add(toAdd isoftype in DataType)
• temp isoftype ptr toa ListNode
• temp lt- new(ListNode)
• temp.data lt- toAdd
• temp.next lt- Head
• Head lt- temp
• endprocedure // Add
• function IsEmpty returnsa Boolean
• IsEmpty returns (Head NIL)
• endfunction // IsEmpty
• procedure Initialize
• Head lt- NIL
• endprocedure // Initialize

19

• // Still in the protected section
• procedure Remove (toRemove iot in DataType)
• RemoveHelper (Head, toRemove)
• endprocedure // Remove
• procedure RemoveHelper (current iot in/out ptr
• toa ListNode, toRemove iot in DataType)
• if (current ltgt NIL) then
• if (current.data toRemove) then
• current lt- current.next
• else
• RemoveHelper(current.next, toRemove)
• endif
• endif
• endprocedure // RemoveHelper
• endclass // Collection

20
Instantiating Generic Classes

• Simply add a type as a parameter to the
  declaration of the object
• Algorithm CollectionExample
• uses Collection
• Students isoftype Collection(Student)
• WordList isoftype Collection(String)
• Numbers isoftype Collection(Num)

21
Using Objects of Generic Classes

• Just as before
• algorithm CollectionExample
• ...
• Numbers.Add(42)
• Numbers.Add(31)
• Numbers.Remove(42)
• if (Numbers.IsEmpty) then
• print(Empty collection of numbers)
• endif
• WordList.Add(CS is fun!)
• ...

22
Summary

• Everything in its proper place
• Hide details from the client in the protected
  section
• Hide details from the class using generic
  parameters
• This gives better abstraction and increases
  reusability.

23
Questions?
24
Use Cases
25
Designing an OO Solution

• Ask yourself, What are the characteristics of
  the system I want to model?
• Use natural language to describe scenarios, or
  cases of use.
• Natural language descriptions define how each
  user of a system intends to use it.

26
Use Cases

• Frequently causes you to think more clearly about
  the system design before its too late.
• Useful in providing introduction to the system
  requirements
• Identify users
• Identify major system components (classes)
• Identify methods and attributes needed for each
  component

27
Use Case Design

• From the use case scenarios, we can construct our
  classes with methods and attributes
• Nouns become classes or attributes
• Verbs become methods

28
Use Case Example

• A passenger wishing to go to another floor of the
  building presses the elevator call button. When
  an elevator is available, the doors open and the
  passenger enters the cage. The passenger presses
  one of the inside buttons to select the
  destination floor. The doors close and the
  elevator moves to the destination floor the
  doors open and the passenger leaves.
• When an elevator requires maintenance, the
  maintainer disables the elevator call buttons,
  attaches his external control box and exercises
  individual elevator control commands and display
  features.

29
Visual Diagram of A System
30
Relationships between Classes Has-a

• Identity
• Weight
• Doors
• People
• Position

Elevator
Open Doors
Close Doors
Move to Floor
Door

• Identity
• Weight
• Color
• Position

Open
Close
31
Relationships between Classes Is-A
32
Issues

• What are the main tasks to be performed by each
  actor? (Class definition)
• What could go wrong with each task? (Fault
  tolerance and recovery)
• What information is required for each task,
  produced by it, or changed by it? (Information
  and method passing)

33
Issues

• Do the actors have to be involved by providing
  input about the external world? (Interface)
• What information does the actor desire from the
  system? (User-centered design)
• Should the actor be informed of unexpected events
  or unavailable equipment or capabilities?
  (Visibility)

34
Questions?
35
Inheritance
36
Relationships Between Classes

• Has-A
• One class can provide services to another, acting
  as an attribute
• Is-A
• One class inherits the abilities of another class

37
Elevator Instances
Passenger Elevator 1
Passenger Elevator 2
Doors
Doors
Lobby
Doors
Doors
Passenger Elevator 3
Service Elevator
Doors
38
Relationships between ClassesUsing - Has-A

• Identity
• Color
• State
• Doors
• Position

Elevator
Open Doors
Close Doors
Move to Floor
Door

• Identity
• State
• Color
• IsOpen

Has-A
Open
Close
39
Relationships between ClassesBeing - Is-A

• Identity
• Color
• State

Thing
Move
Is-A
Door
Elevator

• Position
• Doors

• IsOpen

Open Doors
Open
Close
Close Doors
40
Defining the Differences

• Classes often share capabilities
• We want to avoid re-coding these capabilities
• Re-use of these would be best to
• Improves maintainability
• Reduces cost
• Improves real world modeling

41
Inheritance Defined

• When one class re-uses the capabilities defined
  in another class.
• The new subclass gains all the methods and
  attributes of the superclass.

Thing
Superclass
Subclass
Elevator
Door
42
Inheritance Example
Thing

• Identity
• Color
• State

Move
Door
Elevator

• Position
• Doors

• IsOpen

Open Doors
Open
Close
Close Doors
43
Benefits of Inheritance

• Saves effort of reinventing the wheel
• Allows us to build on existing code, specializing
  without having to copy it, rewrite it, etc.
• To create the subclass, we need to program only
  the differences between the superclass and the
  subclass that inherits from it.
• Allows for flexibility in class definitions.

44
Inheriting from a SuperClass

• class ltSUBCLASS_NAMEgt
• inherits ltSUPERCLASS_NAMEgt
• public
• ltCHANGESgt
• protected
• ltCHANGESgt
• endclass // ltSUBCLASS_NAMEgt

45
Two Types of Inheritance

• Extension
• Adds attributes and methods
• Redefinition
• Changes/modifies existing methods, specializing
  as needed

46
Inheritance Examples

• Given a bank account class
• Extension
• Add the capability of calculating interest
• Redefinition
• Redefine how withdraws occur

47
Inheritance Example Bank Accounts

• Consider a primitive bank account which allows
  only three kinds of transactions
• Deposits
• Withdrawals
• Ability to check current balance

48
The Base Class Bank_Account
Bank_Account
Deposit

• balance

Withdraw
Initialize
Get_Balance
49
A Superclass Bank_Account

• class Bank_Account
• public
• procedure Deposit (amt isoftype in Num)
• // comments here
• procedure Withdraw(amt isoftype in/out Num)
• // only allows withdraw up to current balance
• function Get_Balance returnsa Num
• // comments here
• procedure Initialize
• // comments here
• protected
• balance isoftype Num
• procedure Deposit (amt isoftype in Num)
• balance lt- balance amt
• endprocedure // Deposit

50
A Base Class (contd)

• //still in protected section
• procedure Withdraw(amt isoftype in/out Num)
• if (balance lt amt) then
• amt lt- balance
• endif
• balance lt- balance - amt
• endprocedure // Withdraw
• function Get_Balance returnsa Num
• Get_Balance returns balance
• endfunction // Get_Balance
• procedure Initialize
• balance lt- 0
• endprocedure // Initialize
• endclass // Bank_Account

51
Inheritance by Extension

• Imagine that we wish to create a new kind of Bank
  Account that is
• Identical to the base class in all respects,
  except one
• We want to add the ability for the account to
  earn interest
• Without inheritance, wed have to write it from
  scratch, duplicating code, etc.
• With inheritance, we need code only the new
  capability and inherit the rest.

52
Illustration of Inheritance
Bank_Account
Deposit

• balance

Withdraw
Initialize
Get_Balance
Savings_Account

• RATE
• MIN_BALANCE

Calc_Interest
// protected section Function Calc_Interest . .
. endfunction
53
Inheritance by Extension

• class Savings_Account
• inherits Bank_Account
• public
• // inherits Deposit, Withdraw, Get_Balance
• function Calc_Interest returnsa Num
• // comments here
• protected
• // inherits balance
• RATE is .023 // 2.3
• MIN_BALANCE is 500

54
Inheritance by Extension (contd)

• // still in protected section
• function Calc_Interest returnsa Num
• if (balance gt MIN_BALANCE) then
• Calc_Interest returns balance RATE
• else
• Calc_Interest returns 0
• endif
• endfunction // Calc_Interest
• endclass // Savings_Account

55
Using Subclasses in Algorithms

• algorithm BankExample
• uses Savings_Account
• my_savings isoftype Savings_Account
• my_savings.Initialize // superclass method
• . . .
• my_savings.Deposit(500) // superclass
  method
• my_interest isoftype Num
• my_interest lt- my_savings.Calc_Interest
• // subclass method
• . . .
• my_savings.Withdraw(amount) // superclass
  method
• endalgorithm // BankExample

56
Inheritance by Redefinition

• Imagine that we wish to create a new kind of
  Savings Account that is
• identical to Savings Account in all respects,
  except one
• we want to change the way in which withdrawals
  are handled
• the base class already handles withdrawals, but
  now we want a subclass that does them
  differently.
• Without inheritance, wed have to rewrite it from
  scratch.
• With inheritance, we need code only the new way
  that we want withdrawals to work,

57
Illustration of Redefinition
Savings_Account

• RATE
• MIN_BALANCE

Calc_Interest
Cool_Savings

• overdraft_ok
• OVERDRAFT_CHARGE

Allow_Overdraft
// protected section procedure Withdraw . .
. procedure Initialize . . .
58
Inheritance by Redefinition

• class Cool_Savings
• inherits Savings_Account
• public
• procedure Allow_Overdraft(ok iot in Boolean)
• // new method extending superclass
• protected
• overdraft_ok isoftype Boolean // extension
• OVERDRAFT_CHARGE is 20 // extension
• procedure Allow_Overdraft(ok iot in Boolean)
• overdraft_ok lt- ok
• endprocedure // Allow_Overdraft

59
Inheritance and Redefinition (contd)

• // still in protected section
• procedure Withdraw(amt isoftype in/out Num)
• if (overdraft_ok) then
• balance lt- balance - amt
• if (balance lt 0) then
• balance lt- balance OVERDRAFT_CHARGE
• endif
• else
• Super.Withdraw(amt) // calls super version
• endif
• endprocedure // Withdraw
• procedure Initialize // redefines Init.
• Super.Initialize // uses super method
• overdraft_ok lt- FALSE // and adds to it.
• endprocedure // Initialize
• endclass // Cool_Savings

60
Super

• Super is a built-in attribute to all classes
  which inherit from another class.
• Super allows us to access the implementation of
  a method in the superclass.
• For example, Super.Initialize executes the
  Initialize implementation in the superclass of
  the class.

61
Using Subclasses in Algorithms

• my_cool_savings isoftype Cool_Savings
• my_cool_savings.Initialize // both
• my_cool_savings.Deposit(250) // super method
• . . .
• my_cool_savings.Withdraw(amount) // both
• // check amount to see if correctly done
• my_cool_savings.Allow_Overdraft(TRUE)
• // subclass method
• my_interest isoftype Num
• my_interest lt- my_cool_savings.Calc_Interest
• // super method
• . . .
• my_cool_savings.Withdraw(amount)// subclass method

62
Summary of Inheritance

• Extension take a base class and add new
  capabilities to it (methods, attributes).
• Redefinition take a base class and redefine an
  existing method, implement it in a new way in
  order to change capability or performance.
• Both allow us to code only the differences.

63
Questions?
64
(No Transcript)