CS 10: Spring 2014

Lecture 4, March 31

Code discussed in lecture

Short Assignment 3

Short Assignment 3 is due Wednesday.

How to get console input from the keyboard

When you want to read keyboard input from the console, you use Java's Scanner class. It's not as builtin as System.out is, however, and so you need to use the import statement

import java.util.Scanner;

In your program, you have to create a Scanner object, associate it with the keyboard, and give it a name. The program in Input.java provides an example. First, create a Scanner object, and pass its constructor the special object System.in. Just as System.out means output to the console, System.in means input from the console. In this example, we have the line

    Scanner input = new Scanner(System.in);

There's nothing special about the name input; you can use whatever name you want for the reference to the Scanner object. (You might notice the little warning next to this line. It reads, "Resource leak: 'input' is never closed." Generally speaking, when you get input from somewhere, you should close it when you're done. Try adding the line

    input.close();

at the end of the main method. We don't worry about closing the console input, however, and so we live with the warning.)

We have to call the appropriate method for whatever type of data we expect to read from the keyboard. If we want to read an int, we call nextInt. If we want to read a double, we call nextDouble. If we want to read a long, we call nextLong. These methods, and others, appear in the Java documentation.

Note that we don't need to create a new Scanner object each time we want to read input from the keyboard. Instead, we create just one Scanner object and reuse it each time.

How would you read a character string from the keyboard? If we want all the input that has been typed into the current console line and has not yet been read, we can call nextLine. For example, suppose that I've typed the following into the console:

lions and tigers and bears

And let's suppose that lions and has already been read in by some previous calls to a method on a Scanner object named input. Then if I execute the line

String restOfLine = input.nextLine();

the result is that restOfLine will hold the character string tigers and bears.

The other method for reading character strings from the keyboard is next, and it reads the next token. What's a token? Normally, it's the next "word," where words are separated by spaces and newlines. In our example, if we've ready read in lions, then

String token = input.next();

results in token holding the character string and. If we were to then call input.next() again, it would read tigers.

You can check that there is a next token and that it's of the correct type by calling the methods hasNextInt, hasNextDouble, hasNextLong, etc.; each of these methods returns a boolean. The Scanner class includes other "has" methods; see Section 1.6 of the textbook.

ArrayLists

If you've programmed in C but not Python, then you're used to arrays. You can access the element at a given index quickly—in constant time, in fact. But if you've programmed in Python but not C, you're used to Python lists, which also allow you to dynamically append, insert, and delete elements at any location in the list. Arrays in Java do not allow you to do these operations unless you code them up yourself. In fact, just appending or inserting into a Java array can be a pain, because arrays in Java have a fixed length. If you want to insert into an array that is full, you need to allocate a new array, copy everything into it, and then insert. And if some other code has a reference to the array, then you need to update that reference. Yuck!

Instead, one of the available classes in Java is the ArrayList, which is a lot like a Python list. To use it, you have to add the line

import java.util.ArrayList;

to your .java file. The driver ArrayListDriver.java shows an example of using an ArrayList. The file has the above import statement. It also needs some random numbers, and so we also have the line

import java.util.Random;

The main method has the declaration with initialization

    ArrayList<GeomShape> shapes = new ArrayList<GeomShape>();  // a polymorphic ArrayList

When you declare an ArrayList, you have to say what kinds of objects will be in the ArrayList. You use Java's generics feature to do so, by putting a class name inside the angle brackets. Here, shapes is a reference to an ArrayList object in which each item is a reference to an object from some class that implements the GeomShape interface that we saw last time. In particular, each item in this ArrayList will reference either a Circle or a Rectangle object.

Because an ArrayList is an object, we use Java's new operator to create it. We still have to use the generics feature when we create the ArrayList, saying new ArrayList<GeomShape>(). The default constructor for ArrayList creates an empty ArrayList object.

In order to randomly create objects to add to the ArrayList, we create an object from the Random class, which gives us a random-number generator. We call the method nextInt, which returns an int in the range from 0 to 1 less than its parameter. For example, if I need an int value that is either 0 or 1, I can call generator.nextInt(2). We also call the method nextDouble, which returns a double in the range from 0.0 to 1.0; we can scale this value as necessary to get it into whatever range we really wanted.

The first for-loop appends references to eight randomly chosen objects, each either a Circle or a Rectangle, to shapes. You can see how the method getRandomShape randomly chooses to create either a Circle or a Rectangle and then randomly chooses the parameters of the object. The add method ArrayList appends to the ArrayList if you give it just one parameter.

The second for-loop prints out each of the objects referenced in the ArrayList. To get the value in the ith position of the ArrayList, we call the get method with a parameter of i. We cannot use square brackets to subscript into an ArrayList because it is not an array.

Then, we use the two-parameter form of the add method to insert a shape into the middle of the ArrayList. It goes into position 3, and all references after this position move one index higher, as the third for-loop shows.

Next, we remove the reference that is currently at index 5. (It was originally at index 4, but it got bumped up when we added the shape at index 3.) The remove method takes an index and removes the reference at that index, with all references following it moving one index lower to close up the gap. The fourth for-loop shows the result.

Finally, we demonstrate the indexOf method. You give it a parameter that is a reference, and it returns the index in the ArrayList of the first occurrence of that reference. If the reference is not anywhere in the ArrayList, then indexOf returns  - 1.

The Java documentation tells you everything about the methods of the ArrayList class. The following methods are the ones you most frequently use. Here, E stands for the type that the ArrayList references (GeomShape in our example).

A word about what the contains, indexOf, and remove methods do. Specifically, how does the ArrayList decide whether the object obj is at a particular position? Every class has a method named equals, which returns a boolean indicating whether two objects are "equal." The writer of the class gets to determine what "equal" means, with the default being "are the same object," i.e., the two references in question hold the same address. But you might decide that two distinct objects can be "equal" if, say, some of their instance variables are equal. For example, you could say that two Circle objects are equal if they have the same center and radius. Anyway, the contains, indexOf, and remove methods call the equals method of the class that obj references to decide whether there's a match.

Take a moment to look at the Java documentation to see what other methods the ArrayList class provides.

Wrapper classes and autoboxing

Notice how the ArrayList in the example held references to objects. Could it have held primitive types, such as an int? After all, an array can hold either primitive types or references. But an ArrayList cannot; it can hold only references.

But what if you really wanted an ArrayList that holds ints? Java provides wrapper classes that allow you to treat primitive types like objects. (If you recall the discussion of the Smalltalk language, it would need no such facility, since everything, and I mean everything, is an object.) The class names for the wrapper classes are Boolean, Character, Byte, Short, Integer, Long, Float, and Double. So, if you wanted an ArrayList holding integer values, you could declare

ArrayList<Integer> intList = new ArrayList<Integer>();

What's nice is that you can now treat this ArrayList as though each element was in fact an int, even though each element is really a reference to an Integer object. For example:

intList.add(7);
int n = intList.get(0);

Java has features called autoboxing and unboxing. When you use an int where an Integer object is expected, as in the call to add, Java automatically converts the int to an Integer for you. The Integer object holds that int value. That's autoboxing. When you use an Integer object where an int is expected, as in the assignment to n, Java automatically converts the Integer to an int; that's unboxing.

There are some subtleties that can mess you up. The following two calls do very different things:

intList.remove(3);
intList.remove(new Integer(3));

The first call removes the element at index 3. The second call removes the first element in the ArrayList whose value is 3.

Inheritance

We have already seen several of the key ideas of object-oriented programming. The most important one we have yet to see is inheritance.

Inheritance is a way to create new classes from existing classes. We call the existing class the superclass and the new class created from it the subclass. With inheritance, each object of the subclass "inherits" the instance variables and methods of the superclass. That way, we don't have to write these methods for the subclass unless we want to.

Of course, we'll want to write some methods in the subclass, for if we don't, the subclass is exactly the same as the superclass and there would have been no point in creating the subclass. Compared with objects of the superclass, objects of the subclass have additional specialization.

We used interfaces to provide polymorphism: the ability of an object reference to refer to more than one type of object. We will see that inheritance gives us another, very powerful, way to achieve polymorphism. So now we have two ways to achieve polymorphism: interfaces and inheritance.

The Golden Rule of Inheritance

I'll give you some generalities about superclasses and subclasses that seem abstract at the moment, but we'll see a little later how they apply to object-oriented programming by specific examples.

If there is one thing you should remember about inheritance, it is

Use inheritance to model "is-a" relationships and only "is-a" relationships.

What does this mean? Suppose we have two classes: A is the superclass of B (which is therefore the subclass). If we have used inheritance correctly, then

The BankAccount class

For our first example of inheritance, we will look at bank accounts. BankAccount.java is a basic bank account class. It has an instance variable balance that holds the current balance. It has two constructors. The first creates a new account with a balance of 0.00. The second takes in an initialAmount and uses that for the initial balance.

The BankAccount class also has a set of useful methods:

  public void deposit(double amount)
  public void withdraw(double amount)
  public double getBalance()
  public void transfer(BankAccount other, double amount)
  public String toString()

The deposit, withdraw, and getBalance methods do what you would expect. The transfer method transfers amount from the current bank account (referenced by this) to the bank account referenced by other. The method toString converts the information about the bank account to a String. (As you recall, every object in Java has a toString method defined for it, and System.out.println uses toString to print the value of the object.)

We have seen much more complicated examples of classes. Perhaps the most interesting characteristic of our BankAccount class is the calls to withdraw and deposit within transfer. We could have written this method differently:

  public void transfer(BankAccount other, double amount) {
    balance -= amount;
    other.balance += amount;
  }

(Notice that a method may refer to private instance variables of another object in the same class. This capability has nothing to do with inheritance, but it's good to remember that methods of a class can always access instance variables of any object in the class for which they have a reference, not just the object referenced by this.)

But instead, we chose to write the transfer method by having it call the withdraw and deposit methods. Why? If something changes about the way the withdrawals or deposits are done (for example, if we have the withdraw method check for overdrawn accounts) then transfer will automatically use the modifed methods. Abstraction works in our favor even within a class.

Banks offer many kinds accounts, though. A savings account pays periodic interest. A checking account pays no interest and may have transaction fees for deposits and withdrawals. A time deposit account may have an interest penalty for early withdrawal. We could write a separate class for each of these variants of bank accounts. We would reproduce a lot of code, however. All of these different accounts have a balance, and they all have to deal with deposits, withdrawals, getting the account balance, transfers, and converting their contents to a String. Much of the code will be identical or only slightly modified.

It is this situation that inheritance was designed to deal with. The goal is to "inherit" the instance variable balance and the various methods. Methods can be used as is, if they already do the right thing. If not, they can be overridden by writing new versions of some of the methods for the new account types. These new versions, however, can call the old versions to help them out if they need to.

The SavingsAccount class

Our first subclass is SavingsAccount, defined in SavingsAccount.java. A savings account is just like a basic bank account, except that it pays interest. All the methods for the BankAccount class work fine for the SavingsAccount class. The SavingsAccount class has to add an instance variable interestRate and a method addPeriodicInterest, but otherwise it is just a BankAccount.

We indicate that SavingsAccount is a subclass of BankAccount by adding the words extends Bankaccount at the end of the header of the class declaration. Because SavingsAccount is a subclass of BankAccount, SavingsAccount will have copies of all the instance variables and methods of BankAccount. It can then add the declaration for the new instance variable interestRate and the new method addPeriodicInterest. Thus, every SavingsAccount object has two instance variables:

A couple of complications arise, however. First, although every SavingsAccount object has an instance variable balance, because this instance variable is private to BankAccount, no methods of SavingsAccount are allowed to access it directly. This restriction may seem strange at first, and there is in fact a way to let a subclass have direct access to instance variables of the superclass. The trick is to use protected access instead of private access when declaring the instance variable in the superclass. We will discuss this idea later. But we can deal with private instance variables in the superclass in the same way that any other class would: access them indirectly via methods.

The addPeriodicInterest method demonstrates this idea. The getBalance and deposit methods of BankAccount give indirect access to balance, and they are all that are needed to write addPeriodicInterest. But how is it determined what methods getBalance and deposit refer to?

Let's look at deposit. We know that the method call deposit is really an abbreviation for this.deposit. We first look in the SavingsAccount class to see whether SavingsAccount defines a deposit method. It does not. And so we look into the superclass BankAccount. Because we find a definition of deposit there, we need look no further. If we had not found deposit in the BankAccount class, then we would look at BankAccount's superclass, if there is one. Eventually, we either find a superclass that defines the deposit method or we don't. If we do, we use the first superclass that defines the method. If we don't, then we have an error: we have called a method not defined for the class.

The constructors get a bit trickier. We cannot see (and in general may not even know the names of) the private instance variables in BankAccount. How do we initialize them in our constructors?

It turns out that a constructor for the superclass (BankAccount) will always be called in the subclass (SavingsAccount) constructors. The only questions are which superclass constructor is called (recall that BankAccount has two constructors), and whether the call is explicit or implicit.

The first constructor for SavingsAccount has an implicit call of the superclass constructor. The only code appearing in the first constructor sets the instance variable interestRate. Because there is no explicit call to the superclass constructor, the Java compiler automatically inserts a call to the superclass's default constructor—the one with no parameters—as the first line of the subclass constructor. In this case, balance is initialized to 0.00 by the implicit call of the default constructor for BankAccount, and then interestRate is initialized by the constructor for SavingsAccount.

The second SavingsAccount constructor explicitly calls the superclass constructor by calling super(initialAmount) as its first line. We'll see several uses of the reserved word super in our bank account example. Here, we use it to call the one-parameter constructor of the superclass BankAccount. When a subclass constructor explicitly calls its superclass's constructor, this call must be the first line of the subclass constructor.

Let's return to the "golden rule" business above. We have made SavingsAccount a subclass of BankAccount. Have we fulfilled all four relationships that we said must hold?

It is important to note that these relationships go only one way. For example, is every bank account also a savings account? No, it is not true. Checking accounts are bank accounts that are not savings accounts. Or we can ask if a property is true of a savings account, is it also true of a bank account? No, for we can add interest to savings accounts by calling addPeriodicInterest, but we cannot add interest to checking accounts; a call of addPeriodicInterest on a checking account would make no sense.

It may be a bit confusing at first when you realize that a subclass is a subset of its superclass, yet the subclass may contain more instance variables and methods than the superclass. (I know that it confused me at first.) After a while, you get more comfortable with it.

The CheckingAccount class

The CheckingAccount.java class again is similar to the basic BankAccount class, but it incorporates transaction fees. In this implementation, the account owner gets FREE_TRANSACTIONS free transactions per month (3). After that, the account owner must pay a TRANSACTION_FEE for each additional transaction (50 cents). These fees are assessed at the end of each month. We have declared the constants FREE_TRANSACTIONS and TRANSACTION_FEE as static and final since they will never change (hence final) and they should be the same for all checking accounts (hence static).

Rather than worrying strictly about months, our implementation of the CheckingAccount class just worries about some period of unspecified length. The instance variable transactionCount counts the number of transactions that have occurred in the current period. To keep this variable up-to-date, we increment transactionCount every time we make a deposit or a withdrawal. The methods deposit and withdraw that are inherited from the superclass BankAccount do not handle incrementing transactionCount. We must therefore override these methods by writing new versions of them.

We can describe the desired behavior of CheckingAccount's withdraw method as

Do what the normal withdraw in BankAccount does, and then increment transactionCount.

Our implementation of withdraw in CheckingAccount does so. The code

  super.withdraw(amount);

says to call the withdraw method of the superclass. (If we left off the super. it would try to call this.withdraw, which is the same method we are writing. We'd get a recursive call of the same method with the same parameters, which would cause infinite recursion. Big trouble.) Our implementation of the deposit method is analogous.

The new method deductFees takes care of transaction fees by computing the amount to be charged, withdrawing it from the account, and then setting transactionCount back to 0. It performs the withdrawal by calling super.withdraw. (In this case, just calling withdraw would also work. It would increase the number of transactions, but that gets immediately set back to 0. It is safer to use withdraw from the superclass, which does not deal with transaction fees.)

The TimeDepositAccount class

Our last class in this hierarchy of bank accounts is the TimeDepositAccount class in TimeDepositAccount.java. It is like the SavingsAccount class, except it has to charge a penalty for early withdrawal. Therefore it is a subclass of SavingsAccount. Note that it inherits the methods deposit, withdraw, getBalance, transfer, and toString from BankAccount. Why? The direct superclass of TimeDepositAccount is SavingsAccount, and these methods are not overridden in SavingsAccount. Therefore, they come from the superclass of SavingsAccount, which is BankAccount. On the other hand, TimeDepositAccount inherits the method addPeriodicInterest from SavingsAccount. For instance variables, TimeDepositAccount inherits balance from BankAccount, and it inherits interestRate from SavingsAccount; because they are private, neither of these inherited instance variables is directly accessible within methods of TimeDepositAccount.

TimeDepositAccount overrides both addPeriodicInterest and withdraw. In both cases, much of the work is done by calls to super.addPeriodicInterest and super.withdraw.

A driver program that demonstrates polymorphism and dynamic binding

AccountTest.java exercises the bank account classes. It also shows that inheritance allows polymorphism and dynamic binding, as we are about to see. In this program, three accounts are created, one of each of our subclasses:

Each of these objects is created using new and constructors.

Let's examine the method calls this program makes.

First is the call

  momsSavings.deposit(10000.00);

Because momsSavings references a SavingsAccount object, we first see whether SavingsAccount defines a deposit method. It doesn't, so we go to the SavingsAccount's superclass, BankAccount. That's where deposit is defined. We conclude that this call of deposit actually invokes the deposit method defined in the BankAccount class. We could use the debugger to confirm this observation.

Next is the call

  momsSavings.transfer(harrysChecking, 2000);

Like deposit, the method transfer is not defined in SavingsAccount, but it is defined in the superclass, BankAccount. Thus, what is invoked is BankAccount's transfer method.

But there's something even more interesting going on in this call. The first formal parameter to transfer—other—is declared to be a reference to BankAccount. But when we look at the corresponding actual parameter, it is harrysChecking, which is a reference to CheckingAccount. This is OK, because of what is called the subclass principle:

Any variable that is declared to be a reference to an object of a superclass may actually reference an object of a subclass.

This principle applies as well to the variable this within non-static methods.

In fact, we've been using the subclass principle already. When we called momsSavings.deposit, the deposit method expected this to be a reference to a BankAccount object, but it was actually a reference to a SavingsAccount object—the subclass principle at work!

Let's continue examining the call of transfer. It first calls withdraw on the same object—the one that momsSavings references—on which it was invoked. That part's easy. But then it calls deposit on the object that other references—and that's the CheckingAccount object referenced by harrysChecking. Here's where polymorphism and the related concept of dynamic binding come into play. Although the declaration of deposit says that other is a reference to a BankAccount object, the way that transfer was called, other is actually a reference to a CheckingAccount object. And so it is the deposit method in the CheckingAccount class that is actually invoked.

This example shows the idea of polymorphism and dynamic binding. We have multiple versions of a method, appearing in various places within an inheritance hierarchy. Regardless of what class a method call appears in, which method is actually called depends only on the class of the object it is called on.

The calls to harrysChecking.withdraw are now straightforward: they call the withdraw method of the CheckingAccount class.

Then there are three calls to the static method endOfMonth, and this method is overloaded. Version 1 takes a reference to a SavingsAccount, and version 2 takes a reference to a CheckingAccount. In the first call, the actual parameter is momsSavings, a reference to SavingsAccount, and so the version of endOfMonth actually invoked is version 1. In the second call, the actual parameter is collegeFund, a reference to TimeDepositAccount. We have no overloaded version of endOfMonth that takes a reference to TimeDepositAccount, but version 1 takes a reference to TimeDepositAccount's superclass SavingsAccount. We apply the subclass principle, which says that it's OK to invoke version 1 and substitute a reference to TimeDepositAccount in place of a reference to SavingsAccount. Finally, in the third call, the actual parameter is harrysChecking, a reference to CheckingAccount, and version 2 of endOfMonth is actually invoked.

We conclude by looking at the System.out.println calls. The first one has the actual parameter "Mom's savings. " + momsSavings. Here, the Java compiler calls momsSavings.toString in order to convert momsSavings to a String that it can concatenate with "Mom's savings. ". The only version of toString that we have implemented in this class hierarchy is in BankAccount, and so that is the method invoked. The same holds for all the other implicit calls to toString that occur in the System.out.println calls in this example.

Dynamic binding and overloading

Although dynamic binding and overloading seem similar, there is an important difference between the two concepts. The program AccountTest2.java illustrates the difference. It's the same as AccountTest.java, but with six lines changed:

Something seems fishy here, doesn't it? Why is it OK to have momsSavings, collegeFund, and harrysChecking all declared as references to BankAccount and the calls to deposit, transfer, and withdraw work but the calls to endOfMonth require us to cast?

The difference is in how the calls are made. When we call deposit, transfer, or withdraw, the object reference is to the left of the dot, e.g., harrysChecking.withraw(200). When the reference is to the left of the dot, then and only then do we get dynamic binding. In other words, when the reference is to the left of the dot, the decision as to which method is actually called occurs at run time. When we call a non-static method but we don't supply a reference and a dot, then the method is called on this, and we still decide which method is called based on the type of the object that this references.

On the other hand, observe that in the calls to endOfMonth, the object reference is not to the left of the dot. Instead, it's a parameter. In this case, no dynamic binding occurs. The decision as to which method is called is made at compile time, and it is based on how the reference is declared. The decision has nothing to do with what kind of objects the references really refer to! We call this compile-time decision static binding. In AccountTest2.java, momsSavings, collegeFund, and harrysChecking are all declared as references to BankAccount, and there is no version of endOfMonth that takes BankAccount, or any superclass of BankAccount, as a parameter. Thus, we must cast each of these references to the appropriate class so that the compiler can make the proper decision at compile time.