Why objects? Class vs object

You can already write programs that work. Variables hold values, if and switch make decisions, loops repeat, and arrays and lists hold many values at once. So here is a fair question to start with: if all of that works, why does Java keep talking about something called an object?

Start with the mess#

Imagine you are writing a small program for a bank. It needs to keep track of one customer's account: their name, their balance and the account number. With the tools you have so far, you would reach for separate variables.

That works. Now the bank gets a second customer, and a third. With separate variables, you are pushed into something like this:

Look at what is happening. The same idea, a customer, is smeared across many loose variables with numbers stuck on the end of their names. Nothing ties name2 and balance2 together except that you, the human, remember they belong to the same person. The computer has no idea. Add a fourth customer and you copy the pattern again. Add a field, say a phone number, and you have to add it three times, once per customer, and never forget one.

Arrays help, up to a point#

You know a better tool than numbered names: arrays. One array holds the names and another holds the balances, and each customer sits at the same index in both.

This is an improvement. One loop now handles any number of customers, and a deposit for Ben is a single line. But the link between a name and its balance is still only a shared index that you keep in your head. Arrays that line up like this are called parallel arrays, and they break as soon as one of them changes without the other.

It prints Aisha has 900.0, Ben has 300.0 and Carmen has 500.0. The balances moved and the names stayed put, so Aisha now owns Carmen's money. Java had no way to know that names[0] and balances[0] belonged together. Sorting the customers, removing one, or adding an array of phone numbers would all need the same care in every array, every time.

Key idea

Data that belongs together is not held together. Nothing in the program is “a customer”: a customer exists only in your head, as a name and a balance that happen to share an index.

The idea: bundle the data with the things you do to it#

Here is the move that object-oriented programming makes. Instead of loose variables, you describe one kind of thing once: what fields it has and what it can do. A customer has a name and a balance. A customer can deposit money. The state (the data) and the behavior (the actions) are bundled into a single unit.

That description, the shape of “a customer”, is called a class. It is a blueprint. It is not a customer itself, the same way an architect's drawing of a house is not a house you can live in. From one blueprint you can build as many real customers as you want, and each real one is called an object.

The cookie cutter

A cookie cutter is a class. It describes the shape. It is made once. You cannot eat it. Each cookie you press out with it is an object: a real, separate thing, all sharing the same shape but each with its own existence. Eat one and the others are untouched. Change the dough on one and the others do not change.

An object built from a class is also called an instanceof that class. Aisha's account and Ben's account are two instances of Customer, the way two cookies are two pressings of one cutter. Building one is called instantiatingthe class. The two words just mean “an object made from this class” and “making one”, and you will meet them in error messages and documentation.

Your first class and object, running#

Here is the smallest complete program that defines a class and makes objects from it. Read it once, then press Run and step through it. Watch the memory view under the code when new runs: a new Customer object appears there, with its fields at their starting values.

Two things are worth saying out loud. First, Customer is written once at the bottom: the blueprint. Second, new Customer() appears twice in main, and each one makes a separate object, so the memory view ends up with two Customer objects. Setting a.name does not touch b.name. They are different cookies from the same cutter. The . (dot) reaches into one specific object to read or set one of its fields.

Two variables, one object#

The variable a does not hold the customer object itself. It holds a referenceto it, which you can think of as the object's home address; the object lives elsewhere in memory. So two variables can hold the same address and point at the same object. Step through this program and watch the memory view:

new runs once, so the memory view only ever holds one Customer object. The line Customer sameOne = a; makes a second variable that points at that same object. The balance set through sameOne is the balance a reads, which is why the program prints Aisha: 750.0. Two names, one customer. This matters a lot later, and it gets a careful look in creating classes and objects and again in the this keyword and object references.

State and behavior: the two halves of every object#

So far Customer only has state, the fields. The other half of the idea is behavior, the actions an object can do with its own data. Depositing money is a thing a customer does, so it belongs inside the class, next to the data it works on.

deposit is a method: a named action that belongs to the class. Notice that it just says balance, not a.balance. Inside the class, the object is already talking about itself, so balance means “my own balance”. When you call a.deposit(200.0), the action runs on a's balance, so this prints Aisha has 750.0. If you had a second customer and called b.deposit(...), the very same method would run on b's balance instead. One description of the behavior, reused by every object.

Key idea

An object is state and behavior kept together: the data, and the actions that belong with that data, in one unit.

You have used objects like this already. In ArrayList, scores.add(7) asked one list to change its own contents, and scores.size() asked it how many values it held. The list kept its values (state) and knew how to work with them (behavior). Someone wrote the ArrayList class once, and every list you make is an instance of it. Now you write classes of your own.

1public class Main {
2 
3    public static void main(String[] args) {
4        Customer a = new Customer();
5        a.name = "Aisha";
6        a.balance = 500.0;
7 
8        // TODO: make a second customer, Ben, with a balance of 300.0,
9        // and deposit 50.0 into Ben's account only.
10 
11        System.out.println(a.name + " has " + a.balance);
12        // TODO: print Ben's line the same way.
13    }
14}
15 
16class Customer {
17    String name;
18    double balance;
19 
20    void deposit(double amount) {
21        balance = balance + amount;
22    }
23}

Further reading#

• What is an object? What is a class? The dev.java introduction to objects, classes and the ideas behind them
• Classes and Objects, the dev.java tutorial series that goes on to fields, methods and constructors