Exercise Sheet B

Last Week's Exercise

We are looking over your submissions for exercise sheet A. On the whole they were good. Luckily, you get the chance to make them even better.

We are writing some comments onto them now and will hand them back to you in the next couple of weeks. I will then notify you by email of the date for resubmission of your improved versions.

Some problems cropped up time and time again. I summarise a few of them here:

There were 16 examples given in a table at the end of the exercise sheet. Too many of you did not handle all 16 correctly.
16 examples were given and some of you decided that all you had to do was get the right answer for these 16. But the point of the exercise was to check user strings to make sure that they obeyed a number of rules that I gave in the exercise sheet. I tested your programs with three additional pieces of test data. Too many of you got incorrect answers for these three pieces of data.
There was in some cases a poor choice of variable names, e.g. lots of uses of s, s1, s2, str2, etc., where, e.g., host or hostName would have been better.
There are naming conventions among Java programmers which some of you were not following. E.g. the names of local variables should begin with lowercase letters. E.g. host, not Host.
Layout was often messy. Curly braces weren't always aligned. Some of you are still using tabs instead of spaces. If, when you press tab, your editor puts spaces into the file, then that's fine. But if, when you press tab, you editor puts a special character into the file, then your file will not print nicely on a majority of printers. So the general advice is: avoid tabs.
Some of you are indenting way too much: put your code into columns 1, 3, 6, 9,... or 1, 4, 8, 12,... Starting your program a third of the way across the page looks bad; also your program will be too wide to be printed properly on A4 paper.
Create strings using the short-cut. There really is no need to use the longer form (new String(...)).
Your for-loops were often very messy. They showed that you were using trial-and-error to work out whether the counter should start/end at 0, 1, str.length() or str.length() - 1 and whether the test should use < or <= or =. Use reasoning, not trial-and-error!
In particular, those of you who are using this:
```
for (int i = 0; i <= str.length() - 1; i++)
```
should abandon it in favour of the following
```
for (int i = 0; i < str.length(); i++)
```
which is (a) equivalent in terms of how many times we go round the loop, (b) easier on the eye, and (c) more efficient.
If you break a method up into smaller methods (which, if done properly, is a good thing to do), there is no need to separate the methods with great long lines of equal signs or hyphens.

Many of you wrote code like this:

public static boolean checkProtocol(String theProtocol)
{  if (theProtocol.equals("http://"))
   {  return true;
   }
   else
   {  return false;
   }
}

But the following is equivalent and much more concise:

public static boolean checkProtocol(String theProtocol)
{  return theProtocol.equals("http://");
}

Exercise

Your work for this exercise sheet will be automatically collected in (if you put it in the right place) at 5 p.m. on Friday 8th November.

Create a subdirectory of your cs2000 directory. Call this new directory sheetB. Place your answers to this exercise in your cs2000/sheetB directory.

This exercise gives you practice in writing a fairly straightforward class definition (`blueprint'). In particular, you will be writing a class definition called ATM, which represents simplified ATMs (automated teller machines, i.e. hole-in-the-wall cash dispensers) for an international bank. Machines in different countries will be loaded with banknotes of different denominations depending on the currency of the country.

Read the whole exercise before writing any code.

Part 1

Create a file ATM.java in which you will write a class definition (`blueprint') for ATMs. (Do this by copying and editing the template mentioned in the lecture.)

Here's some client code, which will become clearer as you read the rest of the exercise:

int[] euroDenoms = {5, 10, 20, 50}; // denominations
ATM atm = new ATM("euro", euroDenoms); // create the ATM
atm.load(5, 1); // load it with 1 x 5 euro notes
atm.load(20, 3); // load it with 3 x 20 euro notes
atm.load(50, 2); // load it with 2 x 50 euro notes
System.out.println(atm.getQty(20)); // print how many 20 euro notes
atm.display(); // display the contents
atm.dispense(50, 1); // dispense 1 x 50 euro note to a customer
System.out.println(atm.getTotal() + " " + atm.getCurrency()); // print total

Each ATM must know

what currency it contains. This is stored as a String, e.g. "euro", "dollar", "peso".
what banknote denominations (face-values) there are for that currency. This is stored as an array of ints. For example, if this currency's banknotes come in denominations of 5, 10, 20 and 50, then these are the values that will be stored in the array. Throughout this exercise, you may assume that the values in this array are sorted in ascending order.
how many of each banknote the machine currently contains. This is stored as another array of ints, of the same length as the previous array. If this array contains {1, 0, 3, 2} and the denominations array contains {5, 10, 20, 50} and the currency variable contains "euro", then this shows that this machine contains 1 note worth 5 euro, 0 notes worth 10 euro, 3 notes worth 20 euro and 2 notes worth 50 euro.

(So, define three instance variables!)

The interface of your ATM class should consist of the following:

Constructor
```
public ATM(String theCurrency, int[] theDenominations)
```
When client code invokes the constructor, the client code supplies the currency and the banknote denominations. Use these to initialise the first two instance variables. The third instance variable should contains all zeros at this stage because the machine is presently empty.
Getters
```
public String getCurrency()
```
which returns the name of the currency that this machine contains.
```
public int getTotal()
```
which returns the total amount of money in the machine at the moment.
```
public void display()
```
which displays on the standard output (i.e. on the screen, using System.out) how many of each banknote the machine contains, e.g.:
```
euro5 x 1
euro10 x 0
euro20 x 3
euro50 x 2
```
```
public int getQty(int theDenomination)
```
which returns how many notes of the specified denomination the machine contains. For example, if the parameter is 20, we're asking how many 20 euro notes the machine contains; in our running example, the return value is 3.

If the parameter is an illegal denomination, then the return value is zero.
Setters
```
public void load(int theDenomination, int theQty)
```
This method allows someone to load the machine with money. The parameters specify the banknote denomination and the number of banknotes. This method updates the third instance variable. For example if the parameters are 20 and 3, then the contents of the cell of the array that represents 20 euro notes are increased by 3.

You may assume that the second parameter is a positive integer. But, if the first parameter is illegal, then no update should occur.
```
public void dispense(int theDenomination, int theQty)
```
This method allows someone to take money out of the machine. Somewhat unrealistically (but in the interests of making your exercise easier!), they must specify the banknote denomination and how many banknotes of that denomination they wish to withdraw. This updates the third instance variable. For example, if the parameters are 50 and 1, then the contents of the cell of the array that represents 50 euro notes is reduced by 1.

You may assume that the second parameter is a positive integer. But, if the first parameter is illegal, then no update should occur.

(A more realistic version of dispense is the subject of the Challenge Exercise.)

Part 2

If you haven't already done so, you need to test your ATM class definition. I've written some extensive client code to help you do this. Get your copy here: CashFlow.java.

First make sure that you can compile CashFlow.java and ATM.java. (Compiling the former will automatically compile the latter because the latter is client code of the former.) If there are compile-time errors, fix ATM.java. (All such errors are caused by your file; do not change CashFlow.java.)

Then, when there are no more compile-time errors, try to execute CashFlow. If your program is perfect, the following will be displayed on the screen:

a b c d e f g h i j k l m n o p q r s t u v w x y z

atm1.display()
==============
euro5 x 1
euro10 x 1
euro20 x 0
euro50 x 1

atm2.display()
==============
peso500 x 0
peso1000 x 5
peso2000 x 10
peso5000 x 0
peso10000 x 0

Check your output carefully against the above. If there are differences, then you have a bug.

Why does it print the alphabet? CashFlow.java carries out a sequence of tests on your program. After each test it prints a letter of the alphabet. This is so you can see how far through the tests your program gets. If it prints a-z, then it got through all the tests. But if it stops printing before it gets to z, then there is a problem, e.g.:

a b c d e f There's an error in your ATM definition.

a b c Exception in thread "main" java.lang.NullPointerException
        at ATM.getTotal(ATM.java:48)
        at CashFlow.main(CashFlow.java:20)

Look at the last letter it prints. Find the line in CashFlow.java that prints that letter. The problem arose when trying to execute whatever statement comes after that line.

Part 3

Check all your files. Are they in the right directory? Are they correctly named? Does your name appear in an @author comment at the start of each file? Did you lay them out using the template? Are your instance variables private? Are your variable names meaningful? Are curly braces aligned? Etc. etc.

Elegance, conciseness, clarity, consistency of layout, good commenting, and meaningful variable names are all as important in the marking criteria as whether the program works or not.

Challenge Exercise

Sheet A's Challenge Exercise was reasonably demanding, so here's a short and much much easier challenge for Sheet B. Remember, challenge exercises are optional. They never count toward your final mark.

Create a subdirectory of your sheetB directory, calling this new directory challenge. Put a copy of your ATM.java class into this new directory.

The task is to add a second but more realistic version of dispense to ATM.java, as follows:

public int[] dispense(int theAmount)

This method is used to dispense a specified amount of money from this ATM, if possible. It should use the minimum number of notes by making use of as many higher denomination notes as possible before using lower denomination notes.

If it can dispense the requested amount of money exactly, it updates the third instance variable and returns an array: each value in this array is the number of notes of the corresponding denomination that is being dispensed.

If the given amount cannot be exactly dispensed using the notes that are currently in this ATM, the contents of the ATM are not changed, and the array that is returned contains all zeros.

E.g. if the machine contains 2 x 5 euro note, 3 x 10 euro notes, 3 x 20 euro notes and 2 x 50 euro notes, then after executing the following

int[] cashInHand = atm.dispense(75);

the array cashInHand would contain {1, 0, 1, 1}, which shows that to dispense 75 euro with the fewest notes, it used 1 x 5, 0 x 10, 1 x 20 and 1 x 50. (The contents of the machine will be decremented also.)

But after executing the following

int[] anotherWad = atm.dispense(76);

the array anotherWad would contain {0, 0, 0, 0}, which shows that this amount cannot be dispensed with the available notes. (The contents of the machine remain unchanged.)