Instance Fields & Methods

Recall that objects in Java have both characteristics and behaviors. Within the Java language we can represent characterstics through the use of fields, or variables, and behaviors through the use of methods.

For the following chapter, I take for granted your familiarity with functions in the computer science sense of the term. If you are unfamiliar with functions then I suggest you check out this chapter written for a C class which goes over the basics.

An instance refers to the in-memory representation of an object. Take the following class definition:

 1:   public class BankAccount {
 2:     String owner;
 3:     double balance;
 4: 
 5:     BankAccount(String owner, double initialBalance){
 6:         this.owner   = owner;
 7:         this.balance = initialBalance;
 8:     }
 9: 
10:     void deposit(double amount){
11:         balance = balance + amount;
12:     }
13: 
14:     void withdraw(double amount){
15:         balance = balance - amount;
16:     }
17: 
18:     void printBalance(){
19:         System.out.printf("%s's balance: $%.2f%n", owner, balance);
20:     }
21: 
22: }

The this keyword makes explicit the reference to the instance which is being used for the method invocation.

The BankAccount class has two instance fields (owner and balance) and three instance methods (deposit, withdraw, and printBalance). We can create two instances of the class with the following:

1: BankAccount alice = new BankAccount("Alice", 1000.00);
2: BankAccount bob   = new BankAccount("Bob",   500.00);

The variables alice and bob store two distinct instances of the BankAccount class in the form of in-memory objects. We can represent these objects pictorially like so:

                   BankAccount
         (class definition / blueprint)
┌─────────────────────────────────────────────────┐
│  fields:                                        │
│    String owner                                 │
│    double balance                               │
│                                                 │
│  methods:                                       │
│    deposit(double amount)      ◄────────────┐   │
│    withdraw(double amount)     ◄──────────┐ │   │
│    printBalance()              ◄────────┐ │ │   │
└─────────────────────────────────────────┼─┼─┼───┘
               /              \           │ │ │
         new BankAccount()   new BankAccount()│
             /                  \         │ │ │
┌─────────────────────┐   ┌─────────────────────┐
│  BankAccount object │   │  BankAccount object │
│  ─────────────────  │   │  ─────────────────  │
│  owner:   "Alice"   │   │  owner:   "Bob"     │
│  balance: 1000.00   │   │  balance: 500.00    │
│                     │   │                     │
│  deposit()    ──────┼───┼─────────────────────┼─┘
│  withdraw()   ──────┼───┼─────────────────────┼─┘
│  printBalance()─────┼───┼─────────────────────┼─┘
└─────────────────────┘   └─────────────────────┘
        alice                       bob

We can see that there are two BankAccount objects with their own, distinct internal fields. We can also see, however, that the methods defined in the class are all shared by the instances. This is because alice and bob are both instances of the BankAccount class and as such they have the same characteristics (i.e. fields) and the same behaviors (i.e. methods). Characteristics may change from object to object, but behaviors do not (a bank account may have such and such amount, but it should always be able to take in new deposits).

OOP came from a desire to attribute greater functionality to programmer-defined types. One such aspect is the ability to encapsulate data by restricting its visibility to prevent, wittingly or unwittingly, malicious actors from ruining a class's assumptions. This is achieved in Java through the use of access modifiers.

1. In your own words, explain the difference between a class and an instance. Using the BankAccount example from the chapter, identify which parts of the code represent the class definition and which parts represent instances.
2. Compile and run Listing 10. Then add a call to acc_2.deposit(250) after the existing deposit and print both balances again. Does the deposit to acc_2 affect acc_1? Explain why or why not in terms of instances.
3. Add a withdraw call to Listing 10 that withdraws $2000 from acc_1. What is the resulting balance? Does the BankAccount class prevent this? What would need to change in the class definition to prevent a negative balance from occurring through a withdrawal?
4. Listing 17 prevents instantiation with a negative balance but Listing 15 shows the invariant can still be broken. Explain in your own words why making balance private solves this problem. What does private prevent that the constructor check alone cannot?
5. The chapter states that when no constructor is defined, the Java compiler creates a default one. Remove the constructor from BankAccount and attempt to instantiate it with new BankAccount("Alice", 1000.00). What error do you get? Then instantiate it with new BankAccount() and print acc.owner. What value is printed and why?
6. The chapter states that methods are invoked with context. In your own words explain what this means. When acc_1.printBalance() is called, how does printBalance know to print Alice and 1000.00 rather than Bob and 500.00?
7. The access modifier table shows four levels of privilege. Rank them from most to least restrictive and give a real-world analogy for each — for example, private is like a personal diary that only you can read.
8. Add a transfer method to BankAccount that takes another BankAccount object and a double amount as arguments and transfers that amount from the current account to the other. Test it by transferring $200 from acc_1 to acc_2 and printing both balances before and after.
9. The chapter introduces the . notation for accessing instance fields and methods. Write a program that creates a BankAccount, accesses its owner field directly, calls printBalance, and then attempts to access a field that does not exist (e.g. acc.phone). Record the compiler error and explain what it tells you.
10. Make both owner and balance private in BankAccount. Now BankUser can no longer access acc.owner directly. Write a method getOwner in BankAccount that returns the value of owner and update BankUser to use it instead. This pattern is called a getter — why might this be preferable to leaving owner as a default field?
11. The chapter states "a bank account may have such and such amount, but it should always be able to take in new deposits." Give two more real-world examples of objects where characteristics vary between instances but behaviors remain the same. For each, identify at least two fields and two methods.
12. Create a second class called SavingsAccount that has an additional field interestRate of type double. Add a method applyInterest that multiplies balance by (1 + interestRate). Instantiate one SavingsAccount and one BankAccount and demonstrate that applyInterest cannot be called on a BankAccount object.
13. The chapter notes that constructors are "always named after the class and never have a return type." Try adding a return type of void to the BankAccount constructor and recompile. What happens? Then try naming the constructor bankAccount (lowercase b) instead. What happens?

14. Consider the following code snippet:

    BankAccount a = new BankAccount("Alice", 500.00);
    BankAccount b = a;
    b.deposit(200.00);
    a.printBalance();
    

    Before running it, predict what a.printBalance() will print. Then run it and verify. Does the result surprise you? What does this tell you about how object variables work in Java? We will explore this further in the chapter on references.

15. The BankAccount constructor uses the this keyword on Lines 6 and 7 of Listing 1:

    this.owner   = owner;
    this.balance = initialBalance;
    

    Remove the this keyword from Line 6 so it reads owner = owner and recompile. Does it compile? Run it and call printBalance. What value is printed for the owner and why? Now restore this.owner = owner and explain in your own words what this refers to and why it is necessary when a parameter name matches a field name.