Getters وsetters و«أخبِر ولا تسأل» (tell, don't ask)

Written Explanation

Getters and setters

A getter returns the value of a private field. A setter assigns a new value to it:

class Account {
    private double balance;

    Account(double balance) { this.balance = balance; }

    double getBalance() { return balance; }
    void setBalance(double balance) { this.balance = balance; }
}

The names follow a convention: getX and setX for a field x (for a boolean, isX is common). Many tools and frameworks rely on this convention, which is why you will see it everywhere in Java code. But conventions are not a rule that every field needs a pair.

A setter is a public field in disguise

What does setBalance allow?

Account a = new Account(100);
a.setBalance(-500);
System.out.println(a.getBalance());

-500.0

The field is private, yet anyone can set it to any number. Compare this with lesson 1: a.balance = -500; was the original problem. A setter that does no checking offers the same hole with extra typing. You protected the constructor, deposit, and withdraw, and a generated setter walks around all of them.

You could add checks to the setter, which is better. But then ask: what is the setter for? A bank balance does not "get set". It changes because a deposit or a withdrawal happened. setBalance(70) loses that meaning: nobody can tell from the code whether 70 came from a withdrawal, a correction, or a mistake. And there may be rules for deposits (positive amount) that differ from rules for withdrawals (sufficient funds).

Prefer behavior methods

A behavior method is a method named for something that happens in the problem domain: deposit, withdraw, transferTo, closeAccount. It changes the object's state as a consequence, applying the rules that belong to that event.

Behavior methods give you a small public window with a meaning, and each one can enforce exactly the rules for its event.

"Tell, don't ask"

The habit behind this is "tell, don't ask". Compare:

// Ask: pull the data out, decide outside, push a new value back
if (a.getBalance() >= 50) {
    a.setBalance(a.getBalance() - 50);
}

// Tell: say what you want; the object decides
a.withdraw(50);

In the "ask" version, the rule "balance must cover the amount" lives in the caller, which is the situation lesson 1 warned about: every caller must repeat it, and one will get it wrong. In the "tell" version the rule lives in withdraw, once.

A useful sign: if you see a call chain like x.getY() followed by a decision followed by x.setY(...), the decision probably belongs inside x.

When a getter is fine

"Tell, don't ask" does not ban reading data. Reading is often necessary: to print a statement, to show a balance on a screen, to log. A getter is appropriate when a caller really needs the value for something the object should not do itself.

Ask for each field:

• Does any caller need to read it? If not, no getter.
• Does any caller need to replace it directly, bypassing the object's rules? Almost never. If the answer is "no rule applies", it may be a plain data object, but still consider a behavior method with a clear name.
• Can the answer be a question the object answers itself, such as canWithdraw(50) or isEmpty(), instead of exposing the number?

A field that never changes after construction, like an account number or owner, needs a getter at most. Declare it final (see next lessons) so the compiler guarantees it never changes.

Naming note: this course sometimes writes the getter as balance() instead of getBalance(). Both work; the get prefix is the traditional JavaBeans style. Be consistent within a project, and follow the style your team or framework uses.

The accessor trap: do not return what you should protect

A getter hands out whatever the field refers to. For int, double, and String that is harmless, because the value cannot be modified through the copy you get. For a field that refers to a mutable object, such as an array, the getter hands out the live object. The immutable-objects lesson deals with this; keep it in mind.

Generated code is still code you own

IDEs offer a command to generate getters and setters for every field. Using it is not wrong, but doing it by reflex for every field creates a class where each field is readable and writable by anyone: effectively public fields. Generate only what you need, and delete the rest. The exact menu names depend on your IDE, so search its documentation for "generate getters and setters" if you want to use the feature.