On this page:
5.1 Partners
5.2 Hourglass tutorial:
5.3 Defining equality
5.3.1 Getting started
5.4 Two approaches:   bad and good
5.4.1 Bad Option - Incorrect alternative:
5.4.2 Good Option - A Better alternative:
8.5

Lab 5: Sameness

Goals: Practice designing equality methods for union data types

Related files:
  Banking.zip  

Reminder: You must be in lab to take the quiz.

5.1 Partners

You will get a partner to work with on the next assignment (Assignment 5). If you and another student *in your lab section* agree that you want to work together, you may make a request in handins to be partners. Both of you must make this request in handins. If you do not have a preference, we will randomly assign a partner for you. You should work on this lab with your partner once they are assigned.

5.2 Hourglass tutorial:

To prepare for Exam 1, please do the Hourglass tutorial at https://hourglass.khoury.northeastern.edu/. Use your Khoury account to login.

5.3 Defining equality
5.3.1 Getting started

For this part of the lab we will work with classes that define bank accounts: a checking, savings or credit line account. Download the Banking.zip file that represents this class hierarchy and start a new project. Make two examples of each type of account as well as examples of lists of accounts and banks.

Implementing the sameBank method

Our object is to define a method that will determine whether a given Bank is the same as this Bank. We will need methods to compare lists of accounts and all accounts in them.

Of course, now that we have the abstract class it would be easy to compare just account numbers and the name on the account, but we want to make sure that all the customer’s data matches what we have on file exactly, including balances, interest rates, etc.

We will design the method same similar to the technique described in the lecture, sameness by double dispatch. The relevant examples can be found in the lecture notes. You may want to look at the code there as you work through this problem.

5.4 Two approaches: bad and good
5.4.1 Bad Option - Incorrect alternative:

A method to compare Accounts can be badly written with two features of the Java language: the instanceof operator and casting. In the Checking class this style method would look like the following:

// Is the given Account the same as this Checking? boolean sameAccount(Account that){
if(that instanceof Checking){
return this.sameChecking((Checking)that);
}
else {
return false;
}
}

However, this version introduces bugs!

The issue is that any class that later extends Checking, say a PremiumChecking class, will also be considered a Checking instance by the instanceof operator.

If we implement a similar same method in PremiumChecking:

// Is the given Account the same as this PremiumChecking? boolean sameAccount(Account that){
if(that instanceof PremiumChecking){
return this.samePremChecking((PremiumChecking)that);
}
else {
return false;
}
}

Now only a PremiumChecking object can be the same as the given instance of the PremiumChecking class.

But an instance of the Checking class can be the same as the given instance of the PremiumChecking class!

These kinds of bugs can cause serious problems.

5.4.2 Good Option - A Better alternative:

In Lecture 12: Defining sameness for complex data, part 2 we introduced another approach that works better. It requires us to add a new method to the abstract class for each subclass of Account, and relies on double dispatch to produce the correct answer. Following your notes from class, implement the helpers for sameBank using double dispatch. Make sure to test all the methods very well.