All topics
26 / 101
library
beginner

Encapsulation in Java

Hide internal state behind access modifiers and expose behavior through public methods.

Encapsulation means the fields are private and the outside world goes through methods.

A bank account: you can't reach into the vault (private balance). You use the teller window (public methods) which enforces rules like 'no overdraft.'

Key Concepts

1
    public class BankAccount {
      private double balance;          // nobody can touch this
2
      public void deposit(double amt) {
        if (amt <= 0) throw new IllegalArgumentException();
        balance += amt;
      }
      public double getBalance() { return balance; }
    }
3
The point is the check in deposit. A public field cannot reject a negative amount. A method can, and every caller goes through it.
deposit
4
It also lets you change how the data is stored.
    private String firstName, lastName;
    public String getFullName() { return firstName + " " + lastName; }
5
    // later: one stored field instead of two
    private String fullName;
    public String getFullName() { return fullName; }
6
Callers never change. That is the real payoff in a large codebase, where a field's type otherwise ripples into hundreds of files.
7
A getter and setter for every field is barely encapsulated.
    account.setBalance(account.getBalance() - 100);   // the caller does the work
    account.withdraw(100);                            // the class does the work
8
The second form can check for insufficient funds. The first cannot, because the rule lives in the caller where nobody can enforce it.
9
So expose behaviour, not storage. Ask what callers want to do, then name a method for that.
10
Returning a mutable object leaks the state back out.
    public List<Txn> getTxns() { return txns; }                  // caller can add
    public List<Txn> getTxns() { return List.copyOf(txns); }      // caller cannot
11
The first hands out a reference to the internal list, so any caller can modify it. Returning a copy, or an unmodifiable view, closes that hole.
12
What the interviewer is probing.1. "What is encapsulation, and is a class with a getter and setter for every field encapsulated?" Probing: whether you understand the point or just the syntax. Stalls: "It means making fields private." Moves up: that routing access through methods lets you enforce rules; getters and setters for everything expose the same state with extra steps.
13
2. "Your getter returns a List field. What is wrong with that?" Probing: defensive copying. Stalls: "Nothing, it is just a read." Moves up: the caller gets a reference to the internal list and can modify it; return List.copyOf or an unmodifiable view.
14
3. "How does encapsulation let you change the implementation later?" Probing: whether you can connect it to maintenance cost. Stalls: "It is good practice." Moves up: a worked example: two stored fields collapsed into one, with getFullName() unchanged, so no caller recompiles.
15
4. "Is encapsulation the same as abstraction?" Probing: whether you can separate two words people use interchangeably. Stalls: "They are basically the same." Moves up: encapsulation hides the data behind an API; abstraction hides the complexity behind a simpler model. One is about access, the other about design.
Use cases:OOPDesignBest Practices