Encapsulation

Encapsulation as a Design Boundary

In low-level design, encapsulation is not just private fields — it is the decision of which state a class owns and which operations are allowed to touch it. The class becomes a boundary: callers interact through behavior, and the invariant (the set of rules that must always hold) is defended inside.

Modeling steps

1. List the invariants of the entity (e.g., a Wallet balance can never be negative).
2. Make the state private and expose only operations that preserve the invariant.
3. Reject invalid transitions with validation inside the method, not at the caller.

class Wallet {
    private long balanceCents; // invariant: >= 0

    // behavior preserves the invariant — callers cannot bypass it
    public void credit(long amountCents) {
        if (amountCents <= 0) throw new IllegalArgumentException("amount must be positive");
        balanceCents += amountCents;
    }

    public boolean debit(long amountCents) {
        if (amountCents <= 0 || amountCents > balanceCents) return false;
        balanceCents -= amountCents;
        return true;
    }

    public long balanceCents() { return balanceCents; } // read-only view
}

If balanceCents were public, every caller would become responsible for the invariant — and one missed check corrupts the whole system. Encapsulation moves that responsibility to the single owner.

Anemic model smell

A design where every class is a data bag with public getters/setters and all logic lives in Service classes is an anemic domain model. It compiles and runs, but invariants are enforced far from the state, and the design degrades into procedural code with DTOs.

Access Surface: Getters, Methods, or Nothing

Not every private field needs a getter. Choose the narrowest access surface that supports real use cases:

Returning internals breaks the boundary

// LEAK: caller can mutate the list behind the class's back
class Order {
    private final List<Item> items = new ArrayList<>();
    public List<Item> getItems() { return items; }
}

order.getItems().clear(); // invariant destroyed from outside

Fix by returning an unmodifiable view or a defensive copy:

public List<Item> items() { return Collections.unmodifiableList(items); }

Tell, don't ask

Prefer order.cancel(reason) over order.setStatus(CANCELLED); order.setCancelledAt(now);. The first keeps the transition logic — and its invariants — inside Order; the second makes every caller a co-author of your state rules.

Encapsulation Across Object Graphs

Real LLD problems chain objects: an Account holds a Wallet, a Wallet holds Transactions. Encapsulation decisions must hold at every hop of the graph.

Composition over exposure

class CheckoutService {
    // good: PaymentGateway is hidden behind Checkout's behavior
    private final PaymentGateway gateway;

    Result pay(Order order, Card card) {
        return gateway.charge(card, order.total());
    }
}

Callers of CheckoutService never learn which gateway is used, so swapping Stripe for an in-memory fake in tests changes nothing outside the class.

Cross-object invariants

Some invariants span several objects — "an order can only be paid once". Encapsulate the rule in the aggregate root (Order.pay() marks itself paid before calling the gateway) instead of letting CheckoutService set flags from outside.

Interview checklist

• Who owns each piece of mutable state? One class, always.
• Which methods may change it? Are they validating the invariant?
• Does any getter return a live internal collection or reference?
• If I replace a collaborator (DB, API), which classes change? Ideally one.
• Can I describe the class in one sentence starting with "X manages ..."?

Encapsulation is the first tool you reach for in every LLD round: it sets the boundaries every later decision (patterns, persistence, concurrency) builds on.