What is encapsulation, and how do access modifiers help achieve it?

Think of an ATM. The cash is locked inside the machine. You cannot open the box and take out notes; you have to insert a card, enter a PIN and request an amount. The machine checks your balance before giving anything. The money (data) and the rules for touching it (methods) live together, and the only way in is through the screen.

That is encapsulation. A class hides its fields and offers methods that check every change, so the object can never end up in a nonsense state, like a bank balance of minus fifty thousand rupees.

public class BankAccount {
    private final String accountNumber;   // hidden from outside
    private double balance;               // hidden from outside

    public BankAccount(String accountNumber) {
        this.accountNumber = accountNumber;
    }

    public void deposit(double amount) {
        if (amount <= 0) throw new IllegalArgumentException("Amount must be positive");
        balance += amount;
    }

    public void withdraw(double amount) {
        if (amount > balance) throw new IllegalStateException("Insufficient balance");
        balance -= amount;
    }

    public double getBalance() { return balance; }   // read-only access, no setter

    public static void main(String[] args) {
        BankAccount acc = new BankAccount("SB-1029");
        acc.deposit(5000);
        acc.withdraw(1200);
        System.out.println(acc.getBalance());   // prints: 3800.0
        // acc.balance = -50000;               // compile error: balance has private access
    }
}

There is no setBalance method. The only ways to change the balance are deposit and withdraw, and both enforce the rules.

Java has four access levels:

A common pattern:

• Fields are private.
• Methods that other code needs are public.
• Helper methods used only inside the class are private.
• Getters are added only when needed, and setters only when a field should really change, with validation inside.

• A ShoppingCart that keeps its item list private and exposes addItem, removeItem and total, so nobody can insert an item with a negative quantity.
• An Order whose status can move from PLACED to SHIPPED but never back, enforced inside the class.
• Libraries keep internals private so they can change them in a new version without breaking your code.

• Making fields private and then generating a public getter and setter for every one without any checks. That is just a public field with extra steps.
• Returning a private mutable list directly from a getter. The caller can then modify it. Return List.copyOf(items) or an unmodifiable view.
• Confusing encapsulation with abstraction. Encapsulation hides data and protects it; abstraction hides complexity behind a simple interface.
• Thinking protected means "only subclasses". In Java it also gives access to every class in the same package.

• What is the difference between encapsulation and abstraction?
• Can a top-level class be private or protected?
• How do you make a class fully immutable?
• What is the default access modifier for members of an interface?