CS 2102 - Bterm 09

Homework 5 - Mutating Object State

Due: Tuesday, November 24 at 5pm

©2009 Felleisen, Proulx, et. al. (Modified by Glynis Hamel)

Assignment Goals

Assignment

A bank keeps a list of different kinds of bank accounts: checking accounts, savings accounts, and line of credit accounts. Customers make deposits into and withdrawals from these accounts. Checking accounts require that the customer keeps a minimum balance below which withdrawals may not be made. For line of credit accounts, the balance represents the amount of money owed. Credit accounts must also record the maximum amount that the customer can borrow. Customers can withdraw money from line of credit accounts, as long as the amount being withdrawn does not increase the balance owed above the maximum amount. When a customer deposits money to a credit line account, it decreases the amount owed by the deposited amount. Customers are not allowed to overpay the amount owed in the credit line accounts.

Problems

  1. Download the zip file containing the preliminary java source files for Homework 5. Create a Java Project and add the files to its source directory:

    In the Examples.java file, make several examples of data for Credit accounts.

  2. Design the method deposit for the abstract class Account:
    // EFFECT: Add the given amount to this account
    // Returns the new balance
    public int deposit(int amount)
    
    You need to determine if the method should be defined as an abstract method, if it should be implemented in the abstract class, if it should be overridden in the subclasses, etc. If a transaction cannot be completed, the method should throw a RuntimeException such as:
    
    throw new RuntimeException("Balance too low: " + this.balance);
    
    Make the message meaningful. You may add to the message information about the account that caused the problem - the customer name, or the current balance available, or how much more there would need to be in the account for the transaction to go through.

    Testing Exceptions

    We need to be able to test that methods throw exceptions we expect them to throw. Suppose bobAcct is a Checking account, and the method invocation:
       this.bobAcct.withdraw(1000) 
    
    results in a RuntimeException with the message:
       "1000 is not available". 
    
    The test would then be:
    
    t.checkException(
      "Testing withdrawal from checking",  
      new RuntimeException("1000 is not available"), 
      this.bobAcct,
      "withdraw",
      1000);
    
    The first argument is a String that describes what we are testing — it is optional and can be omitted. The second argument defines the Exception our method invocation should throw. The third argument is the instance that invokes the method, the fourth argument is the method name, and after that we list as many arguments as the method consumes — all separated by commas. It could be no arguments, or five arguments — it does not matter. For our method that performs the withdrawal, it will just be the amount we are trying to withdraw.

    Every time you define a method that throws an exception, provide a test for that exception in the testExceptions() method of the Examples class.

    Testing Methods that have Side Effects

    For transactions that do go through without throwing an exception, you should develop a set of test cases. Because the method deposit() produces a value as well as has an effect on the state of the object that invoked the method, you must test both parts.

    The Examples.java file provides instances of data that can be used in our tests for checking accounts. It also defines a method reset() that initializes the values for the data we expect to work with and which may change during the tests. We can then design the tests as follows (assuming that this.check1 is the instance that invokes the method that is being tested):

    
    //Tests the deposit method inside certain accounts.
    void testDeposit(Tester t){
      reset();
    
      t.checkExpect(check1.deposit(100), 100);
      t.checkExpect(check1, 
        new Checking(1, 100, "First Checking Account", 0));
    
      // you need to add additional tests here...
    
      reset();
    }
    
    Notice that we use the reset() method twice. At the start, we make sure that the data we use has the correct values before the method is invoked, and after the test we reset the data back to its original values, so that the tests that were run don't affect any other part of the program. Notice the tests themselves - there are two kinds. The first one is just like what we have done in the past - we compare the value produced by the method invocation with the expected value. The second test verifies that the state of the object we were modifying did indeed change as expected. Convince yourself that both kinds of tests are needed. (Look at the following incorrect implementations in the Checking class of this method to see why both kinds of tests are necessary):
    
    //EFFECT: Add the given amount to this account
    //Return the new balance
    public int deposit(int amount){
      return this.balance + amount;
    }
    
    
    //EFFECT: Add the given amount to this account
    //Return the new balance
    public int deposit(int amount){
      this.balance = balance + amount;
      return amount;
    }
    
    
    Of course, you should test deposits into all three kinds of accounts.

  3. Design the method withdraw() for the abstract class Account:
    // EFFECT: Withdraw the given funds from this account
    // Return the new balance
    public int withdraw(int funds)
    
    Provide a set of test cases.

  4. The class Bank keeps track of all accounts. Design the method openAcct() for the class Bank that allows a customer to open a new account in the bank.
    // EFFECT: adds a new account to the list of accounts kept by this bank
    public void openAcct(Account acct)
    
    Make sure you design your tests carefully.

  5. Design the method deposit() for class Bank that deposits the given amount to the account with the given name and account number. deposit() is a void method. Make sure you report any problems, such as no such account, or that the transaction cannot be completed. Make sure you design your tests carefully.

  6. Design the method withdraw() for class Bank that withdraws the given amount from the account with the given name and account number. withdraw() is a void method. Make sure you report any problems, such as no such account, or that the transaction cannot be completed. Make sure you design your tests carefully.

  7. Design the method removeAccount() for the class Bank that will remove the account with the given account id and the given name from the list of accounts in a bank.
    public void removeAccount(int acctNo, String name)
    
    Make sure you design your tests carefully.

    What to Turn In

    Create an archive of your Eclipse project (see "Saving your work" in Lab 4 if you forgot how to do this). Using web-based turnin, turn in a single zip file containing all code and documentation for this assignment. Follow the naming conventions when naming your file.