Section J.8. Class BankDatabase

J.8. Class BankDatabase

Class BankDatabase (Fig. J.7) models the bank's database with which the ATM interacts to access and modify a user's account information. We determine one reference-type attribute for class BankDatabase based on its composition relationship with class Account. Recall from Fig. 11.19 that a BankDatabase is composed of zero or more objects of class Account. Line 4 implements attribute accountsan array that will store Account objectsto implement this composition relationship. Class BankDatabase has a parameterless constructor (lines 713) that initializes accounts with new Account objects. We create two new Account objects with test data and place them in the array (lines 1112). Note that the Account constructor has four parametersthe account number, the PIN assigned to the account, the initial available balance and the initial total balance.

Recall that class BankDatabase serves as an intermediary between class ATM and the actual Account objects that contain users' account information. Thus, methods of class BankDatabase invoke the corresponding methods and properties of the Account object belonging to the current ATM user.

Private Utility Method GetAccount

We include Private utility method GetAccount (lines 1625) to allow the BankDatabase to obtain a reference to a particular Account within the accounts ArrayList. To locate the user's Account, the BankDatabase compares the value returned by property AccountNumber for each element of accounts to a specified account number until it finds a match. Lines 1822 traverse the accounts ArrayList. If currentAccount's account number equals the value of parameter accountNumber, the method returns currentAccount. If no account has the given account number, then line 24 returns Nothing.

Public Methods

Method AuthenticateUser (lines 2940) proves or disproves the identity of an ATM user. This method takes a user-specified account number and a user-specified PIN as arguments and indicates whether they match the account number and PIN of an Account in the database. Line 32 calls method GetAccount, which returns either an Account with userAccountNumber as its account number or Nothing to indicate that userAccountNumber is invalid. If GetAccount returns an Account object, line 36 returns the Boolean value returned by that object's ValidatePIN method. Note that BankDatabase's AuthenticateUser method does not perform the PIN comparison itselfrather, it forwards userPIN to the Account object's ValidatePIN method to do so. The value returned by Account method ValidatePIN (line 36) indicates whether the user-specified PIN matches the PIN of the user's Account, so method AuthenticateUser simply returns this value (line 36) to the client of the class (i.e., ATM).

BankDatabase trusts the ATM to invoke method AuthenticateUser and receive a return value of true before allowing the user to perform transactions. BankDatabase also trusts that each transaction object created by the ATM contains the valid account number of the current authenticated user and that this is the account number passed to the remaining BankDatabase methods as argument userAccountNumber. Methods GetAvailableBalance (lines 4347), GetTotalBalance (lines 5054), Credit (lines 5761) and Debit (lines 6468) therefore simply retrieve the user's Account object with utility method GetAccount, then invoke the appropriate Account method on that object. We know that the calls to GetAccount within these methods will never return Nothing, because userAccountNumber must refer to an existing Account. Note that GetAvailableBalance and GetTotalBalance return the values returned by the corresponding Account properties. Also note that methods Credit and Debit simply redirect parameter amount to the Account methods they invoke.