Purpose of Accessors - Getters And Setters When And Why | OneNoughtOne

0/246

System Design (LLD)Getters and Setters — When and Why

Getters and Setters — When and Why

LevelBeginner

Duration60 mins

TopicGetters and Setters — When and Why

1 / 4

Purpose of Accessors

The Gateway to Object State

In object-oriented programming, objects are not merely data containers—they are living entities that combine state (data) with behavior (methods). But this raises a fundamental architectural question: How should the outside world interact with an object's internal state?

The answer lies in accessors—specialized methods that provide controlled access to an object's private fields. Commonly known as getters and setters, these methods are far more than simple conveniences. They represent a deliberate design decision about how your objects communicate with the rest of the system.

This page explores the deep purpose behind accessors, why they are essential to proper encapsulation, and how understanding their true role transforms the way you design classes.

What You Will Learn

By the end of this page, you will understand why accessors exist beyond simple syntax, how they enable encapsulation, and the difference between accessors as implementation choice versus accessors as design intent. You'll see how proper use of accessors protects object integrity and enables evolution of internal representations without breaking external code.

The Problem Accessors Solve

To understand why accessors exist, we must first understand the problem they solve. Consider a world without them—a world where all object fields are public and directly accessible.

The Direct Access Problem:

Imagine a BankAccount class with a public balance field. Any code in the system can directly read or write this field:

DirectAccessProblem.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Dangerous: Public field allows uncontrolled access
class BankAccount {
    public double balance;  // Anyone can modify this!
    public String accountNumber;
    
    public BankAccount(String accountNumber, double initialBalance) {
        this.accountNumber = accountNumber;
        this.balance = initialBalance;
    }
}
 
// Anywhere in the codebase...
BankAccount account = new BankAccount("12345", 1000.0);
 
// Direct manipulation - no validation!
account.balance = -500.0;  // Negative balance? Allowed!
account.balance = Double.MAX_VALUE;  // Infinite money? Sure!
 
// External code depends on internal structure
double currentBalance = account.balance * 0.02;  // Tight coupling

This approach creates multiple severe problems:

1. No Validation Possible

With direct field access, there is no place to insert validation logic. If business rules require that balances never go negative, or that deposits must be audited, there is no mechanism to enforce these constraints. Any code can violate invariants at will.

2. No Encapsulation of Internal Representation

When external code directly accesses balance, it becomes coupled to the specific representation of balance as a double. If you later need to change this to a BigDecimal for precision, or to a Money value object, every line of code that accessed account.balance must change.

3. No Opportunity for Side Effects

Real-world operations often have side effects: logging, caching, notification, synchronization. With direct field access, there is no place to insert these behaviors. Every access is raw and unmediated.

4. No Debugging or Monitoring

When something goes wrong—a balance mysteriously changes—there is no centralized point to set a breakpoint or add logging. The modification could have happened from anywhere in the codebase.

5. Immutability is Impossible

If the field is public, it can be modified. There is no way to create a read-only view of the object's state. Immutability, one of the most powerful tools for building reliable software, becomes unachievable.

The Core Insight

Public fields are not just 'bad style'—they fundamentally undermine the ability to maintain invariants, evolve implementations, and reason about code. Accessors exist to restore control over how objects interact with the world.

What Accessors Actually Are

Accessors are methods that provide controlled access to an object's internal state. They come in two primary forms:

Getters (Accessor Methods)

A getter retrieves the value of a private field, optionally transforming, computing, or validating before returning. The naming convention is getFieldName() (or isFieldName() for booleans in Java) or simply fieldName in languages that support property syntax.

Setters (Mutator Methods)

A setter modifies the value of a private field, with the opportunity to validate input, enforce invariants, trigger side effects, or reject invalid values. The naming convention is setFieldName(value).

Let's see how accessors transform our problematic BankAccount:

BankAccountWithAccessors.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
class BankAccount {
    // Private field - inaccessible from outside
    private double balance;
    private final String accountNumber;
    private final List<Transaction> transactionHistory;
    
    public BankAccount(String accountNumber, double initialBalance) {
        if (initialBalance < 0) {
            throw new IllegalArgumentException(
                "Initial balance cannot be negative"
            );
        }
        this.accountNumber = accountNumber;
        this.balance = initialBalance;
        this.transactionHistory = new ArrayList<>();
    }
    
    // Getter: controlled read access
    public double getBalance() {
        return balance;
    }
    
    // Getter for read-only field
    public String getAccountNumber() {
        return accountNumber;
    }
    
    // Getter returning defensive copy
    public List<Transaction> getTransactionHistory() {
        return Collections.unmodifiableList(transactionHistory);
    }
    
    // Setter with validation and side effects
    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Deposit amount must be positive"
            );
        }
        this.balance += amount;
        this.transactionHistory.add(
            new Transaction(TransactionType.DEPOSIT, amount)
        );
    }
    
    // Setter with complex business rules
    public void withdraw(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Withdrawal amount must be positive"
            );
        }
        if (amount > balance) {
            throw new InsufficientFundsException(
                "Cannot withdraw " + amount + 
                " with balance " + balance
            );
        }
        this.balance -= amount;
        this.transactionHistory.add(
            new Transaction(TransactionType.WITHDRAWAL, amount)
        );
    }
}

Notice several critical differences from the public field approach:

1. The balance field is private — No external code can directly modify it. All modifications must go through the defined methods.

2. No setBalance() method exists — This is intentional! Balance should only change through deposit() and withdraw(), which encode the business operations. Direct setting of balance is not a valid operation.

3. Getters return controlled views — getTransactionHistory() returns an unmodifiable list. External code can read the history but cannot tamper with it.

4. Business rules are centralized — All validation happens in one place. If rules change, only these methods need modification.

5. Operations are named for their intent — Instead of generic setBalance(), we have deposit() and withdraw() which express domain semantics.

Accessors as Contracts

Think of accessors not as 'field wrappers' but as contracts between your object and the outside world. A getter promises to provide certain information. A setter (or domain method) promises to accept certain modifications under certain conditions. The internal implementation can change as long as the contract is honored.

The Four Purposes of Accessors

Accessors serve four fundamental purposes in object-oriented design. Understanding each purpose helps you use accessors intentionally rather than habitually.

Purpose 1: Encapsulation of Representation

•Hide internal data structures — The outside world doesn't need to know if you store data in an array, list, or database
•Enable representation changes — Switch from double to BigDecimal without breaking clients
•Support computed properties — A getter can calculate values on demand rather than storing them
•Allow lazy initialization — Create expensive resources only when first accessed

RepresentationEncapsulation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class Circle {
    private double radius;
    
    // Stored field - simple getter
    public double getRadius() {
        return radius;
    }
    
    // Computed property - no need to store area
    public double getArea() {
        return Math.PI * radius * radius;
    }
    
    // Computed property - no need to store circumference
    public double getCircumference() {
        return 2 * Math.PI * radius;
    }
    
    // Future: could cache area if called frequently
    // External code wouldn't need to change
}
 
// Client code doesn't know (or care) which values
// are stored vs computed
Circle c = new Circle(5.0);
System.out.println(c.getRadius());        // Stored
System.out.println(c.getArea());          // Computed
System.out.println(c.getCircumference()); // Computed

Purpose 2: Validation and Invariant Enforcement

•Validate input values — Reject invalid data before it corrupts object state
•Enforce business rules — Ensure constraints like 'balance >= 0' are never violated
•Maintain consistency — When changing one field requires updating others, the setter handles coordination
•Throw meaningful exceptions — Provide clear error messages when validation fails

ValidationExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
class Person {
    private String email;
    private int age;
    private LocalDate birthDate;
    
    public void setEmail(String email) {
        // Validation: must be valid email format
        if (email == null || !email.matches("^[\\w.]+@[\\w.]+$")) {
            throw new IllegalArgumentException(
                "Invalid email format: " + email
            );
        }
        this.email = email.toLowerCase(); // Normalize
    }
    
    public void setAge(int age) {
        // Validation: must be reasonable age
        if (age < 0 || age > 150) {
            throw new IllegalArgumentException(
                "Age must be between 0 and 150: " + age
            );
        }
        this.age = age;
        // Invariant maintenance: update birth date estimate
        this.birthDate = LocalDate.now().minusYears(age);
    }
    
    public void setBirthDate(LocalDate birthDate) {
        Objects.requireNonNull(birthDate, "Birth date cannot be null");
        if (birthDate.isAfter(LocalDate.now())) {
            throw new IllegalArgumentException(
                "Birth date cannot be in the future"
            );
        }
        this.birthDate = birthDate;
        // Invariant maintenance: update age
        this.age = Period.between(birthDate, LocalDate.now()).getYears();
    }
}

Purpose 3: Side Effects and Notification

•Logging and auditing — Record who changed what and when
•Observer notification — Inform listeners when state changes
•Cache invalidation — Clear cached computed values when underlying data changes
•Persistence triggers — Mark object as dirty for later database synchronization

SideEffectsExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class Observable {
    private List<PropertyChangeListener> listeners = new ArrayList<>();
    private String status;
    
    public void setStatus(String newStatus) {
        String oldStatus = this.status;
        this.status = newStatus;
        
        // Side effect 1: Logging
        logger.info("Status changed from {} to {}", oldStatus, newStatus);
        
        // Side effect 2: Observer notification
        PropertyChangeEvent event = new PropertyChangeEvent(
            this, "status", oldStatus, newStatus
        );
        for (PropertyChangeListener listener : listeners) {
            listener.propertyChange(event);
        }
        
        // Side effect 3: Mark for persistence
        this.dirty = true;
    }
    
    public void addPropertyChangeListener(PropertyChangeListener l) {
        listeners.add(l);
    }
}

Purpose 4: Thread Safety and Synchronization

•Synchronized access — Prevent race conditions in multithreaded environments
•Atomic operations — Ensure complex reads or writes complete without interference
•Read-write locking — Allow multiple readers but exclusive writers
•Copy-on-write semantics — Return copies to prevent concurrent modification

ThreadSafetyExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class ThreadSafeCounter {
    private final AtomicInteger count = new AtomicInteger(0);
    private final ReentrantReadWriteLock lock = 
        new ReentrantReadWriteLock();
    private List<String> events = new ArrayList<>();
    
    // Thread-safe getter using atomic
    public int getCount() {
        return count.get();
    }
    
    // Thread-safe increment
    public void increment() {
        count.incrementAndGet();
    }
    
    // Thread-safe read with read lock
    public List<String> getEvents() {
        lock.readLock().lock();
        try {
            return new ArrayList<>(events); // Defensive copy
        } finally {
            lock.readLock().unlock();
        }
    }
    
    // Thread-safe write with write lock
    public void addEvent(String event) {
        lock.writeLock().lock();
        try {
            events.add(event);
        } finally {
            lock.writeLock().unlock();
        }
    }
}

Accessors vs Public Fields: A Deeper Analysis

Some developers argue that simple value objects don't need accessors—public fields are simpler. This argument deserves careful examination.

Comparing Public Fields and Accessors
Aspect	Public Fields	Accessors
Validation	❌ Impossible	✅ Can validate every change
Representation change	❌ Breaks all clients	✅ Internal only, clients unaffected
Computed values	❌ Must be stored	✅ Can compute on demand
Side effects	❌ No mechanism	✅ Can add logging, notification, etc.
Thread safety	❌ No control	✅ Can add synchronization
Read-only access	❌ Impossible	✅ Provide getter without setter
Debugging	❌ No breakpoint location	✅ Single place to intercept
Lazy initialization	❌ Not possible	✅ Initialize on first access
Binary compatibility	❌ Field changes break compiled code	✅ Method signatures stable
API evolution	❌ Locked to initial design	✅ Implementation can evolve

The Binary Compatibility Problem:

In compiled languages like Java, public fields become part of the binary interface. If you compile code against a class with a public field, and later that class changes the field's type or removes it, the compiled code breaks even if source-level compatibility exists.

With accessors, you maintain binary compatibility because method signatures are stable. You can completely rewrite the internal implementation, and code compiled against older versions continues to work.

When Public Fields Are Acceptable:

There are limited cases where public fields are reasonable:

Private nested classes — When a class is only used internally by its outer class, the outer class already controls all access.
Package-private classes — Classes with default (package) visibility are internal implementation details.
Truly immutable simple data carriers — In modern Java (with records) or Kotlin (with data classes), compiler-generated accessors provide the benefits without manual boilerplate.
Constants — public static final fields are effectively constants and are safe.

For any public API, accessors are the only defensible choice.

A Common Misconception

"But getters and setters are just extra typing for the same thing." This is false. A public field and a getter/setter pair are fundamentally different contracts. The field says: 'Here is my implementation, use it directly.' The accessor says: 'Here is a service I provide, how I provide it may change.'

The Method, Not the Field

A crucial insight for understanding accessors is that they are methods first, not field wrappers. This distinction changes how you think about them.

Consider the difference between these two conceptual models:

Wrong: Field-First Thinking

•I have a field balance
•I need to expose it, so I add getBalance()
•I need to modify it, so I add setBalance()
•The accessor is a wrapper around the field
•Result: Accessors mirror internal structure

Right: Interface-First Thinking

•What does a BankAccount need to tell the world?
•It should report its current balance → getBalance()
•What operations can change this?
•Deposits and withdrawals → domain methods
•Result: Interface reflects capabilities, not structure

The Interface-First Approach:

When designing accessors, start by asking: What does this object need to communicate to the outside world? The answer determines your getters.

Then ask: What operations can legitimately modify this object's state? The answer determines your mutator methods—which may or may not be simple setters.

This approach has profound implications:

1. Not every field needs a getter. Internal implementation details should remain hidden.

2. Not every field needs a setter. Many fields should be set-once at construction time.

3. Mutators should be domain operations. Instead of setBalance(), provide deposit() and withdraw().

4. Getters can return computed values. The absence of a corresponding field is an implementation detail.

5. The public interface is stable. Internal changes don't ripple to clients.

InterfaceFirstDesign.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Interface-First: Define what the object should do
interface ShoppingCart {
    // What can this object tell us?
    int getItemCount();
    Money getSubtotal();
    Money getTax();
    Money getTotal();
    List<CartItem> getItems();
    
    // What operations can modify it?
    void addItem(Product product, int quantity);
    void removeItem(String productId);
    void updateQuantity(String productId, int newQuantity);
    void applyCoupon(String couponCode);
    void clear();
    
    // Note: No setSubtotal(), setTax(), setTotal()
    // These are computed values, not settable state
}
 
// Implementation can change independently
class DefaultShoppingCart implements ShoppingCart {
    private Map<String, CartItem> items = new HashMap<>();
    private List<Coupon> appliedCoupons = new ArrayList<>();
    private TaxCalculator taxCalculator;
    
    @Override
    public Money getTotal() {
        // Computed dynamically
        return getSubtotal()
            .add(getTax())
            .subtract(getDiscounts());
    }
    
    @Override
    public void addItem(Product product, int quantity) {
        // Complex logic hidden behind simple interface
        String key = product.getId();
        if (items.containsKey(key)) {
            items.get(key).incrementQuantity(quantity);
        } else {
            items.put(key, new CartItem(product, quantity));
        }
        invalidateCache(); // Internal detail
    }
    
    // ... other methods
}

Properties in Modern Languages

Modern languages have evolved to make accessors more elegant while preserving their power. Understanding these mechanisms helps you write cleaner code while maintaining encapsulation.

JavaAccessors.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// Traditional Java - verbose but explicit
class Person {
    private String name;
    private int age;
    
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    
    public int getAge() { return age; }
    public void setAge(int age) {
        if (age < 0) throw new IllegalArgumentException();
        this.age = age;
    }
}
 
// Java 14+ Records - immutable with built-in accessors
record Point(int x, int y) {
    // Automatically has x() and y() accessors
    // No setters - records are immutable
    
    // Can add custom validation in compact constructor
    public Point {
        if (x < 0 || y < 0) {
            throw new IllegalArgumentException("Coordinates must be non-negative");
        }
    }
}

Syntax vs Semantics

Regardless of syntax—whether you write person.age (Python, C#, Kotlin) or person.getAge() (Java)—the underlying semantics are the same: a method is invoked, providing the opportunity for validation, computation, and side effects. Modern syntax makes this more pleasant but doesn't change the fundamental nature of accessors.

Common Mistakes with Accessors

Understanding the purpose of accessors helps avoid common misuses. Here are patterns to recognize and avoid:

Anti-Pattern 1: Mechanical Getter/Setter Generation

•Automatically generating getters/setters for every field defeats encapsulation
•If every field has both getter and setter, you've just created public fields with extra steps
•Each accessor should be a deliberate design decision, not a reflex
•Ask: Does external code really need to read/modify this field?

Anti-Pattern 2: Returning Mutable Internal State

•Returning mutable collections or objects breaks encapsulation
•External code can modify internal state without going through setters
•Solution: Return defensive copies or unmodifiable views
•Example: return Collections.unmodifiableList(items);

Anti-Pattern 3: Setters that Break Invariants

•Setters for interdependent fields can leave objects in inconsistent states
•Example: Separate setStartDate() and setEndDate() where start must be before end
•Solution: Provide methods that update related fields atomically
•Example: setDateRange(start, end) that validates the relationship

Anti-Pattern 4: Getters with Side Effects

•Getters should be idempotent—calling twice should have no additional effect
•A getter that modifies state (except for lazy init) violates caller expectations
•Side effects in getters make code unpredictable and hard to debug
•Rule: Getters read, mutators write. Keep responsibilities separate.

AntiPatternExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// ❌ BAD: Returning mutable internal state
class Order {
    private List<Item> items = new ArrayList<>();
    
    public List<Item> getItems() {
        return items;  // External code can modify this!
    }
}
 
// External code can break encapsulation:
order.getItems().clear();  // Deletes all items!
order.getItems().add(null);  // Adds invalid data!
 
 
// ✅ GOOD: Return unmodifiable view
class Order {
    private List<Item> items = new ArrayList<>();
    
    public List<Item> getItems() {
        return Collections.unmodifiableList(items);
    }
    
    // Modifications go through domain methods
    public void addItem(Item item) {
        Objects.requireNonNull(item, "Item cannot be null");
        items.add(item);
    }
}
 
 
// ❌ BAD: Getter with side effects
class ReportGenerator {
    private int callCount = 0;
    
    public Report getReport() {
        callCount++;  // Side effect in getter!
        return generateReport();
    }
}
 
// ✅ GOOD: Separate concerns
class ReportGenerator {
    private int generationCount = 0;
    
    public Report generateReport() {  // Named as action
        generationCount++;
        return doGenerateReport();
    }
    
    public int getGenerationCount() {  // Pure getter
        return generationCount;
    }
}

Summary: The Purpose of Accessors

We've established a comprehensive understanding of why accessors exist and what purposes they serve. Here are the key takeaways:

Key Takeaways

•Accessors are controlled gateways — They mediate all access between internal state and external code, providing a point of control.
•They serve four purposes — Encapsulation of representation, validation and invariant enforcement, side effects and notification, and thread safety.
•They are methods, not field wrappers — Think interface-first: what does this object need to communicate and what operations are valid?
•Not every field needs accessors — Generate accessors deliberately, not mechanically. Many fields should have neither getter nor setter.
•Modern languages provide elegant syntax — Properties in C#, Python decorators, Kotlin backing fields—all preserve encapsulation with cleaner code.
•Avoid common anti-patterns — Don't return mutable state, don't break invariants with setters, don't put side effects in getters.

What's Next:

Now that we understand why accessors exist, we'll explore when to use them—and when not to. The next page dives deep into when to use getters, examining legitimate use cases versus over-exposure of internal state.

Page Complete

You now understand the fundamental purpose of accessors in object-oriented design. They are not merely syntactic conveniences but essential tools for maintaining encapsulation, enforcing invariants, and enabling implementation evolution. Next, we'll explore when getters are appropriate and when they indicate a design problem.