Hands on Testing Java: Lab #11

Inheritance

Introduction

There are three basic capabilities that a modern object-oriented programming (OOP) language (like Java) must provide:

First, an OOP language must provide abstract data types---the ability to create new data types (i.e., classes) that hides data (i.e., private instance variables) and provides a public interface (i.e., public methods). We've used this all along (e.g., the String class), and we've implemented our own since Lab #6 (e.g., Fraction and Coordinate classes).

The second and third capabilities revolve around the similarities found between related, but different, classes. For example, in this lab you will implement classes to represent different types of bank accounts. One of the problems we'll have to solve is computing interest. Interest might be calculated monthly or yearly; it might be simple or compound. There's a similarity and a difference between the solutions for computing interest. How can a programmer take advantage of the similarities and still implement different behaviors?

So the second capability is providing some way to describe the common attributes and abilities of related class. For example, the interest rate is a common attribute for any "yearly interest calculator" and any "monthly interest calculator". It would be useful if we could describe this attribute once and have it apply to all of the different types.

The third capability is providing some way to override common abilities. For example, any interest calculator must be able to compute interest, but how this is done varies from calculator to calculator. In OOP terminology, this is known as polymorphism.

The second and third capabilities come from inheritance. That's the subject of this lab.

Getting Prepared

The Problem Description

Suppose we have been given the task of creating a program that will keep track of the accounts for a bank. There are a number of different kinds of accounts that the bank provides:

• Some charges are done monthly; other charges are based on each transaction. (Note the color coding!)
• The account charge is a flat fee or the percentage of the balance, whichever is smaller.
• Interest rates are expressed in yearly rates, despite their frequency.
• The minimum-balance penalty is applied to every withdrawal when the balance is below the minimum.

Your initial tempation might be to implement four different classes for these four different types of accounts. But this misses the commonalities. Another initial tempation might be to implement just one class for all four accounts, and use instance variables and if statements to handle the different requirements. This misses the simplifying power of inheritance.

Let's first just concentrate on the simplest part of all four accounts, their basic attributes.

Attributes of an Account

Perhaps the most obvious attribute for an account is the balance.

An account is owned by someone, so we should keep track of the account holder's name.

The CD account needs to know how old the account is in order to time its interest payment just right. It's not hard to imagine that other accounts might need this age as well. So we'll also keep track of the number of months that the account has been around.

So that's three solid attributes: a balance, a name, and an age.

The fuzzy part is implementing the differences. Consider them at a very high level in terms of when and why the charges are applied. There are two possibilities:

1. Every account needs to react to individual transactions in different ways (i.e., transaction charge and minimum balance).
2. Every account needs to react at the end of the month in different ways (i.e., account charge and interest).

We're going to be very abstract about these computations. Switch to internal perspective: imagine that as an Account object, I have a list of "calculators" which compute interest and transaction fees and the like for you. I will call these calculators "modifiers" because they will modify my balance.

So we end up with these attributes for an Account class:

Attributes of Account
Description	Type	Name
the balance of the account	double	myBalance
the name of the account holder	String	myName
the age of the account (in months)	int	myAge
transaction modifiers	????	myTransactionModifiers
monthly modifiers	????	myMonthlyModifiers

First off, notice the plurals in the descriptions: "transaction modifiers" and "monthly modifiers". Storing multiple objects should be done with an array or list; since it's unclear how many of these modifiers we will want or need, a list seems like a better approach.

But lists of what? We need to know the element type (like the List of Students in Lab #9), but we don't have element types for the "transaction modifiers" and "monthly modifiers". It looks like we'll need to design some more classes!

Let's call these new classes TransactionModifier and MonthlyModifier. So now the blanks can be filled in:

Attributes of Account
Description	Type	Name
the balance of the account	double	myBalance
the name of the account holder	String	myName
the age of the account (in months)	int	myAge
transaction modifiers	List<TransactionModifier>	myTransactionModifiers
monthly modifiers	List<MonthlyModifier>	myMonthlyModifiers

You need a constructor to initialize the instance variables. You need to receive values for the balance, name, and age. The lists can be initialized to empty ArrayLists.

public void addTransactionModifier(TransactionModifier modifier) {
  myTransactionModifiers.add(modifier);
}

Transaction Modifiers

A transaction modifier needs to be triggered after every transaction (withdraw or deposit money). For example, suppose I'm a bank account, and I have two transaction modifiers. What they do doesn't matter to me because it's their responsibility to do what they do. They might charge for each transaction; they might charge an extra fee if the withdrawal is too large; they might charge a fee going below the minimum; they might even credit the balance if a deposit gets the balance above a minimum.

The key is that as an account, I do not care exactly what the transaction modifiers do. I care only that they modify my balance after a withdrawal or deposit.

So you need code that will ask each transaction modifier what should be done with the balance after a transaction. It's as if the transaction modifiers are an assembly line working on my balance. The first modifier tweaks it a bit and passes it on to the second; the second tweaks the balance some more and passes it on to the third; and so on until the last modifier is done. Each time I pass the current balance (as modified by the previous transaction-modifier) to the current transaction modifier; at the end, I return the balance as modified by the last transaction-modifier.

Inheritance gives us this ability to specify that an object has an ability without actually defining the ability.

It's tempting to get caught up considering all of the transaction modifiers of an account all at once, but it's much better for us to look at individual transaction-modifiers first.

Transaction Modifiers Inheritance Hierarchy

An inheritance hierarchy is a collection of classes that are related through inheritance. You've already imported one inheritance hierarchy: TransactionModifier, MinimumBalancePenalizer, and PerTransactionCharger. Here's a UML diagram for the relationship between the classes:

TransactionModifier is known as the superclass because it is drawn in this diagram above the others. It is also known as the base class because it serves as the base of all of the other classes. That it, it's the most basic version of the other classes.

PerTransactionCharger and MinimumBalancePenalizer are known as subclasses because they are drawn under the superclass. So the diagram allows us to categorize our classes, but what do these categories mean?

Inheritance captures "is a" relationships. A "minimum-balance penalizer" is a "transaction modifier"; a "per-transaction charger" is a "transaction modifier". By saying that PerTransactionCharger or any subclass extends (or inherits from) TransactionModifier, we're saying that anything a TransactionModifier can do, any subclass charger can do as well. How these things are done might be very different in each subclass, but the fact that they can be done is the same for all subclasses.

So you'll see in these classes two methods, one for reacting to a withdrawal of money, the other to a deposit. All transaction modifiers must be able to react to these actions, but how they do it differs.

Let's start from the bottom up.

Per-Transaction Charges

Consider the PerTransactionCharger class. If I am a per-transaction charger, then I need to charge a fee for each transaction. I'll need to keep track of that fee, so I have one attribute:

Attributes of PerTransactionCharger
Description	Type	Name
the amount to charge per transaction	double	myPerTransactionCharge

Now when a withdrawal or deposit is made, I just need to subtract this per-transaction charge from the given balance.

Behavior of PerTransactionCharger#modifyBalanceAfterWithdrawal(double)

I am a per-transaction charger. I will receive a balance, and I will return a new balance computed from the received balance minus my per-transaction charge.

Objects of PerTransactionCharger#modifyBalanceAfterWithdrawal(double)
Description	Type	Kind	Movement	Name
a balance	double	variable	in	balance
a new balance	double	variable	out	newBalance
my per-transaction charge	double	instance variable	instance	myPerTransactionCharge

Operations of PerTransactionCharger#modifyBalanceAfterWithdrawal(double)
Description	Predefined?	Name	Library
receive the balance	yes	parameter	built-in
subtraction	yes	-	built-in
return the new value	yes	return statement	built-in

Algorithm of PerTransactionCharger#modifyBalanceAfterWithdrawal(double)
Receive balance. Let newBalance be balance minus myPerTransactionCharge. Return newBalance.

Minimum-Balance Penalizer

There are many ways to penalize an account for going below a minimum balance. For a little variety, we'll assume that depositing into an account is never penalized, even if the balance is below the minimum. So the algorithm for a modifying the balance after a deposit is simple:

Algorithm of MinimumBalancePenalizer#modifyBalanceAfterDeposit(double)
Receive balance. Return balance.

It's processing a withdrawal that's more interesting:

Behavior of MinimumBalancePenalizer#modifyBalanceAfterWithdrawal(double)

I am a minimum-balance penalizer. I will receive the current balance. If this balance is less that my minimum, then I will return the balance minus my minimum-balance penalty; otherwise, I will return the old balance.

This behavior actually suggests the attributes for the class:

Attributes of MinimumBalancePenalizer
Description	Type	Name
my minimum balance	double	myMinimumBalance
my penalty	double	myPenalty

So back to the method:

Objects of MinimumBalancePenalizer#modifyBalanceAfterWithdrawal(double)
Description	Type	Kind	Movement	Name
the current balance	double	variable	in	balance
my minimum balance	double	instance variable	instance	myMinimumBalance
my penalty	double	instance variable	instance	myPenalty

Operations of MinimumBalancePenalizer#modifyBalanceAfterWithdrawal(double)
Description	Predefined?	Name	Library
receive the balance	yes	parameter	built-in
if... then... otherwise	yes	if statement	built-in
balance is less than my minimum balance	yes	<	built-in
subtraction	yes	-	built-in
return a value	yes	return statement	built-in

Algorithm of MinimumBalancePenalizer#modifyBalanceAfterWithdrawal(double)
Receive balance. If balance is less than myMinimumBalance, then     return balance - myPenalty, otherwise     return balance.

The Inhertance Hierarchy

Previously, without inheritance, you would have to create two instance variables in the Account class, one for a per-transaction charger and another one for a minimum-balance penalizer even if the account doesn't need them.

With inheritance, we've abstracted away the needs of an account; an account onlyneeds something to modify its balance after each transaction; it does not need to know how it will be done. So the Account class does not need to explicitly worry about PerTransactionChargers and MinimumBalancePenalizers; it will worry about the abstraction: TransactionModifier.

Externally, when I create an Account for a particular type of account, then I provide PerTransactionChargers and MinimumBalancePenalizers.

• A PerTransactionCharger is a TransactionModifier. So if the Account asks for a TransactionModifier and I give it a PerTransactionCharger, it will be happy.
• A MinimumBalancePenalizer is a TransactionModifier. So if the Account asks for a TransactionModifier and I give it a MinimumBalancePenalizer, it will be happy.

In order for this to work, the superclass must promise the common methods.

Implementing the Inheritance Hierarchy

To implement this, we're using an interface for the superclass. A class with no instance variables and with only promised methods (i.e., abstract methods, see below) can be declared as a Java interface. These interfaces are still often called "superclasses".

public interface InterfaceName {
  ConstantDeclarations
  AbstractMethodDeclarations
}

The methods in an interface are only promises. TransactionModifier promises that a TransactionModifier object will have modifyBalanceAfterWithdrawal(double) and modifyBalanceAfterDeposit(double) methods. These are written as abstract methods:

public abstract returnType methodName(parameters);

You were given the conventional code; your compiler might even complain after you make the change.

Once the methods have been promised, we want to implement subclasses in this inheritance hiearchy. They have to implement the interface:

public class ClassName implements InterfaceList {
}

By saying PerTransactionCharger implements TransactionModifier, we're saying that PerTransactionCharger must implement the methods promised in TransactionModifier. And, in fact, they do. This is known as overriding a method. Unlike overloading a method which allows you to reuse a method name with a different signature, overriding insists that you use the exact same signature as the method in the superclass: the same method name, the same return type, and the same parameter list.

The compiler forces you to override all of the abstract methods from the interface. This is to ensure that you actually provide behaviors for all of those promised actions.

So now the Account class can go to any of its TransactionModifiers, and ask it to modify the balance after a withdrawal. The Account class does not need to know how this is done; it just needs to know that it can and will be done.

Since you're using TransactionModifier as the element type for the myTransactionModifiers list, we call it a base class. It's the declared type of the elements; we'll actually allocate instances of the subclasses since they can actually do the computations.

Using the Inheritance Hiearchy

You need to be able to withdraw money from an account. Besides the obvious subtraction of the withdrawal amount, you also have to ask each transaction modifier to modify the balance.

Behavior of Account#withdraw(double)

I am an account. I will receive an amount to withdraw. I will set my balance to be my (old) balance minus this amount to withdraw. Then for each of my transaction modifiers, I will set my balance to be whatever the current transaction-modifier modifies it to be.

Objects of Account#withdraw(double)
Description	Type	Kind	Movement	Name
the amount to withdraw	double	variable	in	amount
my balance	double	instance variable	instance	myBalance
my transaction modifiers	List<TransactionModifier>	instance variable	instance	myTransactionModifiers
the current transaction modifier	TransactionModifier	variable	local	modifier

Specification of Account#withdraw(double):

receive: the amount to withdraw
return: nothing

Operations of Account#withdraw(double)
Description	Predefined?	Name	Library
receive the amount to withdraw	yes	parameter	built-in
subtraction	yes	-	built-in
loop through my transaction modifiers	yes	foreach loop	built-in
modifying the balance after the withdrawal	yes	modifyBalanceAfterWithdrawal(double)	TransactionModifier

Algorithm of Account#withdraw(double)
Receive amount. Set myBalance to be myBalance minus amount. Foreach modifier in myTransactionModifiers:     Set myBalance to be the withdraw of modifier and myBalance. End foreach.

To test this method, you will create integration tests. You will still use JUnit just as you have in the past, but you'll end up testing at least three classes (Account, PerTransactionCharger, and MinimumBalancePenalizer) and possibly two or more methods. Strictly speaking, a unit test should just test one unit (i.e., one method from one class). This is tricky to do with the Account class without getting into some advanced JUnit techniques. Integration testing will still give us good feedback, the only problem is that if one thing goes wrong with, say, the PerTransactionCharger class, you'll get failed tests in PerTransactionChargerTest and AccountTest.

To make an account behave like a regular account (as specified in the chart at the beginning of this lab exercise), all you have to do is add the proper modifiers. You haven't written any of the monthly modifiers, and a regular account needs only one transaction modifier. So here's some likely code:

theAccount.addTransactionModifier(new MinimumBalancePenalizer(100, 8));

Incidentally, the numbers here do not match the numbers in the chart of bank accounts.

To make a withdrawal or deposit, the code would look like this:

theAccount.withdraw(500);
theAccount.deposit(25);
theAccount.withdraw(87);

To assert anything about theAccount, I would have to use theAccount.getBalance().

You'll be able to do more extensive testing when you can also deposit money into the account.

The Bigger Picture

Now that you have this inheritance hiearchy plugged into your Account class, you can create new subclasses of TransactionModifier to add to an Account, and you won't have to recompile any of the code that now exists. If you want a per-transaction charger to charge a percentage of the balance (i.e., PercentagePerTransactionCharger), write the class, and start using it. Strictly speaking, you wouldn't even have to add new tests to AccountTest because you'll create a test-case class for the new subclass (i.e., PercentagePerTransactionChargerTest), so you'll know that that class works fine. AccountTest is really just testing to make sure that the modifiers are being activated.

Let's move on to the inheritance hierarchy for monthly fees. This hierarchy will actually have two levels.

Monthly Modifiers

At the end of each month, the age of an account needs to be incremented, and the monthly modifiers must be executed. This is so that account charges and interest can be applied.

Behavior of Account#nextMonth()

I am an account. I will increment my age. I will loop through my monthly modifiers, setting my balance to be the result of telling the current modifier that it's a new month (providing it with my age and my balance).

Objects of Account#nextMonth()
Description	Type	Kind	Movement	Name
my age	int	instance variable	instance	myAge
my monthly modifiers	List<MonthlyModifier>	instance variable	instance	myMonthlyModifiers
the current monthly modifier	MonthlyModifier	variable	local	modifier
my balance	double	instance variable	instance	myBalance

Operations of Account#nextMonth()
Description	Predefined?	Name	Library
increment my age	yes	++	built-in
loop through my monthly modifiers	yes	foreach loop	built-in
notify the modifier of a new month	no	modifyBalanceForNewMonth(int age,double balance)	MonthlyModifier

Algorithm of Account#nextMonth()
Increment myAge. Foreach modifier in myMonthlyModifiers:     set myBalance to be the result of using modifier to modify the balance for the new month. End foreach.

You'll get compilation errors for MonthlyModifiers.

You should now get compilation errors that MonthlyModifier does not implement the modifyBalanceForNewMonth(int,double) method that it should.

Interest Calculators

Interest is calculated at the end of a month, so these interest calculators will eventually be monthly modifiers, but let's first create the calculators themselves.

Let's compare the two types of interest calculators:

Most banks will tell you the interest rate for the whole year, even if it's calculated each month, so calling this attribute "yearly interest rate" for both interest calculators isn't too much of a stretch.

We'll also consider the interest rate to be in "percentage form". That is, the yearly interest rate will be 4.7 if we want a rate of 4.7%; for computations, this will mean dividing by 100.

So the two interest calculators have a common attribute: the yearly interest rate. In order to share a common attribute, we'll have to use an actual class (as opposed to using an interface).

Let's consider this class:

Attributes of InterestCalculator
Description	Type	Name
the yearly interest rate	double	myInterestRate

Now with inheritance, we can tell Java that the MonthlyInterestCalculator and YearlyInterestCalculator should both have this attribute as well. First, as a design:

All of the attributes from InterestCalculator should used in the MonthlyInterestCalculator and YearlyInterestCalculator.

As a UML diagram, it would look like this:

Notice how the instance variable myInterestRate is specified once in the superclass; the subclasses get this instance variable for free. The accessor getInterestRate() you will also get for free in the subclasses!

The syntax for this in Java is actually quite straightforward.

Now the declarations for the other two classes:

This isn't any different from declaring classes in the past. Inheritance with classes (i.e., without an interface) is accomplished with two extra words in the declaration:

public class ClassName extends SuperclassName {
}

The SuperclassName is the name of the class which has the common attributes in it.

Now, whenever you create an instance of either subclass, that instance will have an myInterestRate instance variable in it. If we think of a class as a blueprint, inheritance tells the subclass blueprints to re-use the superclass blueprint. Each subclass is now free to go beyond this common design to declare peculiar attributes if needed. For these interest calculators, there's no need, so we can move on to the abilities of these objects.

Creating Instances of a Subclass

First, we need to be able to create these calculators. You'll want to be able to create calculators like this:

new MonthlyInterestCalculator(3.0)
new YearlyInterestCalculator(12.0)

That's one; now for the second:

You'll get compilation errors for calling constructors which don't exist.

What do you normally do in a constructor? You initialize the instance variables.

This is not as crazy as it sounds. Yes, this instance variable is not declared in MonthlyInterestCalculator, but MonthlyInterestCalculator extends a class which does declare this instance variable.

Remember back to Lab #6 when we talked about private instance variables. By declaring an instance variable as private, no other class gets access to the instance variable. Not even subclasses!

This may sound really strange, because I keep on saying that the subclasses do have the myInterestRate instance variable. They do! The subclasses just don't have direct access to it. This is a good thing because we may want to enforce a variety of invariants on the variable, and maintaining invariants is much easier to do if the superclass has complete control over the variable.

But then, how can the subclasses access this instance variable which is hidden from them? Indirectly, through the superclass!

Start by declaring a constructor for the superclass:

There's an annoying assumption Java makes about constructors. It assumes that at the beginning of a constructor, it first invokes the default constructor from the superclass. Let's make this assumption explicit:

super();

The super keyword, used in a constructor, indicates that you want to invoke a constructor from the superclass. In this case, without any arguments, you're invoking the default constructor.

You've only made explicit what Java assumes; the error messages are just a bit more confusing when the compiler tries to complain about the assumptions.

The problem is that super(); invokes the default constructor of the superclass, but InterestCalculator (the superclass) doesn't have a default constructor! Instead, you should invoke the explicit-value constructor of InterestCalculator that receives the interest rate.

Invoking superclass constructors must be the first statement in a subclass's constructor because the instance variables from the superclass must be initialized first. Otherwise bad things can happen.

There's still a question whether things are actually working out the way that they should. Do instances of the subclasses actually have their own myInterestRate instance variables? Are these instance variables actually being initialized? Test to find out!

For example,

assertEquals("interest rate should be 33.0%", 33.0, myCalculator33.getInterestRate());

You don't even have to declare getInterestRate() in the subclasses, so long as you have it in the superclass.

These three classes demonstrate the two key capabilities that inheritance provides:

1. sharing common definitions of attributes (i.e., InterestCalculator#myInterestRate) and
2. sharing common definitions of abilities (i.e., InterestCalculator#getInterestRate()).

In both cases, the component was declared once in the superclass, and both subclasses get them for free.

Interesting Computation

This perhaps begs the question: why do we have three separate classes? So far, all you've done are the very basics for any class: constructors and accessors. The really interesting components of a class are the computational methods. It's in the the computational methods that the inheritance hierarchy will really pay off.

Let's start with YearlyInterestCalculator#modifyBalanceForNewMonth(int,double).

Behavior of YearlyInterestCalculator#modifyBalanceForNewMonth(int,double)

I am a yearly-interest calculator. I will receive the age of the account and the account's balance. If the age is a multiple of 12, I will return the balance plus (the balance multiplied by my interest divided by 100.0); otherwise, I will return the account's balance.

I divide by 100.0 because the interest rate is given in percentage form (i.e., 3.0 for 3%).

Objects of YearlyInterestCalculator#modifyBalanceForNewMonth(int,double)
Description	Type	Kind	Movement	Name
the age of the account	int	parameter	in	age
the account's balance	double	parameter	in	balance
my interest rate	double	instance variable	instance	getInterestRate()

Specification of YearlyInterestCalculator#modifyBalanceForNewMonth(int,double):

receive: the age of the account, the account's balance
return: the accrued interest

Operations of YearlyInterestCalculator#modifyBalanceForNewMonth(int,double)
Description	Predefined?	Name	Library
receive values	yes	parameters	built-in
if... then... otherwise	yes	if statement	built-in
age is a multiple of 12	yes	mod 12 is 0	built-in
return a value	yes	return statement	built-in
add balance and interest	yes	+	built-in
multiply balance by my interest rate	yes	*	built-in
divide by 100.0	yes	/ 100.0	built-in

Algorithm of YearlyInterestCalculator#modifyBalanceForNewMonth(int,double)
Receive age and balance. If age mod 12 equals 0, then     return balance + balance * getInterestRate() / 100.0; otherwise     return balance.

Before coding this, write some tests.

public void testModifyBalanceForNewMonth() {
    assertEquals("no interest on 3rd month", 1000.0,
      myCalculator4.modifyBalanceForNewMonth(3, 1000.00), 1e-3);
    assertEquals("no interest on 7th month", 1000.0,
      myCalculator4.modifyBalanceForNewMonth(7, 1000.00), 1e-3);
    assertEquals("4.0% interest on 12th month", 1040.0,
      myCalculator4.modifyBalanceForNewMonth(12, 1000.00), 1e-3);
    assertEquals("6.0% interest on 12th month", 106.0,
      myCalculator6.modifyBalanceForNewMonth(12, 100.00), 1e-3);
    assertEquals("no interest on 13th month", 100.0,
      myCalculator6.modifyBalanceForNewMonth(13, 100.00), 1e-3);
    assertEquals("6.0% interest on 24th month", 106.0,
      myCalculator6.modifyBalanceForNewMonth(24, 100.00), 1e-3);
    assertEquals("no interest on 35th month", 100.0,
      myCalculator6.modifyBalanceForNewMonth(35, 100.00), 1e-3);
    assertEquals("6.0% interest on 36th month", 106.0,
      myCalculator6.modifyBalanceForNewMonth(36, 100.00), 1e-3);
}

Keep in mind that the calculator keeps no history. That is, it computes a new balance based on the balance it's given. So even though myCalculator6 triggers an interest payment, it does not accumulate because that's not the responsibility of the calculator. Its responsibility is to compute a new balance based on the balance it's given in the method and based on its logic.

Accumulating the interest is the responsibility of an Account object (as computed by an interest calculator).

This test method gives a pretty thorough coverage of a variety of cases: different ages, different balances, different interests.

Plugging the Method into the Inheritance Hierarchy

Using the signature modifyBalanceForNewMonth(int,double) for this method was no coincidence. We'll eventually plug this inheritance hiearchy into the MonthlyModifier hierarchy.

YearlyInterestCalculator#modifyBalanceForNewMonth(int,double) explains why we need both the age and balance passed into the method. The process established in Account#nextMonth() is that all monthly modifiers are told to modify the balance each month. They have the option of not modifying the balance at all.

Interest is computed from a balance, so clearly that's information needed by a compute-interest method. Hence, the balance parameter.

The age is necessary for the modifiers that do not react every month (like the YearlyInterestCalculator).

What's lacking right now is a promise from the superclass that all interest calculators will have this method. Unlike other classes and their methods, all that can be done is give a promise for the method because we don't know what algorithm to implement for InterestCalculator#modifyBalanceForNewMonth(int,double). The issue here is responsibility. It is not the responsibility of a plain InterestCalculator to implement an algorithm; inheritance allows that responsibility to be passed on to the subclasses which can better implement the algorithms (plural!).

This is the same issue we had with TransactionModifier; we needed to promise some behaviors.

Promising a method in a superclass is done by declaring an abstract method, whether the superclass is implemented as an actual class or interface:

public abstract returnType methodName(parameters);

Unlike an interface, where the abstract keyword is optional, abstract methods in an abstract class must use the abstract keyword since they're a special case in a class.

Consider this code:

InterestCalculator calculator = new InterestCalculator(33);
assertEquals(0.0, calculator.modifyBalanceForNewMonth(5, 100.0), 1e-3);

What code should be executed for calculator.modifyBalanceForNewMonth(5, 100.0)? It depends, of course. If it were a yearly calculator, it could use the computation you just implemented; if it were a monthly calculator, it would use a different algorithm. But the code above doesn't commit itself to one of these specific interest calculators.

This is useless to us. We cannot have a general interest calculator trying to calculate interest.

To prevent this problem, Java requires that a class with an abstract method be declared as an abstract class. An abstract class cannot be constructed directly (i.e., with new). Subclasses are welcome (and still required) to invoke the superclass constructors, but you can never invoke a constructor of an abstract class directly. So the first line of this code would generate a compiler error.

public abstract class ClassName {
}

As an abstract class, no one can create an instance of InterestCalculator, and so the problematic code above generates a compiler error on the constructor call. If one cannot create an problematic object, one cannot even try to call the problematic method.

Since the subclasses want to be concrete (as opposed to abstract), you have to provide actual definitions for the method.

So the next trick is to write real code for this stub.

Algorithm of MonthlyInterestCalculator#modifyBalanceForNewMonth(int,double)
Return balance + balance * getInterestRate() / 100.0 / 12.0.

Integrating It All

The last step to plugging the interest calculators into the account classes is to add the interest calculators to the monthly-modifiers hierarchy.

This will work immediately because we're already implementing the necessary method in InterestCalculator that MonthlyModifier requires.

You haven't actually tested the interest calculators in the accounts yet. This is just to make sure that adding the monthly modifiers don't break anything you've already tested.

But the next step is to test the interest calculators:

Submit

Submit copies of your code (including classes you didn't modify) and the answers to the questions. Include a sample execution of your test-case classes.

Terminology

abstract class, abstract data type, base class, base class, extends, implement (an interface), inheritance, inheritance hierarchy, inherit from, integration test, interface, override (a method), subclass, superclass