The first step in designing this interface is determining which order things will happen. We are going to use the same interface for each type of account, so before we collect data we must know what type of account we are creating and the account will determine the information it will gather. This means a pointer to the account will be passed to the main dialog box.
| The first dialog determines the type of account | |
| Gather the information on the Account. Notice the button that allows you to determine the dispersal of interest is disabled since if the checking account has interest it is automatically reinvested. | |
| In the case of a CD, the method of dispersal can be chosen from a special dialog box. | |
Some of the data is collected for every type of account and is collected by direct input. This data frequently is entered into TEdit boxes. Those fields which may not be altered (the account number and the interest dispersal in some types of account) are read only TEdit boxes.
The data that can differ from account to account, yet is limited by various restrictions is listed in ComboBoxes. In our case the types of account and the types of dispersion are restricted by bank policy. At the same time these entries are restricted, they may change from time to type. New types of accounts are created and new methods of interest dispersion may be added. Because the choices are limited, yet changable, we store the choices in static variables in the accounts dll. When the program needs to know the possible choices, it asks the Accounts class to give it a list of choices.
We used a button to allow the user to change the dispersal type, because that button can be disabled in cases when the dispersal type is fixed.
The connection between the Account class, its descendents and the interface is the abstract factory. It allows the interface to be independent of the various types of account classes. It is the standard Create function with it's attendent clone functions. This time the clones receive an integer corresponding to the type of class listed in the types of accounts.
First we must have lists of char* describing the types of accounts and the methods of interest dispersal. These lists are implemented as static variables in the Account class, and have a corresponding set of static functions to give the interface access to the lists. We clearly need a function for each list that returns the list. I chose to return a list of strings, since the strings have self-contained counted memory and are relatively safe. In addition, the account dialog needs to display the type of account and the type of dispersal. Since dispersal information is stored as an integer in the account, we needed to return the string representation that corresponds to the integer value. We also used a function like this to retrieve a string for account type in some initialization situations.
For various types of accounts some of the fields of dialog boxes are enabled and disabled. Different types of accounts allow and disallow various aspects of the general type account. The functions that determine what is and isn't allowed are implemented as virtual functions. In order to make use of these functions, the account dialog must have access to the account it is editing.
This problem makes use of more accessors and modifiers than most. In part this is due to the fact that we must create an appropriate type of account before we initialize its member values. When we create an account, we first determine the type of account and create a pointer of that type. This pointer is passed to the account dialog where the initial values are established. This means we need a modifier to set values instead of using a constructor to set values. The accessors are necessary to initialize fields in the account dialog when we are editing the values of the account.
Finally we have to provide virtual functions for each possible action on a given account. Most accounts will allow withdrawals and deposits, but we may have some types of CDs that do not allow these transactions. This means that each type of transaction must be implemented as a virtual function which can be overridden when normal transactions are not allowed.
Back to Week 9 notes.