Why Use Getters and Setters in Java? Accessors vs Public Fields

By the end of this page, you will understand why Java developers often prefer private fields with getters and setters over public fields, even when the methods appear to do nothing extra. You will learn the core idea of encapsulation, how it protects your code from future changes, when public fields are acceptable, and how this choice affects maintainability in real projects.

In Java, the main idea behind getters and setters is encapsulation.

Encapsulation means an object should control access to its own internal state. Instead of letting other code directly read or write a field, the object exposes methods that define how that value is accessed.

At first, this may seem unnecessary when a getter just returns the field and a setter just assigns it:

private String foo;

public String getFoo() {
    return foo;
}

public void setFoo(String foo) {
    this.foo = foo;
}

That looks equivalent to:

public String foo;

But they are not equivalent in terms of design.

Why it matters

If you expose a public field:

• Any code can read it directly
• Any code can change it directly
• You cannot later add validation without changing all calling code
• You cannot control when it is read or written
• You tightly couple other code to your internal representation

If you expose methods instead:

• You can later add validation
• You can make the property read-only or write-only
• You can log access or trigger side effects later
• You can change internal storage without changing external code
• You preserve a stable public API

Think of a class like a building.

• A public field is like leaving the storage room door open so anyone can walk in and move things around.
• A getter is like a service window where people can ask to see something.
• A setter is like a controlled drop-off desk where items are accepted according to rules.

At first, the service window may feel unnecessary because the worker is just handing you the item with no questions asked. But later, the building can add rules:

• only allow certain items
• record who accessed them
• reject invalid deliveries
• move the storage room without changing the public-facing window

The window gives flexibility. The open door does not.

Basic syntax

Public field

public class User {
    public String name;
}

Usage:

User user = new User();
user.name = "Ava";
System.out.println(user.name);

Private field with getter and setter

public class User {
    private String name;

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

Usage:

User user = new User();
user.setName("Ava");
System.out.println(user.getName());

Consider this class:

public class BankAccount {
    private double balance;

    public void setBalance(double balance) {
        if (balance < 0) {
            throw new IllegalArgumentException("Balance cannot be negative");
        }
        this.balance = balance;
    }

    public double getBalance() {
        return balance;
    }
}

And this code:

BankAccount account = new BankAccount();
account.setBalance(100.0);
System.out.println(account.getBalance());

What happens step by step

1. BankAccount account = new BankAccount();

   • A new BankAccount object is created.

Getters and setters are commonly used when a class needs to protect or shape its data.

Common real-world scenarios

User input validation

user.setEmail("TEST@EXAMPLE.COM");

The setter can:

• reject null
• trim whitespace
• normalize case
• enforce format rules

Domain rules

In a payroll system:

employee.setSalary(50000);

The setter can ensure salary is not negative.

Read-only identifiers

A database entity may have an ID that should be readable but not changed freely:

order.getId();

No public setter is provided.

Derived or computed values

A getter can calculate a value instead of returning a stored field:

invoice.getTotal();

This may sum line items internally.

Lazy loading or formatting

A getter may load data only when needed or return a cleaned-up representation.

Framework compatibility

Many Java libraries and frameworks expect JavaBean-style accessors such as:

In real projects, developers use accessors as part of a broader design strategy.

Common patterns

Guard clauses in setters

Setters often validate early:

public void setAge(int age) {
    if (age < 0) {
        throw new IllegalArgumentException("Age cannot be negative");
    }
    this.age = age;
}

This keeps invalid state out of the object.

Early returns in getters

A getter may return a fallback value:

public String getDisplayName() {
    if (nickname != null && !nickname.isBlank()) {
        return nickname;
    }
    return fullName;
}

Defensive copying

If a field is mutable, a getter may return a copy instead of the original:

public List<String> getTags() {
    return new <>(tags);
}

1. Creating getters and setters for everything without thinking

Some beginners expose every field with both getter and setter automatically. That can weaken design.

For example, this class allows uncontrolled changes:

public class Account {
    private double balance;

    public double getBalance() {
        return balance;
    }

    public void setBalance(double balance) {
        this.balance = balance;
    }
}

A better design may be:

public class Account {
    private double balance;

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        if (amount <= 0) {
            throw new ();
        }
        balance += amount;
    }
}

Public fields vs getters/setters

Getter only vs getter and setter

Quick reference

Public field

public String name;

• Simple
• No validation
• No control over reads/writes
• Harder to change later without breaking callers

Private field with accessor methods

private String name;

public String getName() {
    return name;
}

public void setName(String name) {
    this.name = name;
}

• Supports encapsulation
• Lets you add validation later
• Keeps internal representation hidden
• Works well with many Java frameworks

Common rules

• Use private fields by default
• Add a getter if outside code needs to read the value
• Add a setter only if outside code should be allowed to change it
• Prefer meaningful methods like deposit() or renameTo() when behavior matters
• Avoid exposing mutable internal objects directly

Naming conventions

• getName() for most fields

Why are getters and setters better than public fields in Java?

They support encapsulation. You can control access, validate input, and change implementation later without breaking calling code.

If a getter and setter only pass through the value, are they still useful?

Yes. Their main value is preserving flexibility for future changes and hiding internal representation.

Should every private field have a getter and setter?

No. Only expose what outside code actually needs. Some fields should be read-only, and some should stay completely internal.

Are public fields ever acceptable in Java?

Yes, sometimes. Common examples are public static final constants and very simple internal data holders.

Why not just make everything public for less boilerplate?

Because it makes your code harder to protect, validate, and evolve. Saving a few lines now can create larger maintenance problems later.

Is a setter always the right way to modify object state?

No. If the change has business meaning, a behavior method like deposit(), activate(), or markAsPaid() is often better.

Do Java frameworks prefer getters and setters?

Many do. JavaBean-style methods are commonly used by serializers, ORMs, UI tools, and dependency injection frameworks.

Encapsulation

The core idea behind hiding fields and exposing controlled access.

Access modifiers

Understanding public, private, and protected helps explain why field visibility matters.

Immutability

Many classes expose getters but no setters to keep objects unchangeable after creation.

JavaBeans conventions

Standard getter/setter naming is widely used by Java tools and frameworks.

Constructors

Some values are better set once during object creation instead of through setters.

Validation

Setters often validate data before storing it.

Defensive copying

Useful when getters return mutable collections or objects.

Object-oriented design

Choosing between fields, accessors, and behavior methods is part of modeling objects well.