Designing an Inheritance Hierarchy

1
Designing an Inheritance Hierarchy
C Sc 335 Rick Mercer
2
Outline

• Show the objects found for a Library System
• Recognize when to use of inheritance
• Build an inheritance hierarchy
• Design Guidelines related to inheritance
• See another use of polymorphism

3
We'll follow this object-oriented methodology

• 1. Identify candidate objects that model (shape)
  the system as a natural and sensible set of
  abstractions
• 2. Determine the main responsibility of each
  class
• what an instance of the class must be able to do
  and what is should remember
• This is part of Responsibility Driven Design ala
  Rebecca Wirfs-Brocks

4
System Specification

• The college library has requested a system that
  supports a small set of library operations. The
  librarian allows a student to borrow certain
  items, return those borrowed items, and pay fees.
  Late fees and due dates have been established at
  the following rates
• Late fee Length of Borrow
• books 0.50 per day 14 days
• video tapes 5.00 plus 1.50 each additional
  day 2 days
• CDs 2.50 per day 7 days
• The due date is set when the borrowed item is
  checked out. A student with three (3) borrowed
  items, one late item, or late fees greater than
  25.00 may not borrow anything new.

5
Identify candidate objects

• Candidate objects that model a solution with main
  responsibility. The model (no GUIs, events,
  networking)
• Librarian Coordinates activities
• Student, renamed Borrower
• Book Knows due date, late fees, Borrower,
  checkin...
• Video Knows due date, late fees, Borrower,
  checkin...
• CD Know due date, late fees, Borrower,
  checkin...
• Three borrowed books A collection of the things
  that can be borrowed, name it LendableList
• BorrowList maintains all possible borrowers

6
A UML Diagram like on test

• See whiteboard and attachments to these slides

7
What do Books, Videos, and CDs have in common?

• Common responsibilities (methods and data)
• know due date
• know call number
• know the borrower (or the borrower's ID at least)
• knows availability
• can be checked out (borrowed)
• can check a Lendable back in
• Differences
• compute due date
• compute late fee
• may have additional state -- Books have an
  author, CDs an artist

8
When is inheritance appropriate?

• Object-Oriented Design guideline
• If two or more classes have common data and
  behavior, then those classes should inherit from
  a common base class that captures those data and
  methods

9
An inheritance hierarchy
The abstract class never instantiated
Lendable is also known as the base class or
superclass Lendable is shown to abstract (in
italic) Book, CD, and Video are shown to be
concrete subclasses
10
Why not have just one class?

• Some of the behavior differs
• determine due date (2, 7, or 14 days)
• Compute late fee not always daysLate dayLateFee
  
• Data differs
• books have ISBNs
• videos may have a Hollywood studio name
• Inheritance
• allows you to share implementations
• allows one change in a common method to affect
  all
• allows new Lendables to be added

11
Examples of inheritance in Java

• You've seen HAS-A relationships
• A BankAccount HAS-A balance and ID
• Inheritance models IS-A relationships
• an oval IS-A shape
• a rectangle IS-A shape
• MyFrame extends JFrame makes MyFrame a JFrame
  with additional methods and listeners for my
  specific application

12
Java Examples of Inheritance

• Many classes extend the Component class
• a JButton IS-A Component
• a JTextField IS-A Component
• A GregorianCalender IS-A Calendar
• All Exceptions inherit from class Exception
• RunTimeException IS-AN Exception
• NullPointerException IS-A RunTimeException
• public class MyException extends
  RuntimeException
• public MyException()
• super() // implicit, not needed
• public MyException(String message)
• super(message)

13
Designing An Inheritance Hierarchy

• Start with the abstract class (a.k.a. base class)
• public abstract class Lendable
• private instance variables // Data common to
  all
• constructor(s) // Initialize Common Data
• methods that Lendable implements when the
  behavior
• is common to all of its subclasses (what
  is common) abstract methods the subclasses must
  implement (what varies)

14
Some common data fields

• Every class in the hierarchy ended with these
  private instance variables in class Lendable
• Note subclasses can not directly reference these
• private String callNumber
• private String title
• private boolean availability
• private String borrowerID
• private DayCounter dueDate

15
Lendable's constructor

• // Constructor needs a callNumber. Title was
• // added since it seems that all Lendables will
• // have a title of some sort. These come from
• // the subclasses constructor.
• public Lendable(String callNumber,
• String initTitle)
• callNumber callNumber // from subclass
• title initTitle // from subclass
• // Initialize others in a special way
• borrowerID null
• dueDate null
• availability true

16
A few Lendable accessors(the same for all
subclasse)

• public String getCallNumber()
• return callNumber
• public String getTitle()
• return title
• public boolean isAvailable()
• return availability
• public DayCounter getDueDate() return dueDate

17
DayCounter Simple way to compare dates

• public int daysLate()
• // return a positive if dueDate is before
  today
• DayCounter today new DayCounter()
• return dueDate.daysFrom(today)
• public boolean isOverdue()
• if(this.isAvailable())
• return false // not even checked out
• // Or check to see if this Lendable is overdue
• DayCounter today new DayCounter()
• // Return true if today is greater than
• // the due date for this Lendable
• return daysLate() gt 0

18
A Modifying Method in Lendable

• public boolean checkSelfIn()
• if(this.isAvailable())
• return false
• else // Adjust state so this is checked out
• dueDate null
• availability true
• return true

19
checkSelfOut responsibility is split between
Lendable and it subclasses

• protected // called from a subclass checkSelfOut
• void checkOutAnyLendable(String borrowerID,
• int borrowLength)
• // Record who is borrowing this Lendable
• borrowerID borrowerID
• // Set the due date
• dueDate new DayCounter() // today's date
• dueDate.adjustDaysBy(borrowLength)
• // Mark this as no longer available
• availability false

20
Protected

• The protected access mode means that subclasses
  inherit this method (inherit all public
  protected elements).
• It's invoked by the subclass's checkSelfOut
  method.
• So far, good design for the following reasons
• subclasses can't change the private variables of
  the superclass, even though the subclass has them
• doesn't require a bunch of setter methods in
  Lendable for subclasses to modify its own
  instance variables
• the common behavior is in the superclass
• the same thing is done for all subclasses
• We'll get a polymorphic checkSelfOut message

21
Abstract methods

• Subclasses differ setDueDate getLateFee
• declare the appropriate methods abstract, to
  force sub-classes to implement them in their own
  appropriate ways
• public abstract class Lendable
• //Don't really borrow a Lendable or eat a Fruit
• ...
• // Subclass must implement these two methods
• abstract public void checkSelfOut(String ID)
• abstract public double getLateFee()
• // Done with Lendable for now

22
What can a subclass do?

• General form for inheriting from a Java class
• public class subclass extends superclass
• // Inherits all public and protected methods of
  superclass
• may add class constants
• may add instance variables
• may add 0 to many constructors
• may add new public and protected methods
• may override methods in the superclass
• may add additional private methods

23
The Constructor and Super

• A subclass typically defines its constructor
• If not, you will still get a default constructor
• zero parameters
• it automatically calls the base class constructor
• Constructors in a subclass typically call the
  superclass constructor to initialize the objects
• Access superclass with the keyword super
• can pass along arguments super(callNum, title)
• if used, super must be the first message in the
  constructor of the derived classes

24
Book extends Lendable

• public class Book extends Lendable
• public static final int DAYS_TO_BORROW_BOOK
  14
• public static final double BOOK_LATE_DAY_FEE
  0.50
• // A new instance variable added to the 5
  inherited
• private String author
• // Can finally construct something
• public Book(String callNumber, String title,
• String author)
• // call Lendable constructor
• super(callNumber, title) author author
• public String getAuthor()
• return author
• // incomplete, but let's see if something works

25
Complete both required methods

• checkSelfOut delegates some work to Lendable and
  passes along the unique information
  Book.DAYS_TO_BORROW_BOOK
• / Modify the state of this object so it is
  borrowed
• _at_param borrowerID The identification of
  borrower
• /
• _at_Override public void checkSelfOut(String
  borrowerID)
• checkOutAnyLendable(borrowerID,
• Book.DAYS_TO_BORROW_BOOK)
  

26
getLateFee differs among the Lendable subclasses

• _at_Overridepublic double getLateFee()
• if(this.isAvailable()) // Not even checked out!
• return 0.00
• else
• // A positive daysLate means due date has
  passed
• int daysOverdue this.daysLate()
• if(daysOverdue gt 0) // This Lendable is
  overdue
• return daysOverdue Book.BOOK_LATE_DAY_FEE
  
• else
• return 0.00 // The due date has not passed

27
A few assertions

• _at_Test
• public void testGetters()
• // Show that Book has many methods via
  inheritance
• Book aBook new Book("QA76.1", "C", "Jo")
• assertTrue(aBook.isAvailable())
• assertFalse(aBook.isOverdue())
• assertNull(aBook.getBorrowerID())
• assertEquals("QA76.1", aBook.getCallNumber())
• assertEquals("C", aBook.getTitle())
• assertEquals("Jo", aBook.getAuthor())
• // Use the 2 methods that once were abstract
  and
• // now have concrete realizations
• assertEquals(0.00, aBook.getLateFee(), 1e-12)
• assertTrue(aBook.isAvailable())
• aBook.checkSelfOut("Rick")
• assertFalse(aBook.isAvailable())

28
Adding another Subclass such as Video or CD

• extend Lendable
• Optional add class constants
• days to borrow, late fee amounts
• Add a constructor that passes along arguments to
  the constructor in Lendable (super)
• Add the methods that Lendable requires of all
  sublclasses use Override
• checkSelfOut
• getLateFee

29
(No Transcript)