Access modifiers and encapsulation

When you first made objects, any line of code could reach into one and change its fields. A program could write account.balance = -999, and the account would accept it. This lesson closes that door. You will lock an object's fields away and give the object a few methods that guard them, so it can refuse a bad value. That arrangement is called encapsulation, and most classes you write from now on will use it.

The open door we left behind#

Here is a small BankAccount. It has a balance, and a constructor that sets the starting amount. Read it, then look at what main does on the line before it prints.

It prints Balance: -999.0. The account now holds an amount that should be impossible: no bank lets a balance of minus 999 appear out of nowhere. Nothing stopped it, because the field balance is open, so any code in the program can reach in with a dot and write whatever it likes. The careful constructor does not help if the very next line can overwrite its work.

Key idea

A field that anyone can write to is a field that anyone can break. An object cannot protect itself while its insides are open to the whole program.

public and private: who is allowed in#

Java lets you put a word in front of a field or a method that controls which code may use it. These words are called access modifiers, because they set who has access. Two of them matter most.

public means “any code, anywhere, may use this”. privatemeans “only code written inside this same class may use this”. From outside the class, a private field might as well not exist.

Fields with no access word#

The fields you have written so far had neither word in front. A field or method with no access modifier gets package access: any class in the same package may use it. A package is a named group of classes, and you will sort your own code into packages in packages and imports. Every class in one of these programs sits in the same package, so in practice any class could use those fields. That is how main was able to write acc.balance.

With the fourth modifier, protected, that makes four levels of access:

A subclass is a class built on top of another one, which is what inheritance is about, and that is where protected earns its place. Until then, one rule serves you well: make fields private, and make the methods that other classes need public.

Locking the field, then opening a window#

Now make balance private. Straight away the line acc.balance = -999.0 stops compiling, because it sits in main, which is in a different class. But reading the balance is blocked too, and reading it is perfectly reasonable. Locking the field shut went further than we wanted. We only meant to control how the balance changes.

The fix is to keep the field private and add small public methods that are the only ways in and out. A method that hands back a field's value is called a getter. A method that changes a field, on the object's own terms, is called a setter. The object sets the rules, and other code goes through these methods or not at all.

Step through it and watch balance in the memory view. The constructor sets it to 100.0. The first deposit(50.0) passes the amount > 0 check, so the balance becomes 150.0. The second call, deposit(-30.0), fails the check: the account leaves its balance alone, prints a refusal and returns. So getBalance() hands back 150.0, and the last line prints Balance: 150.0. The bad amount never reached the field.

And here is what Java says about the old trick, now that the field is private:

Main.java:5: error: balance has private access in BankAccount
        acc.balance = -999.0;   // not allowed: balance is private
           ^
1 error

The compiler refuses before the program ever runs, and the message names the reason: balance has private access in BankAccount.

Getters and setters#

Getters and setters follow naming habits that nearly all Java code shares:

• A getter is named get followed by the field's name with a capital letter. The getter for balance is getBalance().
• For a boolean field the getter usually starts with is instead, so a field called frozen gets isFrozen().
• A setter is named set followed by the field's name. It takes the new value as its only parameter and returns nothing, as in void setTarget(int degrees).

These names are a convention, not a rule of the language, but many tools and libraries look for them, so it pays to stick to them.

A setter is the place where an object can refuse a value. This thermostat accepts targets from 10 to 30 degrees and ignores anything else. Decide what it prints before you run it.

It prints Ignored 45, then Ignored -3, then Target: 21. The first call passes the check and stores 21. The other two fail it, print a message and return before they reach the line that stores the value, so target stays at 21. Open the program and step through it: the narration shows the check coming out false once and true twice.

A setter checks before it stores#

A setter is an ordinary method, so it can think before it writes. Compare the two ways of changing a value. The open field trusts every caller; the guarded method accepts a value only after it passes the check.

Notice where the rule lives: once, inside the class, next to the data it protects. No code can change the target without going through the check, because the setter is the only way in. If you later decide the limit should be 28 degrees, you change one line in setTarget, and every part of the program follows the new rule without any change to the code that calls it.

Key idea

A getter lets other code read a value. A setter lets other code ask to change it. Because the setter is a method, the object decides whether the change is allowed.

Invariants: rules that always hold#

A bank account has a rule that should be true at every moment: the balance is never negative. A rule like that, which must always hold for an object, is called an invariant. Private fields are how a class keeps its invariants. Only code inside BankAccount can change the balance, so that code is the only code you have to check.

Every way into the object has to respect the rule, and that includes the constructor. Try this one.

So the constructor checks as well. Here the account refuses a negative opening balance, and the balance keeps its default of 0.0:

It prints the first refusal, then a: 0.0, then the deposit refusal, then b: 80.0. Account a was never negative, not even for a moment: the constructor refused before storing anything.

Key idea

An invariant is a rule about an object's fields that must always be true. The constructor makes it true at the start, and every method that changes the fields keeps it true.

1public class Main {
2    public static void main(String[] args) {
3        BankAccount acc = new BankAccount(100.0);
4        acc.withdraw(30.0);
5        acc.withdraw(-10.0);
6        acc.withdraw(500.0);
7        System.out.println("Balance: " + acc.getBalance());
8    }
9}
10 
11class BankAccount {
12    private double balance;
13 
14    public BankAccount(double openingBalance) {
15        if (openingBalance >= 0) {
16            balance = openingBalance;
17        } else {
18            System.out.println("Rejected: opening balance cannot be negative.");
19        }
20    }
21 
22    public void withdraw(double amount) {
23        // TODO: if amount is not above 0, print "Rejected: amount must be positive."
24        // TODO: else if amount is more than the balance, print "Rejected: not enough money."
25        // TODO: otherwise, take amount off the balance
26    }
27 
28    public double getBalance() {
29        return balance;
30    }
31}

What encapsulation means#

You now have the whole idea, and it has a name. Encapsulationis keeping an object's data together with the methods that guard it, and hiding the data behind those methods. Hiding the fields themselves is often called data hiding. The word encapsulation comes from capsule: the important part is sealed inside, and other code deals only with the surface the object chooses to show. The balance is inside the capsule; deposit, withdraw and getBalance are the surface.

Two payoffs make this worth the extra typing. The first you have seen: the object can never be put into a state that makes no sense, because every path to its data runs through a method that checks. The second matters more as programs grow. Because other code only ever uses the public methods, you are free to change everything behind those methods later, and no caller notices.

Constructors and encapsulation work as a team. The constructor makes sure an object starts in a valid state, and the private fields and guarding methods make sure it stays valid for the rest of its life.

Further reading#

• Controlling Access to Members of a Class, from the dev.java tutorial, with the same four access levels
• Access control in the Java Language Specification, section 6.6, the exact rules for public, protected, package access and private