Encapsulation

In any non-trivial application, your objects have rules they must follow. These rules are called invariants (conditions that must always be true).

An Order object's total price must equal the sum of its line items.
A User object's email field must always be a validly formatted email address.
A BankAccount object's balance must never be allowed to drop below its overdraft limit.

If any part of your application can directly modify an object's data, these invariants are at constant risk. This leads to a fragile system where bugs are hard to trace because you don't know what part of the code broke the rules. The goal is to design classes that enforce their own invariants, making the system robust by design.

Encapsulation is the bundling of data and the methods that operate on that data into a single unit (a class), and crucially, restricting direct access to that data.

For an interview, it's vital to frame this correctly: Encapsulation is not just about hiding data by making fields private. It's about giving a class complete responsibility over its own state. The class becomes the sole guardian of its data, ensuring its invariants are never violated.

The public methods of the class are not just simple "getters" or "setters"; they are a well-defined API that represents meaningful operations on that object, each one ensuring the object remains in a valid state.

A Practical Example: A Bank Account

Consider a BankAccount. Its core invariant is that a withdrawal cannot result in a balance below a defined overdraft limit.

A Poorly Encapsulated Approach:

public class BankAccount {
    public double balance; // Public access - anyone can set this to anything.
    public double overdraftLimit = -500.0;
}

// Client code can easily break the rules:
BankAccount account = new BankAccount();
account.balance = -10000.0; // Invariant violated. The object is in an invalid state.

A Properly Encapsulated Approach:

The balance is private. The only way to change it is through deposit and withdraw methods, which contain the business logic to protect the invariant.

public class BankAccount {
    private double balance;
    private final double overdraftLimit;

    public BankAccount(double initialBalance, double overdraftLimit) {
        this.balance = initialBalance;
        this.overdraftLimit = overdraftLimit;
    }

    public double getBalance() {
        return this.balance;
    }

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

    public boolean withdraw(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Withdrawal amount must be positive.");
        }

        // The invariant is checked and enforced here!
        if (this.balance - amount >= this.overdraftLimit) {
            this.balance -= amount;
            return true; // Withdrawal successful
        }
        
        return false; // Withdrawal failed
    }
}

Now, it is impossible for the BankAccount object to enter an invalid state through its public API. The object protects itself.

Encapsulation vs. Data Hiding

A common pitfall is to describe encapsulation as just "making fields private and adding public getters/setters." This is an incomplete answer that describes data hiding, not the full principle.

Talking about Data Hiding	Talking about Encapsulation
It's when you make fields private and provide public getters/setters.	It's the principle of bundling data and methods, where the class takes full responsibility for its own state and invariants.
Exposes all private fields with simple `getX()` and `setX()` methods.	Exposes methods that represent meaningful business operations (`deposit`, `withdraw`, `completeOrder`).
The logic for validation and business rules lives outside the class (in "service" layers).	The core business rules and invariants are enforced inside the class itself.
This leads to "anemic domain models" where objects are just simple data bags.	This leads to "rich domain models" where objects are smart, capable, and responsible for their own consistency.

Key Takeaway: True encapsulation means the methods represent a meaningful contract. If a class has a setBalance() method, it's just data hiding. If it has deposit() and withdraw() methods that contain logic, it's true encapsulation.

How Encapsulation Helps

Testability: You can write unit tests for the BankAccount class in complete isolation. You can verify with certainty that it correctly handles deposits, valid withdrawals, and invalid withdrawals without needing any other part of the system.
Maintainability: If the rule for overdrafts changes, you only have to modify the logic in one place: the withdraw method in the BankAccount class. No other part of the application is affected.
Domain-Driven Design (DDD): This concept is the foundation of creating a rich "Domain Model" in DDD. The core logic of your application (the "domain") is encoded within these robust, self-validating objects rather than being spread out in procedural service classes.
Immutability: The strongest form of encapsulation is immutability. If an object's state cannot be changed at all after creation, its invariants can never be violated. This is why immutable objects are inherently thread-safe and highly desirable in concurrent systems.