Encapsulation in Java Explained

Direct Answer

Encapsulation keeps an object's representation behind methods that preserve its rules. Fields are usually private, but the public API does not need a getter and setter for every field: it may expose operations such as deposit() or rename() instead. This prevents uncontrolled changes and lets implementation details evolve without forcing callers to change.

Code Example

public class BankAccount {
    private double balance; // hidden — nothing outside can touch it directly

    public BankAccount(double initialBalance) {
        if (initialBalance < 0)
            throw new IllegalArgumentException("Initial balance cannot be negative");
        this.balance = initialBalance;
    }

    // Getter: read-only access from outside
    public double getBalance() {
        return balance;
    }

    // Behavior method: encodes the business rule
    public void deposit(double amount) {
        if (amount <= 0)
            throw new IllegalArgumentException("Deposit amount must be positive");
        balance += amount;
    }

    public void withdraw(double amount) {
        if (amount <= 0)
            throw new IllegalArgumentException("Withdrawal amount must be positive");
        if (amount > balance)
            throw new IllegalStateException("Insufficient funds");
        balance -= amount; // rule checked in ONE place, every time
    }
}

// How callers use it:
BankAccount account = new BankAccount(500.0);
account.deposit(200.0);
account.withdraw(100.0);
System.out.println(account.getBalance()); // 600.0

// account.balance = -500; <-- COMPILE ERROR: balance is private

Switch balance from double to BigDecimal later and not a single caller changes — they all use getBalance(), deposit(), and withdraw().

Common Mistakes & Pitfalls

• Calling getters and setters 'encapsulation' — a private field with a pass-through setter that does no checking is the same exposure as a public field, just with more code.
• Adding a setter for every field by reflex — exposing setBalance() lets callers bypass your business rules; expose behavior like deposit() and withdraw() instead.
• Returning a mutable field straight from a getter — handing back the live List or Date lets the caller mutate your private state with .add(); return a copy or an unmodifiable view.
• Validating in the constructor but not in the methods — if withdraw() skips a check the constructor enforces, the object drifts into an invalid state after it is created.