Tino APCS

Determining Object Behavior

In this section, you will learn how to create a simple class that describes the behavior of a bank account. Before you start programming, you need to understand how the objects of your class behave. Operations that can be carried out with a checking account could be:

  • Accepting a deposit
  • Withdrawing from the account
  • Getting the current balance

In Java, these operations are expressed as method calls. For example, assume we have an object checking of type CheckingAccount. Here are the methods that invoke the required behaviors:

checking.deposit(1000); 
checking.withdraw(250); 
System.out.println("Balance: " + checking.getBalance());


These methods form the behaviors of the CheckingAccount class. The behaviors are the list of methods that you can apply to objects of a given class. To the client, an object of type CheckingAccount can be viewed as a “black box” that can carry out its methods. The programming concept of not needing to know how things are done internally is called abstraction.

Once we understand what objects of the CheckingAccount class need to do, it is possible to design a Java class that implements these behaviors. To describe object behavior, you first need to implement a class and then implement methods within that class.

Next, we implement the three methods that have already been identified:

  • deposit
  • withdraw
  • getBalance

What we have been doing here is not real code and wouldn’t actually do anything. However, it is useful to lay out what your class will look like.

  • When we use a mixture of English and Java to show what we are doing, it is called pseudocode. In this example the implementation of the methods is left out because we do not have all the information that we need yet. However, we can still write out what the methods will do with pseudocode so that it becomes easier to see how everything will fit together.
  • This process of starting with a very broad concept or outline and working down to smaller and smaller details is called top-down design.

A method header consists of the following parts:

access_specifier return_type _method_name_ ( _parameters_ )

  1. An access_specifier (such as public). The access specifier controls where this method can be accessed from. Methods should be declared as public if the method needs to be accessed by something other than the object containing the method. If it should only be accessed within the object, you should declare the method as private.

  2. The return_type of the method such as double, void, or DrawingTool. The return type is the data type that the method sends back to the call of the method. This can be any primitive type or any object that your class knows about. For example, in the CheckingAccount class, the getBalance method returns the current account balance, which is a floating-point number, so its return type is double. The deposit and withdraw methods don’t return any value. To indicate that a method does not return a value, you use the keyword void.

  3. The method_name (such as deposit). The name needs to follow the rules of identifiers and should indicate the method’s purpose.

  4. A list of the parameters of the method. The parameters are the input to the method. The deposit and withdraw methods each have one parameter, the amount of money to deposit or withdraw. The type of parameter, such as double, and name for each parameter, such as amount, must be specified. If a method has no parameters, like getBalance, it is still necessary to supply a pair of parentheses () behind the method name.

Once the method header has been specified, the implementation of the method must be supplied in a block that is delimited by braces {...}. The CheckingAccount methods will be implemented later in Section D.

Dark Mode

Outline