Description
Purpose
This is an exercise to practice with the concept of Polymorphism.
Suggested Reading: Chapters 9, 10 of Deitel and Deitel.
Description
This is a polymorphism example, so right from the start we know we will be processing items of
a type that is a super-class (maybe abstract) or an interface. Remember the “type” is the word
that goes on the left side when we declare a variable (examples, int, Shape, Animal, Vehicle,
double, String, etc – but only the ones with capital letters are reference types that can be used
with polymorphic processing). The super-class or interface tells us about the list of behaviors of
the objects we need to process. We’ve seen the super-classes Shape in the past. When we say
“behavior”, we mean the methods that will be available for us to use, even though the specifics,
the actual implementation, of those methods, can be determined by the sub-class. For example,
the Shape superclass tells us what all shapes can do: give their area. The specific shapes each
calculate their area differently.
In this case for this exercise we have bank accounts. What methods would all bank accounts
have? calculateInterest? deposit? withdraw? getBalance? calculateAndUpdateBalance?
What kinds of bank accounts are there? Chequing, Savings, Investment, Credit Card? As
programmers by now we have been trained to recognize that there can be some methods that
would be done the same way in all cases, implemented with the same Java code (getBalance)
and there can be some methods that might be done differently depending on what sub-type it
is, what type of account it is (calculateAndUpdateBalance) Similarly, the attributes (also known
as instance variables) can be divided up into two kinds: those that are the same no matter what
type of account it is, and those that depend on the subclass or type of account. The actual
balance could be represented by a double in all cases, but the fees might not even exist for
some bank account types, so fees would be present as an attribute in only some of the
subclasses, perhaps. The basic question is what’s the same for all of them, and what is not the
same depending on the specific type.
So, based on the above, we have the following summary to use for the present exercise:
(super, abstract) class BankAccount
attributes: double balance
methods: double getBalance()
abstract methods: calculateAndUpdateBalance()
class SavingsAccount extends BankAccount
attributes: double annualInterestRate (yearly)
overrides calculateAndUpdateBalance() (add the interest for the month)
class ChequingAccount extends BankAccount
attributes: double monthlyFee
overrides calculateAndUpdateBalance() (subtract the fee)
We can now think about the polymorphic processing. Suppose we have thousands of accounts
of various types and we need to calculate the updated balance every month. To keep things
simple, we will not represent deposits and withdrawals; rather, we’ll just add interest earned by
a savings account, or charge the monthly fee for a chequing account. Every month we would
run a loop that goes through a collection of accounts and invokes the
calculateAndUpdateBalance() method on each of these accounts. It is polymorphic processing
because the type of the objects we are processing is a superclass or an interface (in this case, a
superclass). The details of the calculateAndUpdateBalance method come from the sub-class.
Steps
• Write down the Class Diagram UML to represent this program.
o Classes: BankAccount, ChequingAccount, SavingsAccount, BankAccountTest
• Create a package named lab5.
• Implement the UML as Java classes, including Javadoc comments throughout.
• Make up a monthly fee amount and annual interest rate you think are reasonable.
Assign these values to the appropriate properties inside the class constructors.
• Create a BankAccountTest class that declares, instantiates, and initializes 4 bank
accounts.
o Add an instance variable that is an array of BankAccount objects.
o In the default BankAccountTest constructor, initialize the array with 2 instances
of ChequingAccount objects and 2 instances of SavingsAccount objects. Each
BankAccount constructor (and subclass constructor) should take a parameter of
type double with a Random initial balance between 0 – 100.
o The subclass constructor should call the super constructor, and pass the balance
to the BankAccount class.
o Add a method monthlyProcess(BankAccount[] accounts) method that takes an
array of bank accounts as a parameter and does the monthly balance update for
each account by calling calculateAndUpdateBalance() for each.
o Add a display(BankAccount[] accounts) method that outputs the balance of
each account when passed an array of bank accounts as an argument.
o Add a main method that creates an instance of the BankAccountTest class, and
calls the monthlyProcess and display methods 12 times (simulating an entire
year).
Submission Requirements
1. Create a new assignment folder and name it:
CST8132____Lab4.
Note: Your SectionNo should be your Lab Section (311, 312, 313).
2. Place copies of your BankAccount.java, ChequingAccount.java, SavingsAccount.java,
and BankAccountTest.java files in the assignment folder.
3. Add a copy of your UML diagram to the folder, named
CST8132____Lab4_UML.[jpg/gif/docx/vsd]
Example: CST8132_312_Giddings_Angela_Lab4_UML.jpg
4. Create an ZIP file of the assignment, and name it:
CST8132____Lab4.zip.
5. Upload the ZIP file to Blackboard.
Grading Scheme
• Javadoc: 3marks
o Thorough – every class, method, and non-private property has Javadoc.
o Complete tags (@author, @version, @param, @return) where necessary.
o Proper descriptions.
• Java code: 4 marks
o Correct implementation of abstract superclass and subclasses.
o Proper use of polymorphic attributes and behaviors in BankAccountTest class.
o Style – naming conventions, readability, indentation, comments, etc.
o Submission
• UML: 3 marks
o Classes
o Relationships
o Matches Java code
• Code does not compile: -5 marks
