| CIS 210 Home Page | Last updated 2007/09/29 19:08:54 |
Problem 4.3 is intended to introduce you to the idea of mutable aggregate objects. A mutable object is one whose data can be changed. An aggregate object is one that is made up of other objects. We have seen classes defined with instance data fields that are primitive types like integer. Such a class is an aggregation of the data fields. In this problem we'll see that the data fields do not have to be primitive types, but can be objects themselves with constructors and methods. The concept of aggregation is fundamental to Object Oriented Design and we can think of it as the "has-a" relationship. This problem defines some classes to represent the concepts that might be used in a simplified banking application. There are three classes (concepts): Customers, Addresses, and Accounts. Each class is defined in its own file.
The Customer class describes the concept of a banking customer (actually you can think of it as the customer record kept by the bank). Some things we note about each customer are that each customer has a name, an identification number (e.g., a Social Security number for tax reporting), an address, a checking account, and a savings account. This is an example of aggregation, or the has-a relationship. Thinking in object terms, a Customer object is an aggregation of other objects corresponding to the data that is relevant to the customer record concept. These other objects will be instance variables in the Customer class, and may be primitive data - like the ID number - or object types - like the name (String), address (Address), checking account (Account) and savings account (Account).
Most of the code for Customer has been provided. The only thing you need to do is to fill in the missing code in the constructor (indicated by ???). Remember that the constructor for a class specifies the actions that are done to initialize an object of the class, i.e., what must be done to create an instance object. As you might expect, the constructor is often passed information used in this initialization, and for our Customer example, we need a name, ID, and the address information.
An Address object is a simple object that contains address information, namely a street address, city, state, and zip code. The constructor for an Address object requires all of these values and initializes the corresponding instance data. The Address class provides "getter" methods to access the data of Address objects, and even a method to properly format the address data as a single String. The Address class as provided is complete, so you won't need to change anything, but you will need the code for compiling the other classes.
An Account object represents a bank account. For our simplified application, an account has a balance and an indicator of whether the account will earn interest. In addition to "getter" methods, the Account object provides methods for performing a withdrawal from or deposit to the account. You are provided with most of the code for Account and only need to furnish the withdraw and deposit methods.
Finally, there is one other class, BankTester, that consists of a main method which will create a Customer object and do some things with it. Again, most of this code is provided, but there are some pieces you must complete.
Your output should look like this:
Account Information: Name: John Smith ID: 950123456 Address: 123 Main St Eugene,OR 97403 Checking earns interest? false Savings earns interest? true Checking: $0.00 Savings: $0.00 After deposits, balances are now: Checking: $500.00 Savings: $1,000.00 After withdrawal, balances are now: Checking: $404.83 Savings: $1,000.00 Customer resides in Eugene
It should be clear that each of the three bank classes (but not the tester) is an aggregate class that collects together primitive or object data. But what is mutable, i.e., what can be changed? Well, the Address class is not mutable since none of the instance data is ever changed after it is set by the constructor. (In fact, we could, and probably should, define the instance data as final.) However, the balance instance variable in Account is certainly going to be changed by your implementation of withdraw and deposit. And while no data in Customer is directly changed, the fact that a Customer has two account objects which are mutable would suggest that we regard Customer objects as mutable objects.