Encapsulation, Access Modifiers and Packages

In the first lesson of this chapter anyone could write account.balance = -99999;. Real code can't allow that. Encapsulation means hiding an object's data and exposing only safe operations, so the object can always protect its own rules. It is the first of the four pillars of object-oriented programming.

Encapsulation in practice

public class Main {
    public static void main(String[] args) {
        BankAccount acc = new BankAccount("Meena", 1000);
        acc.withdraw(300);
        System.out.println(acc.getOwner() + " has ₹" + acc.getBalance());
        try {
            acc.withdraw(5000);
        } catch (IllegalStateException e) {
            System.out.println("Blocked: " + e.getMessage());
        }
        // acc.balance = 1_000_000;   → error: balance has private access
    }
}

class BankAccount {
    private final String owner;
    private double balance;              // hidden: only this class can touch it

    BankAccount(String owner, double opening) {
        this.owner = owner;
        deposit(opening);
    }

    public double getBalance() {          // read access
        return balance;
    }

    public String getOwner() {
        return owner;
    }

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

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

Meena has ₹700.0
Blocked: Insufficient funds

Notice there is no setBalance(). Good encapsulation doesn't mean a getter and setter for every field – it means exposing only the operations that make sense for the object.

Access modifiers

A practical default: make fields private, make methods public only if other classes need them, and use protected sparingly for things subclasses must customise. A top-level class can only be public or default.

Getters and setters with validation

public class Main {
    public static void main(String[] args) {
        Employee e = new Employee();
        e.setName("  Farah Khan ");
        e.setAge(29);
        System.out.println("[" + e.getName() + "] " + e.getAge());
        try {
            e.setAge(12);
        } catch (IllegalArgumentException ex) {
            System.out.println(ex.getMessage());
        }
    }
}

class Employee {
    private String name;
    private int age;

    public String getName() { return name; }

    public void setName(String name) {
        if (name == null || name.isBlank()) throw new IllegalArgumentException("Name required");
        this.name = name.strip();
    }

    public int getAge() { return age; }

    public void setAge(int age) {
        if (age < 18 || age > 65) throw new IllegalArgumentException("Age must be 18–65");
        this.age = age;
    }
}

[Farah Khan] 29
Age must be 18–65

The naming convention getX / setX (and isX for booleans) matters: frameworks such as Spring, Hibernate and Jackson use it to read and write your objects automatically.

Packages and imports

A package groups related classes, like folders, and gives them unique full names. Package names are lowercase and usually start with a reversed domain:

src/
└── com/learnfrenzy/bank/
    ├── BankAccount.java     // package com.learnfrenzy.bank;
    └── service/
        └── TransferService.java   // package com.learnfrenzy.bank.service;

package com.learnfrenzy.bank.service;

import com.learnfrenzy.bank.BankAccount;   // one class
import java.util.*;                        // every class in java.util (not sub-packages)

public class TransferService {
    public void transfer(BankAccount from, BankAccount to, double amount) {
        from.withdraw(amount);
        to.deposit(amount);
    }
}

• java.lang (String, Math, Integer, System…) is imported automatically.
• If two packages have a class with the same name (java.util.Date and java.sql.Date), use the full name for one of them.
• Default (package-private) access lets classes in the same package cooperate while hiding details from the rest of the application.

Immutable classes

An immutable object can't change after creation – like String. Immutable objects are simple to reason about and safe to share between threads.

import java.util.List;

public class Main {
    public static void main(String[] args) {
        Money a = new Money(19_999, "INR");
        Money b = a.plus(new Money(5_001, "INR"));
        System.out.println(a + " | " + b);
        List<String> fixed = List.of("read-only");
        System.out.println(fixed);
    }
}

final class Money {                       // final: no subclass can add mutability
    private final long paise;             // final fields, set once
    private final String currency;

    Money(long paise, String currency) {
        this.paise = paise;
        this.currency = currency;
    }

    Money plus(Money other) {             // "changes" return a new object
        return new Money(paise + other.paise, currency);
    }

    @Override
    public String toString() {
        return String.format("%s %.2f", currency, paise / 100.0);
    }
}

INR 199.99 | INR 250.00
[read-only]

Java 16+ records (chapter 10) create classes like this in a single line.

Practice

Summary

Interview practice: Java OOP in depth.