Encapsulation is the practice of bundling data and the methods that operate on that data into a single class, and restricting direct access to the data from outside. The fields are hidden. The behaviour is exposed. External code interacts with the object only through the methods the class provides — it never reaches directly into the object's state.

This is not just a rule about using private. Encapsulation is a design principle about control. The class controls what state it holds, what changes it allows, and what rules it enforces. Without encapsulation, any code anywhere can corrupt any object's state — and the class has no say in it.

What Is Encapsulation in Java?

Encapsulation is one of the four pillars of Object-Oriented Programming. It combines two things:

›Data hiding — declaring fields private so external code cannot access them directly
›Controlled access — providing public methods (getters and setters) that enforce rules about how data is read and modified

A well-encapsulated class is one where:

›All fields are private
›Read access is provided through getter methods when needed
›Write access is provided through setter methods with validation when needed
›The class itself enforces all business rules about its data

The result is that the class is the single authority on its own state. No other class can bypass the rules.

Why Encapsulation Matters

Consider what happens without it:

Java

// Without encapsulation — any code can corrupt the object
public class BankAccount {
    public double balance;   // anyone can set this to anything
    public String accountId;
}

// Caller can do this — no validation, no control
BankAccount account = new BankAccount();
account.balance = -99999999.0; // negative balance — invalid but unchecked
account.accountId = null;      // corrupted state

Now consider with encapsulation:

Java

// With encapsulation — only controlled changes are possible
public class BankAccount {
    private double balance;
    private final String accountId;

    public BankAccount(String accountId, double initialDeposit) {
        this.accountId = accountId;
        this.balance   = Math.max(0.0, initialDeposit);
    }

    public double getBalance() { return balance; }

    public boolean deposit(double amount) {
        if (amount <= 0) return false;
        balance += amount;
        return true;
    }

    public boolean withdraw(double amount) {
        if (amount <= 0 || amount > balance) return false;
        balance -= amount;
        return true;
    }
}

In the second version, no external code can set balance to a negative value. The business rules live inside the class where they belong — not scattered in every caller that modifies the object.

Getters and Setters

Getters provide read access to private fields. Setters provide write access — and crucially, they can validate input before allowing the change.

Java

// File: UserProfile.java

public class UserProfile {

    private String  username;
    private String  email;
    private int     age;
    private boolean isPremiumMember;

    public UserProfile(String username, String email, int age) {
        setUsername(username); // uses setter for validation even in constructor
        setEmail(email);
        setAge(age);
        this.isPremiumMember = false;
    }

    // Getter — read access only
    public String getUsername()      { return username; }
    public String getEmail()         { return email; }
    public int    getAge()           { return age; }
    public boolean isPremiumMember() { return isPremiumMember; }

    // Setter with validation
    public void setUsername(String username) {
        if (username == null || username.trim().length() < 3) {
            throw new IllegalArgumentException(
                    "Username must be at least 3 characters.");
        }
        this.username = username.trim().toLowerCase();
    }

    public void setEmail(String email) {
        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("Invalid email address: " + email);
        }
        this.email = email.trim().toLowerCase();
    }

    public void setAge(int age) {
        if (age < 13 || age > 120) {
            throw new IllegalArgumentException(
                    "Age must be between 13 and 120. Got: " + age);
        }
        this.age = age;
    }

    public void upgradeToPremium() {
        this.isPremiumMember = true;
    }

    public String getSummary() {
        return username + " | " + email + " | Age: " + age
                + " | Premium: " + isPremiumMember;
    }
}

Java

// File: GetterSetterDemo.java

public class GetterSetterDemo {

    public static void main(String[] args) {

        UserProfile user = new UserProfile("  Rahul_Dev  ", "Rahul@Example.COM", 25);
        System.out.println(user.getSummary());

        // Valid update
        user.setEmail("rahul.dev@company.com");
        user.upgradeToPremium();
        System.out.println(user.getSummary());

        // Invalid update — throws exception with clear message
        try {
            user.setAge(-5);
        } catch (IllegalArgumentException ex) {
            System.out.println("Rejected: " + ex.getMessage());
        }

        // Invalid constructor — caught at creation time
        try {
            UserProfile invalid = new UserProfile("AB", "notanemail", 25);
        } catch (IllegalArgumentException ex) {
            System.out.println("Rejected: " + ex.getMessage());
        }
    }
}

Output:
rahul_dev | rahul@example.com | Age: 25 | Premium: false
rahul_dev | rahul.dev@company.com | Age: 25 | Premium: true
Rejected: Age must be between 13 and 120. Got: -5
Rejected: Username must be at least 3 characters.

The username is automatically trimmed and lowercased in the setter. The age validation rejects impossible values. These rules are defined once, inside UserProfile, and they apply to every modification — whether the caller is the constructor, a direct setter call, or any future code path. During code reviews, input validation scattered in callers rather than centralised in setters is consistently flagged.

Encapsulation and Immutability

The strongest form of encapsulation is an immutable class — one whose state cannot change after construction. Every field is final, there are no setters, and any mutable objects stored as fields are defensively copied.

Immutable objects are inherently thread-safe. Multiple threads can read them simultaneously without synchronisation. They eliminate an entire class of bugs where shared state is modified unexpectedly.

Java

// File: Money.java

import java.util.Objects;

public final class Money {

    // final — cannot be reassigned after construction
    private final double amount;
    private final String currency;

    public Money(double amount, String currency) {
        if (amount < 0) {
            throw new IllegalArgumentException("Amount cannot be negative: " + amount);
        }
        if (currency == null || currency.isBlank()) {
            throw new IllegalArgumentException("Currency is required.");
        }
        this.amount   = amount;
        this.currency = currency.toUpperCase().trim();
    }

    public double getAmount()   { return amount; }
    public String getCurrency() { return currency; }

    // Operations return new Money objects — the original is never modified
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException(
                    "Cannot add different currencies: " + this.currency
                    + " and " + other.currency);
        }
        return new Money(this.amount + other.amount, this.currency);
    }

    public Money subtract(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException("Cannot subtract different currencies.");
        }
        if (other.amount > this.amount) {
            throw new IllegalArgumentException("Insufficient funds.");
        }
        return new Money(this.amount - other.amount, this.currency);
    }

    public Money applyDiscount(double discountPercent) {
        if (discountPercent < 0 || discountPercent > 100) {
            throw new IllegalArgumentException("Discount must be 0-100%.");
        }
        return new Money(this.amount * (1 - discountPercent / 100.0), this.currency);
    }

    @Override
    public String toString() {
        return currency + " " + String.format("%.2f", amount);
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (!(obj instanceof Money other)) return false;
        return Double.compare(this.amount, other.amount) == 0
                && this.currency.equals(other.currency);
    }

    @Override
    public int hashCode() {
        return Objects.hash(amount, currency);
    }
}

Java

// File: ImmutableDemo.java

public class ImmutableDemo {

    public static void main(String[] args) {

        Money price    = new Money(1499.0, "INR");
        Money discount = price.applyDiscount(10);
        Money delivery = new Money(49.0, "INR");
        Money total    = discount.add(delivery);

        System.out.println("Original price : " + price);
        System.out.println("After 10% disc : " + discount);
        System.out.println("Delivery fee   : " + delivery);
        System.out.println("Total payable  : " + total);

        // price is still the original — immutability guarantee
        System.out.println("\nOriginal unchanged: " + price);
    }
}

Output:
Original price : INR 1499.00
After 10% disc : INR 1349.10
Delivery fee   : INR 49.00
Total payable  : INR 1398.10

Original unchanged: INR 1499.00

applyDiscount() and add() return new Money objects — the original price is never modified. You can pass a Money object to any method, any thread, anywhere without fear that it will be changed. This is why Java's String, Integer, LocalDate, and BigDecimal are all immutable — the safety guarantees justify the design cost.

Defensive Copying

When an encapsulated class holds a reference to a mutable object — a List, Date, or a custom class with setters — returning that reference directly allows callers to modify the internal state from outside, bypassing encapsulation.

Defensive copying creates a copy of the mutable object on the way in (constructor/setter) and on the way out (getter), so the caller never holds a direct reference to the internal object.

Java

// File: CourseEnrollment.java

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class CourseEnrollment {

    private final String studentId;
    private final String courseCode;
    // Internal list — must not be exposed directly
    private final List<String> completedModules;

    public CourseEnrollment(String studentId, String courseCode,
                            List<String> initialModules) {
        this.studentId  = studentId;
        this.courseCode = courseCode;
        // Defensive copy on the way IN — caller's list changes don't affect us
        this.completedModules = new ArrayList<>(initialModules);
    }

    public String getStudentId()  { return studentId; }
    public String getCourseCode() { return courseCode; }

    // Defensive copy on the way OUT — caller cannot modify our internal list
    public List<String> getCompletedModules() {
        return Collections.unmodifiableList(completedModules);
    }

    public void completeModule(String moduleName) {
        if (moduleName == null || moduleName.isBlank()) {
            throw new IllegalArgumentException("Module name cannot be blank.");
        }
        if (completedModules.contains(moduleName)) {
            throw new IllegalStateException("Module already completed: " + moduleName);
        }
        completedModules.add(moduleName);
    }

    public int getCompletedCount() { return completedModules.size(); }

    public String getSummary() {
        return studentId + " | " + courseCode
                + " | Completed: " + completedModules.size() + " modules";
    }
}

Java

// File: DefensiveCopyDemo.java

import java.util.ArrayList;
import java.util.List;

public class DefensiveCopyDemo {

    public static void main(String[] args) {

        List<String> startingModules = new ArrayList<>();
        startingModules.add("Module 1: Basics");
        startingModules.add("Module 2: OOP");

        CourseEnrollment enrollment = new CourseEnrollment(
                "STU-001", "JAVA-101", startingModules
        );

        System.out.println(enrollment.getSummary());

        // Modifying the original list DOES NOT affect the enrollment
        startingModules.add("Hacked Module"); // caller tries to inject a module
        System.out.println("After caller modifies original list:");
        System.out.println(enrollment.getSummary()); // count stays at 2

        // Caller cannot modify the returned list either
        List<String> returnedModules = enrollment.getCompletedModules();
        try {
            returnedModules.add("Another Hack"); // throws UnsupportedOperationException
        } catch (UnsupportedOperationException ex) {
            System.out.println("Cannot modify returned list: " + ex.getClass().getSimpleName());
        }

        // Only through the proper method is state change allowed
        enrollment.completeModule("Module 3: Collections");
        System.out.println("\n" + enrollment.getSummary());
        System.out.println("Modules: " + enrollment.getCompletedModules());
    }
}

Output:
STU-001 | JAVA-101 | Completed: 2 modules
After caller modifies original list:
STU-001 | JAVA-101 | Completed: 2 modules
Cannot modify returned list: UnsupportedOperationException

STU-001 | JAVA-101 | Completed: 3 modules
Modules: [Module 1: Basics, Module 2: OOP, Module 3: Collections]

Without defensive copying, startingModules.add("Hacked Module") would silently add a module to the enrollment. The caller's reference and the internal list would be the same object. This is a subtle but real encapsulation breach — the internal state can be changed from outside without going through any of the class's validation logic.

Encapsulation vs Abstraction

These two pillars are closely related and frequently confused in interviews. Understanding the precise difference is what interviewers check.

Aspect	Encapsulation	Abstraction
Core idea	Hiding data and implementation details	Hiding complexity by showing only essential behaviour
Focus	How state is protected inside a class	What interface is presented to the outside
Implemented using	`private` fields, getters, setters	Abstract classes, interfaces
Answers the question	"How is the data protected?"	"What can the object do?"
Level	Class-level data protection	System-level design principle
Example	`private double balance` with `deposit()` and `withdraw()`	`PaymentGateway` interface hiding Razorpay vs PayU implementation
Runtime behaviour	Enforced by access modifiers at compile time	Enforced through polymorphism at runtime

The practical distinction: Encapsulation is about protecting the contents of a class. Abstraction is about simplifying the interface of a system. A class can be well-encapsulated (private fields, controlled access) while still exposing many methods — encapsulation does not hide what the object does, only what it contains. Abstraction hides what the object does and only shows that it can do something.

Getter vs Setter — Design Considerations

Aspect	Getter	Setter
Purpose	Read a field value	Write a field value with validation
Returns	The field value (or a copy for mutable types)	`void` (or the object for chaining)
Validation	Rarely — just returns	Essential — validates before setting
Required	Only when callers genuinely need to read it	Only when callers are allowed to change it
Not every field needs one	Yes — provide only what is necessary	Yes — fewer setters = stronger encapsulation
Immutable class	Getters only — no setters	No setters — values set only in constructor

Not every private field needs both a getter and a setter. A field that is set in the constructor and never changes needs a getter but no setter. A field that is purely internal bookkeeping (a timestamp, a sequence counter) may not need either. Every getter and setter you add is an API commitment — add only what callers genuinely need.

Mutable vs Immutable Classes

Aspect	Mutable Class	Immutable Class
Fields	Can change after construction	Cannot change — `final`
Setters	Present	None
Thread safety	Requires synchronisation	Inherently thread-safe
Defensive copy on return	Required for mutable fields	Not needed — fields cannot change
Equality	May change over time	Stable — safe to use in `HashMap` keys
Example	`UserProfile` with setters	`Money`, `String`, `LocalDate`
Operations	Modify state in place	Return new objects
Caching	Risky — cached value may go stale	Safe — value never changes

Real-World Example — Delivery Slot Booking System

The Business Problem

You are building the delivery slot reservation system for a quick-commerce platform — similar to what Swiggy Instamart or Blinkit uses for its scheduled delivery feature. Each slot has a capacity limit. Once booked to capacity, it must reject further bookings. The slot's time window and capacity cannot change after creation. Booking and cancellation must go through controlled methods. Internal booking state must not be directly accessible or modifiable.

Implementation

Java

// File: DeliverySlotConfig.java

public final class DeliverySlotConfig {

    public static final int DEFAULT_SLOT_CAPACITY = 50;
    public static final int MIN_ADVANCE_BOOKING_HRS = 1;

    private DeliverySlotConfig() {}
}

Java

// File: DeliverySlot.java

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class DeliverySlot {

    // Immutable identity fields — set once, never changed
    private final String        slotId;
    private final LocalDateTime slotStart;
    private final LocalDateTime slotEnd;
    private final int           capacity;

    // Mutable state — controlled through methods only
    private int          confirmedBookings;
    private final List<String> bookedOrderIds;

    public DeliverySlot(String slotId, LocalDateTime slotStart,
                        LocalDateTime slotEnd, int capacity) {
        if (slotEnd.isBefore(slotStart)) {
            throw new IllegalArgumentException("Slot end must be after start.");
        }
        if (capacity <= 0) {
            throw new IllegalArgumentException("Capacity must be positive.");
        }
        this.slotId            = slotId;
        this.slotStart         = slotStart;
        this.slotEnd           = slotEnd;
        this.capacity          = capacity;
        this.confirmedBookings = 0;
        this.bookedOrderIds    = new ArrayList<>();
    }

    // Getters for identity fields — always safe to expose
    public String        getSlotId()    { return slotId; }
    public LocalDateTime getSlotStart() { return slotStart; }
    public LocalDateTime getSlotEnd()   { return slotEnd; }
    public int           getCapacity()  { return capacity; }

    // Derived getters — computed from internal state
    public int  getConfirmedBookings() { return confirmedBookings; }
    public int  getAvailableSlots()    { return capacity - confirmedBookings; }
    public boolean isAvailable()       { return confirmedBookings < capacity; }

    // Defensive copy — caller cannot modify our internal list
    public List<String> getBookedOrderIds() {
        return Collections.unmodifiableList(bookedOrderIds);
    }

    // Controlled booking — validates before allowing state change
    public boolean book(String orderId) {
        if (orderId == null || orderId.isBlank()) {
            throw new IllegalArgumentException("Order ID is required.");
        }
        if (!isAvailable()) {
            return false; // slot full — booking rejected
        }
        if (bookedOrderIds.contains(orderId)) {
            throw new IllegalStateException("Order already booked in this slot: " + orderId);
        }
        bookedOrderIds.add(orderId);
        confirmedBookings++;
        return true;
    }

    // Controlled cancellation — validates before allowing state change
    public boolean cancel(String orderId) {
        boolean removed = bookedOrderIds.remove(orderId);
        if (removed) {
            confirmedBookings--;
        }
        return removed;
    }

    public String getSlotSummary() {
        DateTimeFormatter fmt = DateTimeFormatter.ofPattern("HH:mm");
        return slotId + " | " + slotStart.format(fmt)
                + "-" + slotEnd.format(fmt)
                + " | Booked: " + confirmedBookings + "/" + capacity
                + " | " + (isAvailable() ? "OPEN" : "FULL");
    }
}

Java

// File: SlotBookingDemo.java

import java.time.LocalDateTime;

public class SlotBookingDemo {

    public static void main(String[] args) {

        LocalDateTime base = LocalDateTime.now().withHour(10).withMinute(0);

        DeliverySlot morningSlot = new DeliverySlot(
                "SLOT-AM-01",
                base,
                base.plusHours(2),
                3 // small capacity for demo
        );

        System.out.println("=== Slot Booking System ===\n");
        System.out.println(morningSlot.getSlotSummary());

        // Valid bookings
        System.out.println("\nBooking ORD-001: " + morningSlot.book("ORD-001"));
        System.out.println("Booking ORD-002: " + morningSlot.book("ORD-002"));
        System.out.println("Booking ORD-003: " + morningSlot.book("ORD-003"));
        System.out.println(morningSlot.getSlotSummary());

        // Slot is full — booking rejected
        System.out.println("\nBooking ORD-004: " + morningSlot.book("ORD-004"));
        System.out.println(morningSlot.getSlotSummary());

        // Cancellation frees a slot
        System.out.println("\nCancelling ORD-002: " + morningSlot.cancel("ORD-002"));
        System.out.println(morningSlot.getSlotSummary());

        // Slot is available again — new booking accepted
        System.out.println("\nBooking ORD-005: " + morningSlot.book("ORD-005"));
        System.out.println(morningSlot.getSlotSummary());

        // Cannot modify the returned order list
        try {
            morningSlot.getBookedOrderIds().add("HACK-001");
        } catch (UnsupportedOperationException ex) {
            System.out.println("\nExternal modification blocked: "
                    + ex.getClass().getSimpleName());
        }

        System.out.println("Final bookings: " + morningSlot.getBookedOrderIds());
    }
}

Output:
=== Slot Booking System ===

SLOT-AM-01 | 10:00-12:00 | Booked: 0/3 | OPEN
Booking ORD-001: true
Booking ORD-002: true
Booking ORD-003: true
SLOT-AM-01 | 10:00-12:00 | Booked: 3/3 | FULL

Booking ORD-004: false
SLOT-AM-01 | 10:00-12:00 | Booked: 3/3 | FULL

Cancelling ORD-002: true
SLOT-AM-01 | 10:00-12:00 | Booked: 2/3 | OPEN

Booking ORD-005: true
SLOT-AM-01 | 10:00-12:00 | Booked: 3/3 | FULL

External modification blocked: UnsupportedOperationException
Final bookings: [ORD-001, ORD-003, ORD-005]

confirmedBookings and bookedOrderIds are private — no external code can directly manipulate the booking count. capacity, slotStart, and slotEnd are final — once set, they never change. The book() and cancel() methods are the only doorways through which state changes, and both enforce their own rules before touching the internal data.

Best Practices

Make all fields private by default — widen access only when justified

The discipline is to start with private for every field and widen to protected or public only when there is a specific, justified reason. Every non-private field is an API commitment — once external code depends on it, changing it becomes a breaking change. Teams following clean code conventions treat any public field as a design smell requiring justification in review.

Validate in setters, not in callers

When validation logic lives in callers rather than in setters, the same check must be duplicated everywhere the field is set. When a business rule changes — say, the minimum username length goes from 3 to 5 characters — only the setter changes. If validation is in callers, every caller must be found and updated, and one will inevitably be missed.

Return defensive copies of mutable fields

If a getter returns a direct reference to a mutable internal field — a List, Date, or custom object with setters — the caller can modify the internal state from outside. Always return Collections.unmodifiableList(internalList) or new ArrayList<>(internalList) for lists, and new copies for mutable objects. Java's String is immune to this because it is immutable.

Prefer immutable classes when objects should not change after creation

If an object's state never needs to change — monetary values, addresses, configuration entries, identifiers — make it immutable. Declare all fields final, provide no setters, and use defensive copies in the constructor for any mutable input. Immutable objects are the simplest form of encapsulation and the safest for use in multi-threaded systems.

Common Mistakes

Mistake 1 — Returning a Direct Reference to a Mutable Field

Java

import java.util.List;
import java.util.ArrayList;

public class OrderHistory {

    private final List<String> orderIds = new ArrayList<>();

    public void addOrder(String orderId) {
        orderIds.add(orderId);
    }

    // Wrong — returns direct reference, caller can modify internal state
    public List<String> getOrderIds() {
        return orderIds; // caller can call orderIds.clear() on this
    }

    // Correct — returns an unmodifiable view
    public List<String> getOrderIdsSafe() {
        return java.util.Collections.unmodifiableList(orderIds);
    }
}

A caller who receives the direct reference from getOrderIds() can call list.add(...), list.remove(...), or list.clear() — bypassing all control. The class has no idea its state has been changed.

Mistake 2 — Providing Setters for Every Field Without Thinking

Java

public class PaymentTransaction {

    private final String transactionId;
    private double       amount;
    private String       status;
    private String       gatewayResponse;

    // Wrong — why would anyone need to change the transactionId after creation?
    public void setTransactionId(String transactionId) { /* dangerous */ }

    // Wrong — amount should not change after a transaction is created
    public void setAmount(double amount) { this.amount = amount; /* no validation */ }

    // Reasonable — status legitimately changes as the transaction progresses
    public void updateStatus(String status) {
        if (status == null) throw new IllegalArgumentException("Status required.");
        this.status = status;
    }
}

Generating getters and setters for every field blindly — which many IDEs do with one click — is not encapsulation. It is the illusion of encapsulation. A setter with no validation is worse than a public field in one way: it adds code without adding protection. Every setter must earn its existence by enforcing a rule.

Mistake 3 — Performing Validation in the Caller Instead of the Class

Java

// Wrong — validation in caller, not in the class
public class Main {
    public static void main(String[] args) {
        UserProfile user = new UserProfile();
        String newEmail = "invalid";
        if (newEmail.contains("@")) { // this check belongs in UserProfile.setEmail()
            user.setEmail(newEmail);
        }
    }
}

When the rule "email must contain @" lives in the caller, every caller must know and apply the rule. A second caller that sets the email without the check creates an invalid UserProfile object. The rule belongs in the setter — once, in the class that owns the data.

Mistake 4 — Making a Class Final Without Making Fields Final

Java

// Wrong — class is final but fields are mutable
public final class ProductId {
    private String id; // not final — can be changed by a setter

    public ProductId(String id) { this.id = id; }

    public String getId()          { return id; }
    public void   setId(String id) { this.id = id; } // defeats immutability intent
}

Making a class final prevents subclassing but does not prevent mutation. For a value object like ProductId that should be immutable, the field must be final and the setter must not exist. final on the class and final on fields serve different purposes — both are needed for true immutability.

Interview Questions

Q1. What is encapsulation in Java and why is it important?

Encapsulation is the OOP principle of bundling data (fields) and the methods that operate on that data into a single class, while restricting direct access to the data from outside. Fields are declared private and access is provided through public methods that can enforce business rules. It is important because it makes the class the single authority on its own state — no external code can corrupt data by bypassing validation. It also allows the internal implementation to change without breaking callers, since they only depend on the methods, not the fields.

Q2. What is the difference between encapsulation and abstraction?

Encapsulation is about protecting data — hiding fields and controlling access through methods. It answers "how is the state protected?" Abstraction is about hiding complexity — showing only what an object does, not how it does it. It answers "what can this object do?" Encapsulation is implemented with private fields and access methods. Abstraction is implemented with interfaces and abstract classes. A class can be fully encapsulated (private fields, controlled access) while still exposing many public methods. Abstraction goes further by hiding even what the implementation class is, through interfaces and polymorphism.

Q3. What is defensive copying and when is it needed?

Defensive copying is the practice of creating copies of mutable objects on the way in (in constructors and setters) and on the way out (in getters) to prevent external code from modifying internal state through a shared reference. It is needed whenever an encapsulated class holds a reference to a mutable object — a List, Date, array, or custom class with setters. Without defensive copying, a caller who received the reference or passed the original to the constructor can modify the object's internal state from outside, bypassing all encapsulation. Java's String avoids this problem by being immutable.

Q4. What makes a Java class truly immutable?

A truly immutable class requires five conditions: all fields must be final; the class itself should be final to prevent subclasses from adding mutable state; all fields must be initialised in the constructor; there must be no setters; and for any mutable object held as a field — like a List or Date — a defensive copy must be made in the constructor and any getter must return a copy or unmodifiable view rather than the direct reference. String, Integer, BigDecimal, and LocalDate in the Java standard library all follow this pattern.

Q5. Why should you not generate getters and setters for every field?

Not every field needs external read or write access. A getter for a field is a promise to external code that the field exists and is readable — changing it later becomes a breaking change. A setter with no validation is equivalent to a public field in terms of protection but adds code without adding safety. Each getter and setter should be justified by a genuine caller need. Fields that are internal bookkeeping, fields that should be immutable after construction, and fields whose values are derived rather than stored often need no getter or setter at all.

Q6. How does encapsulation support the open-closed principle?

When a class is well-encapsulated, its internal implementation can change freely as long as the public method signatures remain the same. If balance is private and accessed only through getBalance(), deposit(), and withdraw(), the class can change how it stores balance — switching from double to BigDecimal for precision, or adding logging to every transaction — without any caller needing to change. The class is open for internal modification (extension) but closed to external change in its API. This is the open-closed principle: callers depend on behaviour, not on implementation.

FAQs

What is encapsulation in Java in simple terms?

Encapsulation is hiding the internal data of an object and only allowing access through controlled methods. Fields are private so no outside code can directly read or change them. Methods are public and contain the rules about what changes are allowed. The class is in complete control of its own state.

What is the difference between encapsulation and data hiding?

Data hiding is a part of encapsulation, not the whole of it. Data hiding means making fields private so external code cannot access them directly. Encapsulation is broader — it also means bundling the data with the behaviour that operates on it, and providing controlled access through methods that enforce business rules. Data hiding is the mechanism; encapsulation is the design principle.

Is a class with all public fields still encapsulated?

No. A class with public fields has no encapsulation — any code anywhere can set any field to any value, with no validation and no control. The class cannot enforce any rules about its own state. Encapsulation specifically requires private fields with controlled access through methods.

Can encapsulation be achieved without getters and setters?

Yes. Encapsulation is about controlled access — not specifically about getters and setters. An immutable class achieves maximum encapsulation with only a constructor and getter methods, and no setters at all. Encapsulation can also be achieved by exposing behaviour methods (like deposit() and withdraw()) rather than raw getters and setters, which is often a cleaner design.

What is the benefit of encapsulation in multi-threaded programs?

In multi-threaded programs, encapsulation allows synchronisation to be centralised inside the class. When all access to shared state goes through controlled methods, synchronisation can be added to those methods — locking is the class's responsibility, not the caller's. Immutable classes, which are the strongest form of encapsulation, are inherently thread-safe and require no synchronisation at all.

Does encapsulation affect performance?

The method call overhead from getters and setters is effectively zero for modern JVMs — the JIT compiler almost always inlines simple accessor methods. Immutable objects may have a slight overhead from creating new objects for every operation, but this is offset by the elimination of synchronisation costs in multi-threaded scenarios. Encapsulation should never be sacrificed for performance without profiling evidence that it is actually the bottleneck.

Summary

Encapsulation is the principle that a class owns and controls its own state. Private fields are the mechanism; validated getters and setters are the controlled access points; immutable classes with final fields are the strongest form. Defensive copying protects internal mutable objects from external modification through shared references.

The discipline of encapsulation compounds over a codebase's lifetime. When business rules live inside the class that owns the data, changing a rule requires updating one place. When internal storage changes, callers do not notice. When bugs appear in state management, the investigation is confined to one class. This is the practical payoff that makes encapsulation worth every line of extra code.

For interviews, be ready to explain the difference between encapsulation and abstraction precisely, demonstrate defensive copying with a mutable field like a List, and describe what makes a class truly immutable with all five conditions. These points consistently appear across both service-based recall questions and product-based design discussions.

What to Read Next

Topic	Link
How abstraction hides complexity through interfaces and abstract classes	Abstraction →
How access modifiers implement the visibility rules that encapsulation depends on	Access Modifiers →
How immutable class design combines encapsulation with final fields	Immutable Class →
How inheritance interacts with encapsulated private fields in parent classes	Inheritance →
How constructors enforce valid initial state as the first encapsulation line	Constructors →

←

Previousstatic Keyword

NextInheritance

→