Tell, Don't Ask

The smell: asking for data, then deciding for the object

Here is the trap. A caller wants to withdraw money. It asks the account for its balance, checks the rule itself, then sets a new balance:

// ⚠️ ASK — the caller pulls the balance out, decides, then pushes a result back.
if (account.getBalance() >= amount) {
  account.setBalance(account.getBalance() - amount);
}

Notice who is doing the thinking. The caller knows the overdraft rule (balance >= amount). The account is just a dumb data bag with a getter and a setter — it holds a number but enforces nothing. The real rule about what a valid balance is now lives outside the thing it's about.

Why that hurts: the rule gets copied, then drifts

The moment a second caller also needs to withdraw — an ATM and an online checkout, say — that same if check gets copied into both. Now the overdraft rule lives in two places, and nothing keeps them in sync:

• Duplication — the same balance >= amount rule is written in every caller that withdraws. Add a third caller and it's written a third time.
• Drift — when the rule changes (say, allow a $100 overdraft buffer), you must find and edit every copy. Miss one and the callers now disagree about what's legal.
• Broken encapsulation — the account exposes getBalance and setBalance, so any caller can set the balance to anything, bypassing the rule entirely. The object can't protect its own invariant.
• Inconsistency — if one caller simply forgets the check, it can drive the balance negative while another caller refuses. The same account behaves differently depending on who's asking.

The fix: tell the object, and put the rule inside it

Don't ask for the balance — tell the account to withdraw. Move the decision into the account, where the data already lives:

// ✓ TELL — one method on the account; the rule lives WITH the data.
account.withdraw(amount);

class BankAccount {
  private balance: number;
  withdraw(amount: number) {
    if (amount > this.balance) throw new Error("Insufficient funds");
    this.balance -= amount;   // the rule and the data are in one place
  }
}

Now there is exactly one copy of the overdraft rule, and it lives inside the account — right next to the balance it protects. Every caller, ATM or checkout, calls the same account.withdraw(amount). The rule can't drift, because there's only one of it. And the account no longer needs a public setBalance, so no caller can bypass the check. The object guards its own invariant.

Where the decision lives — the whole idea in one picture

The difference is purely about location. In Ask, the decision (the if) sits outside the object, in the caller. In Tell, the very same decision sits inside the object, as a method. Same check, same data — just moved to where it belongs.

How this connects to encapsulation and Law of Demeter

• Encapsulation — Tell, Don't Ask is encapsulation taken seriously. An object should hide its data and the rules about that data. Exposing getBalance/setBalance leaks both; exposing withdraw keeps them inside.
• Law of Demeter — its close cousin. Demeter says don't reach through an object to talk to strangers (order.getCustomer().getWallet()...); Tell, Don't Ask says don't reach into an object to grab its data and decide for it. Both push behaviour next to the data it needs, so you tell one friend (order.chargeCard(amount)) instead of digging.
• Rich objects, not data bags — following the rule turns anaemic objects (all getters/setters, no behaviour) into ones that actually do things and protect their own state.

Reach for it when a caller decides something the object should own

Tell, Don't Ask is most useful when you catch a caller pulling data out of an object, applying a rule, and pushing a result back — especially if that rule appears in more than one caller. Move the rule, and the data it protects, into the object.

• A get/check/set triple — if (x.getY() ...) x.setY(...). The rule connecting the getter and setter belongs inside the object as a single method.
• A rule copied across callers — the same validation or calculation written in several places. One method on the object means one copy that can't drift.
• Invariants that must hold — a balance that can't go negative, a status that must follow a sequence. Only the object can guarantee its own invariant, so the decision must live inside it.
• Anaemic domain objects — classes that are all getters and setters with no behaviour. Pushing decisions into them turns data bags into real objects.