Example: accounts
Consider the example of a bank in which customers can open accounts and make deposits to and withdrawals from their accounts. You could represent an account by a general-purpose class, called Account. Because there are many customers, multiple instances of the Account class could exist simultaneously.
After you determine the classes that you need, the next step is to determine the methods that the classes need to do their work. An Account class must provide the following services:
- Open the account.
- Get the current balance.
- Deposit to the account.
- Withdraw from the account.
- Report account status.
The following methods for an Account class meet those needs:
- init
- Open an account and assign it an account number.
- getBalance
- Return the current balance of the account.
- credit
- Deposit a given sum to the account.
- debit
- Withdraw a given sum from the account.
- Display account number and account balance.
As you design an Account class and its methods, you discover the need for the class to keep some instance data. Typically, an Account object needs the following instance data:
- Account number
- Account balance
- Customer information: name, address, home phone, work phone, social security number, and so forth
To keep the example simple, however, it is assumed that the account number and account balance are the only instance data that the Account class needs.
Diagrams are helpful when you design classes and methods. The following diagram depicts a first attempt at a design of the Account class:
The words in parentheses in the diagrams are the names of the instance data, and the words that follow a number and colon are the names of the instance methods.
The structure below shows how the classes relate to each other, and is known as the inheritance hierarchy. The Account class inherits directly from the class java.lang.Object.
Subclasses
In the account example, Account is a general-purpose class. However, a bank could have many different types of accounts: checking accounts, savings accounts, mortgage loans, and so forth, all of which have all the general characteristics of accounts but could have additional characteristics not shared by all types of accounts.
For example, a CheckingAccount class could have, in addition to the account number and account balance that all accounts have, a check fee that applies to each check written on the account. A CheckingAccount class also needs a method to process checks (that is, to read the amount, debit the payer, credit the payee, and so forth). So it makes sense to define CheckingAccount as a subclass of Account, and to define in the subclass the additional instance data and instance methods that the subclass needs.
As you design the CheckingAccount class, you discover the need for a class that models checks. An instance of class Check needs, at a minimum, instance data for payer, payee, and the check amount.
Many additional classes (and database and transaction-processing logic) would need to be designed in a real-world OO account system, but have been omitted to keep the example simple. The updated inheritance diagram is shown below.
A number and colon with no method-name following them indicate that the method with that number is inherited from the superclass.
Multiple inheritance: You cannot use multiple inheritance in OO COBOL applications. All classes that you define must have exactly one parent, and java.lang.Object must be at the root of every inheritance hierarchy. The class structure of any object-oriented system defined in an OO COBOL application is thus a tree.