Java Notes

Encapsulation in Java

Complete guide to encapsulation in Java — access modifiers, getters and setters, data hiding, immutable classes, and building robust protected object state.

Encapsulation is the practice of bundling data (fields) and the methods that operate on that data into a single unit (class), while restricting direct access to the internal state. External code interacts with the object only through a controlled public interface.

Think of a capsule — medicine is wrapped inside a protective shell. You take the capsule (public interface), but you never directly touch the medicine inside (private fields).

Why Encapsulation Matters

Without encapsulation, any code can modify any data:

java example

// ❌ NO encapsulation — fields exposed
public class BankAccount {
    public double balance;
    public String owner;
}

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount();
        account.balance = 1000;

        // ANYONE can do this — no validation!
        account.balance = -999999;  // Negative balance? No protection!
        account.owner = "";         // Empty owner? No rules!
    }
}

With encapsulation, you control all access:

Example

// ✅ ENCAPSULATED — data protected, access controlled public class BankAccount { private double balance; private String owner; private List<String> transactions; public BankAccount(String owner, double initialDeposit) { if (owner == null || owner.trim().isEmpty()) { throw new IllegalArgumentException("Owner name required"); } if (initialDeposit < 0) { throw new IllegalArgumentException("Initial deposit cannot be negative"); } this.owner = owner; this.balance = initialDeposit; this.transactions = new ArrayList<>(); transactions.add("Opened with $" + initialDeposit); } public double getBalance() { return balance; // Read-only access } public String getOwner() { return owner; } public boolean deposit(double amount) { if (amount <= 0) { System.out.println("Error: Deposit must be positive"); return false; } balance += amount; transactions.add("Deposited: $" + amount); return true; } public boolean withdraw(double amount) { if (amount <= 0) { System.out.println("Error: Withdrawal must be positive"); return false; } if (amount > balance) { System.out.println("Error: Insufficient funds"); return false; } balance -= amount; transactions.add("Withdrew: $" + amount); return true; } // Return a COPY of transactions, not the actual list public List<String> getTransactionHistory() { return new ArrayList<>(transactions); // Defensive copy } } public class Main { public static void main(String[] args) { BankAccount account = new BankAccount("Alice", 1000); account.deposit(500); account.withdraw(200); account.withdraw(5000); // Fails — insufficient funds account.deposit(-100); // Fails — negative amount System.out.println("Balance: $" + account.getBalance()); System.out.println("History: " + account.getTransactionHistory()); } }

Output

Error: Insufficient funds
Error: Deposit must be positive
Balance: $1300.0
History: [Opened with $1000.0, Deposited: $500.0, Withdrew: $200.0]

Access Modifiers — The Tools of Encapsulation

Modifier	Same Class	Same Package	Subclass (other pkg)	Everywhere
`private`	✅	❌	❌	❌
(default)	✅	✅	❌	❌
`protected`	✅	✅	✅	❌
`public`	✅	✅	✅	✅

java example

public class AccessDemo {
    private int privateField = 1;      // Only this class
    int defaultField = 2;              // This package
    protected int protectedField = 3;  // This package + subclasses
    public int publicField = 4;        // Everyone

    private void privateMethod() { }
    void defaultMethod() { }
    protected void protectedMethod() { }
    public void publicMethod() { }
}

Choosing the Right Modifier

private — Default choice for fields. Always start here.
protected — For fields/methods that subclasses need
(default) — For package-internal helpers
public — Only for the intended API surface

Getters and Setters

The standard pattern for controlled field access:

Example

public class Employee { private String name; private double salary; private int age; private String department; public Employee(String name, double salary, int age, String department) { setName(name); // Use setters for validation setSalary(salary); setAge(age); setDepartment(department); } // GETTER — read access public String getName() { return name; } // SETTER — write access with validation public void setName(String name) { if (name == null || name.trim().isEmpty()) { throw new IllegalArgumentException("Name cannot be empty"); } this.name = name.trim(); } public double getSalary() { return salary; } public void setSalary(double salary) { if (salary < 0) { throw new IllegalArgumentException("Salary cannot be negative"); } this.salary = salary; } public int getAge() { return age; } public void setAge(int age) { if (age < 18 || age > 70) { throw new IllegalArgumentException("Age must be between 18 and 70"); } this.age = age; } public String getDepartment() { return department; } public void setDepartment(String department) { if (department == null || department.trim().isEmpty()) { throw new IllegalArgumentException("Department cannot be empty"); } this.department = department.trim(); } }

Not All Fields Need Setters

Some fields should be read-only after construction:

java example

public class OrderItem {
    private final String productId;  // Immutable after creation
    private final String productName;
    private int quantity;  // Can be updated

    public OrderItem(String productId, String productName, int quantity) {
        this.productId = productId;
        this.productName = productName;
        setQuantity(quantity);
    }

    // Only getters for immutable fields
    public String getProductId() { return productId; }
    public String getProductName() { return productName; }

    // Getter AND setter for mutable field
    public int getQuantity() { return quantity; }
    public void setQuantity(int quantity) {
        if (quantity < 1) {
            throw new IllegalArgumentException("Quantity must be at least 1");
        }
        this.quantity = quantity;
    }
}

Defensive Copies — Protecting Mutable Fields

When your fields contain mutable objects (like lists, arrays, dates), you must return copies:

Example

public class StudentRecord { private String name; private List<Integer> grades; private Date enrollmentDate; public StudentRecord(String name, List<Integer> grades, Date enrollmentDate) { this.name = name; this.grades = new ArrayList<>(grades); // Defensive copy IN this.enrollmentDate = new Date(enrollmentDate.getTime()); // Copy in } public List<Integer> getGrades() { return new ArrayList<>(grades); // Defensive copy OUT // NOT: return grades; — caller could modify our internal list! } public Date getEnrollmentDate() { return new Date(enrollmentDate.getTime()); // Copy out } public void addGrade(int grade) { if (grade < 0 || grade > 100) { throw new IllegalArgumentException("Grade must be 0-100"); } grades.add(grade); } public double getAverage() { return grades.stream().mapToInt(Integer::intValue).average().orElse(0); } } public class Main { public static void main(String[] args) { List<Integer> grades = new ArrayList<>(List.of(85, 90, 78)); StudentRecord record = new StudentRecord("Alice", grades, new Date()); // Try to cheat by modifying the original list grades.add(100); // Doesn't affect record! // Try to cheat through getter List<Integer> gotten = record.getGrades(); gotten.add(200); // Doesn't affect record! record.addGrade(92); // Proper way to add System.out.println("Grades: " + record.getGrades()); System.out.println("Average: " + record.getAverage()); } }

Output

Grades: [85, 90, 78, 92]
Average: 86.25

Immutable Classes — Maximum Encapsulation

An immutable class cannot be modified after creation:

Example

public final class Money { private final double amount; private final String currency; public Money(double amount, String currency) { if (amount < 0) throw new IllegalArgumentException("Amount cannot be negative"); if (currency == null || currency.length() != 3) { throw new IllegalArgumentException("Currency must be 3-letter code"); } this.amount = amount; this.currency = currency.toUpperCase(); } // Only getters — no setters! public double getAmount() { return amount; } public String getCurrency() { return currency; } // Operations return NEW objects public Money add(Money other) { if (!this.currency.equals(other.currency)) { throw new IllegalArgumentException("Cannot add different currencies"); } return new Money(this.amount + other.amount, this.currency); } public Money multiply(double factor) { return new Money(this.amount * factor, this.currency); } @Override public String toString() { return String.format("%s %.2f", currency, amount); } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof Money)) return false; Money other = (Money) obj; return Double.compare(amount, other.amount) == 0 && currency.equals(other.currency); } @Override public int hashCode() { return Objects.hash(amount, currency); } } public class Main { public static void main(String[] args) { Money price = new Money(29.99, "USD"); Money tax = new Money(2.40, "USD"); Money total = price.add(tax); // Returns NEW object System.out.println("Price: " + price); System.out.println("Tax: " + tax); System.out.println("Total: " + total); Money discounted = total.multiply(0.9); System.out.println("After 10% off: " + discounted); } }

Output

Price: USD 29.99
Tax: USD 2.40
Total: USD 32.39
After 10% off: USD 29.15

Rules for Immutable Classes:

Class is final (cannot be subclassed)
All fields are private final
No setters
Methods that "modify" return new objects
Defensive copies for mutable parameters and returns

Real-World Encapsulation: Configuration Manager

java example

public class AppConfig {
    private static AppConfig instance;
    private final Map<String, String> settings;
    private final String environment;
    private boolean locked;

    private AppConfig(String environment) {
        this.environment = environment;
        this.settings = new HashMap<>();
        this.locked = false;
    }

    public static AppConfig create(String environment) {
        if (instance != null) {
            throw new IllegalStateException("Config already initialized");
        }
        instance = new AppConfig(environment);
        return instance;
    }

    public static AppConfig getInstance() {
        if (instance == null) {
            throw new IllegalStateException("Config not initialized");
        }
        return instance;
    }

    public void set(String key, String value) {
        if (locked) {
            throw new IllegalStateException("Config is locked — cannot modify");
        }
        settings.put(key, value);
    }

    public String get(String key) {
        return settings.getOrDefault(key, null);
    }

    public String get(String key, String defaultValue) {
        return settings.getOrDefault(key, defaultValue);
    }

    // Once locked, no more modifications
    public void lock() {
        this.locked = true;
        System.out.println("Config locked for " + environment);
    }

    public String getEnvironment() { return environment; }
    public boolean isLocked() { return locked; }
}

Common Mistakes

Exposing internal mutable objects:

``java private List<String> items; public List<String> getItems() { return items; } // ❌ External code can modify! public List<String> getItems() { return Collections.unmodifiableList(items); } // ✅ ``

Public fields:

``java public int age; // ❌ No validation possible ``

Setters that don't validate:

``java public void setAge(int age) { this.age = age; } // ❌ age = -5 allowed! ``

Getter returns reference to mutable field:

``java private Date birthDate; public Date getBirthDate() { return birthDate; } // ❌ Caller can mutate! ``

Breaking encapsulation with reflection (intentional violation):

``java Field field = obj.getClass().getDeclaredField("privateField"); field.setAccessible(true); // Breaks encapsulation! Don't do this in production. ``

Best Practices

Default to private — only expose what's necessary
Use final for fields that shouldn't change after construction
Return defensive copies of mutable objects
Validate all input in setters and constructors
Prefer immutable classes when possible
Don't generate getters/setters blindly — think about what should be exposed
Use Collections.unmodifiableList() for read-only collection access

Interview Questions

Q1: What is encapsulation? Bundling data and methods into a class while hiding internal state behind access modifiers. External code uses only the public interface.

Q2: How does encapsulation differ from abstraction? Abstraction is about design (WHAT to show). Encapsulation is about implementation (HOW to hide). Encapsulation implements the hiding that abstraction designs.

Q3: Can we achieve encapsulation without getters/setters? Yes. Not all fields need external access. Some fields are purely internal. Encapsulation means controlling access — sometimes that means NO access.

Q4: What is a POJO? Plain Old Java Object — a class with private fields, a constructor, getters, and setters. No business logic.

Q5: Why return defensive copies from getters? To prevent external code from modifying your internal state through the returned reference. Especially important for mutable objects like List, Date, and arrays.

Q6: What is the benefit of immutable classes? Thread-safe without synchronization, safe to share, no unexpected state changes, simpler to reason about, and good HashMap keys.

Q7: What happens if you access a private field from another instance of the same class? It works! Access modifiers are per-CLASS, not per-object. One BankAccount object CAN access private fields of another BankAccount object.

Q8: What is the difference between tight encapsulation and loose encapsulation? Tight encapsulation: ALL fields are private, accessed only through methods with validation. No field is accessible without going through the class's public API. Loose encapsulation: some fields are protected or package-private, allowing broader access. Tight encapsulation is preferred for robust code.

Q9: How does encapsulation support the principle of least privilege? Encapsulation ensures each component only exposes what's necessary. Private fields + specific getters/setters mean external code can only do what you explicitly allow. This prevents accidental misuse, reduces bugs, and makes the system more secure and maintainable.

Q10: What is an immutable class and how does encapsulation help? An immutable class has state that cannot change after creation. Encapsulation enables this: make fields private final, provide no setters, don't leak mutable references (return copies), and make the class final. Example: String, Integer, LocalDate.

Q11: How do getters and setters differ from public fields? Getters/setters provide: (1) validation (reject negative age), (2) computed properties (return calculated values), (3) read-only or write-only access, (4) ability to change implementation without affecting users, (5) debugging hooks. Public fields provide none of these.

Q12: Can encapsulation exist without abstraction? Yes, but they usually work together. Encapsulation is the mechanism (private fields, public methods). You could technically have private fields with getters that expose everything — that's encapsulation without meaningful abstraction. Good design uses both: hide data AND simplify the interface.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Encapsulation in Java.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Java Master Course topic.

Search Terms

java-master-course, java master course, java, master, course, oops, encapsulation, encapsulation in java

Continue learning this concept

OOPsAbstract Class in JavaComplete guide to abstract classes in Java — abstract methods, partial implementation, when to use abstract classes, template method pattern, and abstract class vs interface comparison.OOPsAbstraction in JavaComplete guide to abstraction in Java — hiding complexity, abstract classes and interfaces, abstraction layers, real-world design, and achieving loose coupling through abstraction.OOPsAnonymous Class in JavaComplete guide to anonymous classes in Java — creating inline implementations, event handlers, comparators, and understanding when lambdas replaced anonymous classes.OOPsClass and Object in JavaDeep dive into Java classes and objects — class anatomy, object creation, memory allocation, instance vs class members, and how objects work under the hood in the JVM.OOPsConstructor in JavaComplete guide to Java constructors — default, parameterized, copy constructors, constructor chaining, overloading, and the role of constructors in object initialization.OOPsInheritance in JavaComplete guide to Java inheritance — single, multilevel, and hierarchical inheritance, method inheritance, the IS-A relationship, composition vs inheritance, and the Diamond Problem.

PreviousConstructor in Java NextInheritance in Java

Java Notes

Encapsulation in Java

Complete guide to encapsulation in Java — access modifiers, getters and setters, data hiding, immutable classes, and building robust protected object state.

Think of a capsule — medicine is wrapped inside a protective shell. You take the capsule (public interface), but you never directly touch the medicine inside (private fields).

Why Encapsulation Matters

Without encapsulation, any code can modify any data:

java example

// ❌ NO encapsulation — fields exposed
public class BankAccount {
    public double balance;
    public String owner;
}

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount();
        account.balance = 1000;

        // ANYONE can do this — no validation!
        account.balance = -999999;  // Negative balance? No protection!
        account.owner = "";         // Empty owner? No rules!
    }
}

With encapsulation, you control all access:

Example

Output

Error: Insufficient funds
Error: Deposit must be positive
Balance: $1300.0
History: [Opened with $1000.0, Deposited: $500.0, Withdrew: $200.0]

Access Modifiers — The Tools of Encapsulation

Modifier	Same Class	Same Package	Subclass (other pkg)	Everywhere
`private`	✅	❌	❌	❌
(default)	✅	✅	❌	❌
`protected`	✅	✅	✅	❌
`public`	✅	✅	✅	✅

java example

public class AccessDemo {
    private int privateField = 1;      // Only this class
    int defaultField = 2;              // This package
    protected int protectedField = 3;  // This package + subclasses
    public int publicField = 4;        // Everyone

    private void privateMethod() { }
    void defaultMethod() { }
    protected void protectedMethod() { }
    public void publicMethod() { }
}

Choosing the Right Modifier

private — Default choice for fields. Always start here.
protected — For fields/methods that subclasses need
(default) — For package-internal helpers
public — Only for the intended API surface

Getters and Setters

The standard pattern for controlled field access:

Example

Not All Fields Need Setters

Some fields should be read-only after construction:

java example

public class OrderItem {
    private final String productId;  // Immutable after creation
    private final String productName;
    private int quantity;  // Can be updated

    public OrderItem(String productId, String productName, int quantity) {
        this.productId = productId;
        this.productName = productName;
        setQuantity(quantity);
    }

    // Only getters for immutable fields
    public String getProductId() { return productId; }
    public String getProductName() { return productName; }

    // Getter AND setter for mutable field
    public int getQuantity() { return quantity; }
    public void setQuantity(int quantity) {
        if (quantity < 1) {
            throw new IllegalArgumentException("Quantity must be at least 1");
        }
        this.quantity = quantity;
    }
}

Defensive Copies — Protecting Mutable Fields

When your fields contain mutable objects (like lists, arrays, dates), you must return copies:

Example

Output

Grades: [85, 90, 78, 92]
Average: 86.25

Immutable Classes — Maximum Encapsulation

An immutable class cannot be modified after creation:

Example

Output

Price: USD 29.99
Tax: USD 2.40
Total: USD 32.39
After 10% off: USD 29.15

Rules for Immutable Classes:

Class is final (cannot be subclassed)
All fields are private final
No setters
Methods that "modify" return new objects
Defensive copies for mutable parameters and returns

Real-World Encapsulation: Configuration Manager

java example

public class AppConfig {
    private static AppConfig instance;
    private final Map<String, String> settings;
    private final String environment;
    private boolean locked;

    private AppConfig(String environment) {
        this.environment = environment;
        this.settings = new HashMap<>();
        this.locked = false;
    }

    public static AppConfig create(String environment) {
        if (instance != null) {
            throw new IllegalStateException("Config already initialized");
        }
        instance = new AppConfig(environment);
        return instance;
    }

    public static AppConfig getInstance() {
        if (instance == null) {
            throw new IllegalStateException("Config not initialized");
        }
        return instance;
    }

    public void set(String key, String value) {
        if (locked) {
            throw new IllegalStateException("Config is locked — cannot modify");
        }
        settings.put(key, value);
    }

    public String get(String key) {
        return settings.getOrDefault(key, null);
    }

    public String get(String key, String defaultValue) {
        return settings.getOrDefault(key, defaultValue);
    }

    // Once locked, no more modifications
    public void lock() {
        this.locked = true;
        System.out.println("Config locked for " + environment);
    }

    public String getEnvironment() { return environment; }
    public boolean isLocked() { return locked; }
}

Common Mistakes

Exposing internal mutable objects:

Public fields:

``java public int age; // ❌ No validation possible ``

Setters that don't validate:

``java public void setAge(int age) { this.age = age; } // ❌ age = -5 allowed! ``

Getter returns reference to mutable field:

``java private Date birthDate; public Date getBirthDate() { return birthDate; } // ❌ Caller can mutate! ``

Breaking encapsulation with reflection (intentional violation):

``java Field field = obj.getClass().getDeclaredField("privateField"); field.setAccessible(true); // Breaks encapsulation! Don't do this in production. ``

Best Practices

Default to private — only expose what's necessary
Use final for fields that shouldn't change after construction
Return defensive copies of mutable objects
Validate all input in setters and constructors
Prefer immutable classes when possible
Don't generate getters/setters blindly — think about what should be exposed
Use Collections.unmodifiableList() for read-only collection access

Interview Questions

Q1: What is encapsulation? Bundling data and methods into a class while hiding internal state behind access modifiers. External code uses only the public interface.

Q4: What is a POJO? Plain Old Java Object — a class with private fields, a constructor, getters, and setters. No business logic.

Q6: What is the benefit of immutable classes? Thread-safe without synchronization, safe to share, no unexpected state changes, simpler to reason about, and good HashMap keys.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Encapsulation in Java.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Java Master Course topic.

Search Terms

java-master-course, java master course, java, master, course, oops, encapsulation, encapsulation in java

Continue learning this concept

PreviousConstructor in Java NextInheritance in Java