Encapsulation

Private vs. public

Every member of a class is either public — anyone can see and touch it — or private — only the object's own methods can. Encapsulation is the habit of keeping data private and making a small, deliberate set of methods public. The public methods are the object's front door; the private fields are the locked room behind it.

Picture a vending machine. There's a locked cash box inside (private). You can't open it and take the money. What you can do is press buttons and insert coins (public methods). The machine decides whether to dispense a snack and how much change to return. The rules live with the machine, not with whoever walks up to it.

Access modifiers

Languages give you keywords to mark this boundary. In TypeScript it's private (or a #name field that's truly hidden at runtime). In Java and C++ it's private. Python has no hard private, so the convention is a leading underscore like _balance, often paired with a property to control access. Same idea everywhere: a label that says this is internal, don't touch it from outside.

Getters and setters — done right

A getter reads a private field; a setter changes it. The point of routing through them is not to mindlessly mirror the field — it's to add a checkpoint. A good setter validates:

• Validate before you write. A deposit(amount) rejects a negative amount; a setTemperature(c) rejects anything below absolute zero. The method refuses bad input instead of storing it.
• Expose read-only when that's all you need. Often you want a getter and no setter at all — outsiders can look at the balance but can only change it by depositing or withdrawing.
• Don't just pass the field through. A setter that does this._balance = value with no check gives away everything privacy bought you. If a field has no rules, maybe it doesn't need a setter.

Invariants: the rules the object guards

An invariant is a fact that must always be true about an object — for a bank account, balance >= 0. Encapsulation is what lets the object promise that invariant. Because the only way in is through deposit and withdraw, and those methods check the rule, the balance can never go negative. The object enforces its own correctness.

class BankAccount {
  // private — the front door is the methods below, not this field
  #balance = 0;

  deposit(amount: number) {
    if (amount <= 0) throw new Error("amount must be positive");
    this.#balance += amount;            // guarded write
  }

  withdraw(amount: number) {
    if (amount > this.#balance) throw new Error("insufficient funds");
    this.#balance -= amount;            // invariant balance >= 0 holds
  }

  get balance() { return this.#balance; } // read-only view, no setter
}

const a = new BankAccount();
a.deposit(100);
// a.#balance = -5  ← won't even compile; the field is unreachable

Why data and its guard methods belong together

The validation rules and the data they protect are two halves of one thing. If they're split apart — data in one place, the checks scattered across the codebase — sooner or later someone changes the data without running the checks. Keeping balance and the deposit/withdraw that guard it in the same class means there's exactly one trusted path in, and the rules can't be skipped.

When to make things private

• When a field has rules — a balance that can't go negative, a percentage that must stay 0–100, a status that only changes in a set order.
• When you want to change the internals later without breaking callers — hide the field now, and you're free to swap how it's stored.
• When data and the logic that protects it belong together — keep them in one class so the checks can't be skipped.