Encapsulation: Protecting an Object's Data Behind a Small Interface

Encapsulation is the first and most fundamental of the four pillars of OOP. It's a simple rule with large consequences: an object keeps its internal data private and lets the outside world touch it only through a small, deliberate set of methods.

The problem it solves

Suppose an account's balance is a plain, public value that any code can change:

account.balance = account.balance - 50   # anyone, anywhere

Now the rule "you can never withdraw more than you have" can be broken from anywhere in the program. When a negative balance shows up in production, the bug could have originated in any file that touched balance. There's no single place that guarantees the rule.

The fix: a front door

Encapsulation makes the data private and forces every change through a method that enforces the rules:

class Account:
    private balance = 0
 
    method withdraw(amount):
        if amount <= balance:
            balance = balance - amount
        else:
            reject("insufficient funds")

Now the invariant — balance never goes negative — is guaranteed in one place. Callers can't corrupt the state because they can't reach it; they can only ask the object to do something, and the object decides whether that's allowed.

The second payoff: freedom to change

Because callers only ever see the methods, you're free to change how the object works internally — and nobody else has to know.

Store the balance in cents instead of dollars, add an audit log on every change, cache a running total — none of it touches the code that uses the account, as long as the methods still behave the same. The interface is the promise; the internals are yours to change. This is what lets large codebases evolve without every change rippling everywhere.

The trap: getters and setters for everything

A common misreading of encapsulation is to make every field private and then add a pass-through getBalance() and setBalance() for each one:

account.setBalance(account.getBalance() - 50)   # back to square one

This looks encapsulated but isn't: a public setter for balance is just a public balance with extra steps — the invariant is gone again. Encapsulation is about exposing behaviour, not raw fields. Prefer a meaningful withdraw(amount) that enforces rules over a setBalance that lets callers set anything.

Recap

• Encapsulation keeps an object's data private and exposes a small set of methods as the only way to change it.
• This puts each rule (an invariant) in one place, shrinking where a whole class of bug can originate.
• It also frees you to change the internals without breaking callers, as long as the interface holds.
• Avoid the getter/setter-for-everything trap — expose behaviour, not raw fields.

Encapsulation hides the internals. The next pillar is about designing the simple interface you expose in their place. Continue to Abstraction.