The problem objects solve, and the difference between a blueprint and the thing built from it.
Finished reading?
Mark this session so you can track where you are.
You have written programs that work. Variables hold values, loops repeat, methods do a job and hand something back. So here is a fair question to start with: if all of that already works, why does Java keep insisting on something called an object?
class apart from an object without reaching for jargon.Imagine we are writing a small program for a bank. We need to keep track of one customer's account: their name, their balance, and the account number. With only the tools you have so far, you would reach for separate variables.
public class Main { public static void main(String[] args) { String name = "Aisha"; int accountNumber = 1001; double balance = 500.0; balance = balance + 200.0; System.out.println(name + " now has " + balance); }}Aisha now has 700.0
That is fine. It runs. Now the bank gets a second customer. And a third. With separate variables, you are forced into something like this:
public class Main { public static void main(String[] args) { String name1 = "Aisha"; double balance1 = 500.0; String name2 = "Ben"; double balance2 = 300.0; String name3 = "Carmen"; double balance3 = 900.0; balance2 = balance2 + 200.0; System.out.println(name2 + " now has " + balance2); }}Ben now has 500.0
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.
The trouble is not that the code is long. It is that the data that belongs together is not held together. There is no single thing in the program called “a customer”.
{"name": "Ben", "balance": 300}to keep a customer's fields in one place. That instinct is exactly right. An object is that instinct made into a first-class part of the language, with a fixed shape and its own behavior attached.Here is the move that object-oriented programming makes. Instead of loose variables, we 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. We bundle the state (the data) and the behavior (the actions) 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 that one blueprint you can build as many real customers as you want, and each real one is called an object.
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.
Cookie on the cutter.Enough words. Here is the smallest complete program that defines a class and makes objects from it. Read it once, then press Run and step through. Watch the moment new runs: that is a real object being born.
public class Main { public static void main(String[] args) { Customer a = new Customer(); a.name = "Aisha"; a.balance = 500.0; Customer b = new Customer(); b.name = "Ben"; b.balance = 300.0; System.out.println(a.name + ": " + a.balance); System.out.println(b.name + ": " + b.balance); }} class Customer { String name; double balance;}Aisha: 500.0 Ben: 300.0
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. 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.
a.balance reads as “the balance belonging to a”. Whenever you see a dot between a variable and a field, picture reaching into that one object and pointing at one field inside it. You will use this constantly.Right now our Customer only has state, the fields. The other half of the idea is behavior, the actions an object can do to its own data. Depositing money is a thing a customer does, so it belongs inside the class, next to the data it works on.
public class Main { public static void main(String[] args) { Customer a = new Customer(); a.name = "Aisha"; a.balance = 500.0; a.deposit(200.0); a.deposit(50.0); System.out.println(a.name + " has " + a.balance); }} class Customer { String name; double balance; void deposit(double amount) { balance = amount + balance; }}Aisha has 750.0
Notice that deposit just says balance, not a.balance. Inside the class, the object is already talking about itself, so it means “my own balance”. When you calla.deposit(200.0), the action runs on a's balance. 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.
An object is state and behavior, kept together. The data, and the actions that belong with that data, living in one unit.
a.balance = -999 from outside and break the account. Protecting an object from being put into a nonsense state is the point of encapsulation, and building it correctly from the first moment is the point of constructors. You do not need either yet. Just notice the gap; we close it soon.Try each one yourself first, then open the answer.
class is and what an object is, using the cookie cutter only if it helps.a and b. After both are set up, the line a.name = "Zara"; runs. What does b.name print now, and why?Dog class. You are designing the blueprint, not any one dog.Take these away. They continue exactly what we just did.
Book class. Write down its fields (state) and at least one action (behavior). Do not write Java yet, just the blueprint in plain words. Bring it next session.deposit) yourself in the playground. Then add a second customer b, deposit different amounts into each, and print both. Confirm that depositing into a never changes b.name and balance together inside one object better than three loose balance1, balance2, balance3 variables? Think about what happens when the bank adds a thousand customers.