Encapsulation & accessors

Imagine if anyone could walk into a bank vault, open any safe deposit box, and change the cash numbers on a ledger. Financial catastrophe would ensue immediately. In software engineering, encapsulation (also known as information hiding) prevents this disaster by ensuring that an object’s internal fields cannot be manipulated directly by external code.

Encapsulation follows a simple two-step rule:

1. Declare all instance variables with the private access modifier (- in UML).
2. Provide public accessor methods to interact with the data:
   • Getters (Accessors): Public methods that return the attribute value (e.g. public double getBalance()).
   • Setters (Mutators): Public methods that accept a new value and validate it before updating the field.

Why not just make fields public? Consider setting a bank account balance:

// Without encapsulation (DANGEROUS):
account.balance = -50000; // Direct corruption! No validation possible.

// With encapsulation (PROTECTED):
public void setBalance(double amount) {
    if (amount >= 0) {
        this.balance = amount;
    } else {
        System.out.println("Error: Negative balance rejected!");
    }
}

By channeling all state changes through a setter, the class maintains complete control over its own invariants.