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

Getters and Setters — When and Why

LevelBeginner

Duration60 mins

TopicGetters and Setters — When and Why

3 / 4

When to Avoid Setters

The Hidden Danger of Unlimited Mutation

In the previous page, we explored when getters are appropriate and when they leak implementation details. Now we turn to the more controversial topic: setters.

Setters are far more dangerous than getters. While a getter merely exposes information, a setter allows the outside world to mutate your object's internal state. This capability, if granted carelessly, undermines everything encapsulation is meant to protect.

The truth is: most setters shouldn't exist. They represent a failure to think about the object's behavior, a surrender of control to external code, and a recipe for inconsistent states and scattered business logic.

This page will teach you to recognize when setters are problematic, understand why they undermine encapsulation, and learn the alternatives that lead to stronger, more robust object designs.

A Paradigm Shift

If you're used to automatically generating getters and setters for every field, this page will challenge that habit. The goal is not to eliminate all setters, but to treat each one as a significant decision that requires justification.

Why Setters Are Problematic

To understand why setters are often harmful, consider what they really represent: unrestricted mutation of object state from anywhere in the codebase.

This creates several fundamental problems:

Problem 1: Setters Allow Invalid States

•Objects have invariants—conditions that must always be true
•Setters for individual fields can violate invariants that depend on multiple fields
•Example: setStartDate() and setEndDate() individually cannot enforce that start < end
•The object can be left in an inconsistent state between setter calls

SetterInvariantViolation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Invariant: startDate must be before endDate
class DateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    // These setters cannot enforce the invariant!
    public void setStartDate(LocalDate start) {
        this.startDate = start;  // What if start > endDate?
    }
    
    public void setEndDate(LocalDate end) {
        this.endDate = end;  // What if end < startDate?
    }
}
 
// Problem: Object can be in invalid state
DateRange range = new DateRange();
range.setEndDate(LocalDate.of(2024, 1, 1));
range.setStartDate(LocalDate.of(2024, 12, 31));  // start > end!
 
// Even with validation, the order of setter calls matters
range.setStartDate(LocalDate.of(2025, 1, 1));  // Invalid if end is 2024!

Problem 2: Setters Scatter Business Logic

•When objects have setters, callers must implement rules about when/how to call them
•Business logic ends up duplicated across multiple call sites
•Changes to rules require hunting down all places that use the setters
•The object becomes a dumb data holder with no behavior of its own

ScatteredBusinessLogic.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
// Setters push logic to callers
class Order {
    private OrderStatus status;
    private LocalDateTime shippedAt;
    private String trackingNumber;
    
    public void setStatus(OrderStatus status) { this.status = status; }
    public void setShippedAt(LocalDateTime time) { this.shippedAt = time; }
    public void setTrackingNumber(String num) { this.trackingNumber = num; }
}
 
// Every place that ships an order must know the logic:
// Location 1:
order.setStatus(OrderStatus.SHIPPED);
order.setShippedAt(LocalDateTime.now());
order.setTrackingNumber(tracking);
notificationService.sendShippedEmail(order);
 
// Location 2: Same logic, hopefully consistent...
order.setStatus(OrderStatus.SHIPPED);
order.setShippedAt(LocalDateTime.now());  // What if someone forgets this?
order.setTrackingNumber(tracking);
 
// Location 3: Oops, forgot to send notification!
order.setStatus(OrderStatus.SHIPPED);
order.setTrackingNumber(tracking);
// shippedAt is null! Notification not sent!

Problem 3: Setters Destroy Temporal Coupling Visibility

•Some operations must happen in a specific order
•Setters hide this temporal coupling—the order dependency is not visible in the API
•Callers must know (through documentation or trial and error) the required sequence
•Forgetting a step or reordering leads to subtle bugs

Problem 4: Setters Prevent Immutability

•Immutable objects are simpler, safer, and easier to reason about
•They can be shared freely without defensive copying
•They are inherently thread-safe
•But setters make objects mutable by definition

Problem 5: Setters Complicate Testing

•More possible states means more test cases needed
•Partial updates create exponentially more state combinations
•Tests must verify invariants after every setter combination
•Immutable objects have far fewer states to test

The Core Issue

Setters treat objects as dumb data holders. Real objects should be rich with behavior, controlling their own state transitions and maintaining their own invariants. Every setter is a place where you've surrendered that control.

When to Absolutely Avoid Setters

Certain situations should trigger an immediate "no setter" response. These are patterns where setters cause the most damage:

Avoid 1: Setters for Identity Fields

•Identity fields (IDs, primary keys) should never change after construction
•Changing identity breaks references, caching, equality contracts
•Use constructor initialization and make field final
•If ID isn't known at construction time, use a factory or separate ID assignment service

NoIdentitySetters.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
// ❌ NEVER: Setter for identity
public class User {
    private String id;
    
    public void setId(String id) {  // Dangerous!
        this.id = id;
    }
}
 
// ✅ CORRECT: Immutable identity
public class User {
    private final String id;  // Set once, never changes
    
    public User(String id, String name) {
        this.id = Objects.requireNonNull(id, "ID cannot be null");
        // ...
    }
    
    public String getId() {
        return id;
    }
    
    // No setId()!
}

Avoid 2: Setters for Interdependent Fields

•When multiple fields have invariants involving each other, individual setters cannot maintain consistency
•Example: Rectangle with width/height where area constraint applies
•Example: DateTime components that must form a valid date
•Provide domain methods that update related fields atomically

InterdependentFields.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
// ❌ BAD: Separate setters for interdependent fields
public class Circle {
    private double radius;
    private double area;  // Should always be PI * radius^2
    
    public void setRadius(double r) {
        this.radius = r;
        // Must remember to update area!
    }
    
    public void setArea(double a) {
        this.area = a;
        // Must update radius? What if they don't match?
    }
}
 
// ✅ CORRECT: Derive area, only expose meaningful mutation
public class Circle {
    private double radius;
    
    public Circle(double radius) {
        setRadius(radius);  // Use internal setter for validation
    }
    
    public double getRadius() { return radius; }
    
    // Computed property - no setter needed
    public double getArea() {
        return Math.PI * radius * radius;
    }
    
    // Meaningful domain method with validation
    public void scale(double factor) {
        if (factor <= 0) {
            throw new IllegalArgumentException("Scale must be positive");
        }
        this.radius *= factor;
    }
    
    // If setRadius is truly needed
    private void setRadius(double r) {
        if (r < 0) throw new IllegalArgumentException("Radius cannot be negative");
        this.radius = r;
    }
}

Avoid 3: Setters for State Machine Transitions

•Objects with lifecycle states (Order → Shipped → Delivered) have transition rules
•Not all transitions are valid: can't go from CANCELLED to SHIPPED
•A setStatus() method cannot express these constraints
•Use domain methods that represent valid transitions

StateMachineWithoutSetters.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
// ❌ BAD: Status setter allows invalid transitions
public class Order {
    private OrderStatus status = OrderStatus.PENDING;
    
    public void setStatus(OrderStatus status) {
        this.status = status;  // Any transition allowed!
    }
}
 
order.setStatus(OrderStatus.SHIPPED);
order.setStatus(OrderStatus.PENDING);  // Going backwards? Allowed!
 
 
// ✅ CORRECT: Domain methods enforce valid transitions
public class Order {
    private OrderStatus status = OrderStatus.PENDING;
    
    public OrderStatus getStatus() { return status; }
    
    // Explicit transition methods with rules
    public void confirm() {
        if (status != OrderStatus.PENDING) {
            throw new InvalidTransitionException(
                "Can only confirm pending orders, current: " + status
            );
        }
        this.status = OrderStatus.CONFIRMED;
        // Trigger side effects: notification, logging, etc.
    }
    
    public void ship(String trackingNumber) {
        if (status != OrderStatus.CONFIRMED) {
            throw new InvalidTransitionException(
                "Can only ship confirmed orders, current: " + status
            );
        }
        this.status = OrderStatus.SHIPPED;
        this.trackingNumber = trackingNumber;
        this.shippedAt = LocalDateTime.now();
    }
    
    public void deliver() {
        if (status != OrderStatus.SHIPPED) {
            throw new InvalidTransitionException(
                "Can only deliver shipped orders, current: " + status
            );
        }
        this.status = OrderStatus.DELIVERED;
        this.deliveredAt = LocalDateTime.now();
    }
    
    public void cancel() {
        if (status == OrderStatus.DELIVERED) {
            throw new InvalidTransitionException(
                "Cannot cancel delivered orders"
            );
        }
        this.status = OrderStatus.CANCELLED;
    }
}

Avoid 4: Setters When Validation Depends on Context

•Sometimes whether a value is valid depends on external context (time, other objects, configuration)
•A setter can't access this context to validate properly
•Domain methods can require context as parameters
•Or use domain services that have access to necessary context

ContextDependentValidation.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
// ❌ BAD: Setter can't validate against context
public class Appointment {
    private LocalDateTime time;
    
    public void setTime(LocalDateTime time) {
        // Can't check if doctor is available at this time!
        // Can't check if patient has conflicting appointments!
        this.time = time;
    }
}
 
// ✅ CORRECT: Domain method with context
public class Appointment {
    private LocalDateTime time;
    
    public void reschedule(
            LocalDateTime newTime,
            SchedulingService scheduler) {
        
        if (!scheduler.isDoctorAvailable(doctor, newTime)) {
            throw new SchedulingException("Doctor not available");
        }
        
        if (!scheduler.isPatientFree(patient, newTime)) {
            throw new SchedulingException("Patient has conflict");
        }
        
        LocalDateTime oldTime = this.time;
        this.time = newTime;
        
        // Notify affected parties
        scheduler.notifyReschedule(this, oldTime, newTime);
    }
}

Avoid 5: Setters for Derived/Cached Values

•Values computed from other fields shouldn't have setters
•Setting them independently creates inconsistency
•Use getters that compute on demand or cached properties that auto-update
•External code shouldn't even know these are cacheable

Alternatives to Setters

When you're tempted to add a setter, consider these alternatives that maintain encapsulation and invariants:

Alternative 1: Rich Constructors

•Initialize all required state at construction time
•Object is born valid and stays valid
•No 'half-constructed' states possible
•Use factory methods or builders for complex construction

RichConstructors.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
// ✅ Rich constructor - object born complete
public class Address {
    private final String street;
    private final String city;
    private final String postalCode;
    private final String country;
    
    public Address(String street, String city, 
                   String postalCode, String country) {
        // Validate everything at construction
        this.street = Objects.requireNonNull(street);
        this.city = Objects.requireNonNull(city);
        this.postalCode = validatePostalCode(postalCode, country);
        this.country = Objects.requireNonNull(country);
    }
    
    // No setters - object is immutable after construction
}
 
// For complex construction, use a builder
Address address = Address.builder()
    .street("123 Main St")
    .city("Springfield")
    .postalCode("12345")
    .country("USA")
    .build();  // Validates everything at build time

Alternative 2: Domain Methods (Command Methods)

•Replace setters with methods that express domain intent
•Methods can validate, maintain invariants, trigger side effects
•Method names document what the operation means in the domain
•Example: employee.promote(newTitle, newSalary) instead of two setters

DomainMethods.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
// ✅ Domain methods express intent and maintain invariants
public class BankAccount {
    private Money balance;
    private List<Transaction> history;
    
    // Instead of setBalance(), use domain operations
    public void deposit(Money amount) {
        if (amount.isNegative()) {
            throw new IllegalArgumentException("Cannot deposit negative");
        }
        this.balance = this.balance.add(amount);
        this.history.add(Transaction.deposit(amount));
    }
    
    public void withdraw(Money amount) {
        if (amount.isNegative()) {
            throw new IllegalArgumentException("Cannot withdraw negative");
        }
        if (amount.isGreaterThan(balance)) {
            throw new InsufficientFundsException();
        }
        this.balance = this.balance.subtract(amount);
        this.history.add(Transaction.withdrawal(amount));
    }
    
    public void transfer(BankAccount target, Money amount) {
        this.withdraw(amount);  // Validates and updates this account
        target.deposit(amount);  // Updates target account
        // Both accounts maintain their invariants
    }
}

Alternative 3: Immutable Objects with Copy Methods

•For value objects, make them fully immutable
•Provide methods that return new instances with modified values
•Pattern: withX() methods return new objects
•Thread-safe, no defensive copying needed, easy to reason about

ImmutableWithCopy.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
// ✅ Immutable value object with copy methods
public final class Money {
    private final BigDecimal amount;
    private final Currency currency;
    
    public Money(BigDecimal amount, Currency currency) {
        this.amount = amount.setScale(2, RoundingMode.HALF_UP);
        this.currency = currency;
    }
    
    // No setters - instead, return new instances
    public Money withAmount(BigDecimal newAmount) {
        return new Money(newAmount, this.currency);
    }
    
    public Money withCurrency(Currency newCurrency) {
        return new Money(this.amount, newCurrency);
    }
    
    // Operations return new instances
    public Money add(Money other) {
        ensureSameCurrency(other);
        return new Money(
            this.amount.add(other.amount), 
            this.currency
        );
    }
    
    public Money multiply(BigDecimal factor) {
        return new Money(
            this.amount.multiply(factor), 
            this.currency
        );
    }
}
 
// Usage
Money price = new Money(BigDecimal.valueOf(100), USD);
Money discounted = price.multiply(BigDecimal.valueOf(0.9));
// 'price' is unchanged, 'discounted' is new object

Alternative 4: Builder Pattern for Complex Configuration

•When objects need flexible construction with many optional fields
•Builder accumulates configuration, validates at build time
•Object is created in a valid state, then immutable
•Clear separation between configuration phase and usage phase

BuilderPattern.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
65
66
67
68
69
70
71
72
// ✅ Builder for complex construction
public class HttpRequest {
    private final String method;
    private final URI url;
    private final Map<String, String> headers;
    private final Duration timeout;
    private final byte[] body;
    
    private HttpRequest(Builder builder) {
        this.method = builder.method;
        this.url = builder.url;
        this.headers = Map.copyOf(builder.headers);
        this.timeout = builder.timeout;
        this.body = builder.body != null 
            ? builder.body.clone() 
            : null;
    }
    
    public static Builder builder() {
        return new Builder();
    }
    
    public static class Builder {
        private String method = "GET";
        private URI url;
        private Map<String, String> headers = new HashMap<>();
        private Duration timeout = Duration.ofSeconds(30);
        private byte[] body;
        
        public Builder method(String method) {
            this.method = method;
            return this;
        }
        
        public Builder url(URI url) {
            this.url = url;
            return this;
        }
        
        public Builder header(String name, String value) {
            this.headers.put(name, value);
            return this;
        }
        
        public Builder timeout(Duration timeout) {
            this.timeout = timeout;
            return this;
        }
        
        public Builder body(byte[] body) {
            this.body = body;
            return this;
        }
        
        public HttpRequest build() {
            Objects.requireNonNull(url, "URL is required");
            if (body != null && method.equals("GET")) {
                throw new IllegalStateException("GET cannot have body");
            }
            return new HttpRequest(this);
        }
    }
}
 
// Usage - fluent, validated at build time
HttpRequest request = HttpRequest.builder()
    .method("POST")
    .url(URI.create("https://api.example.com/data"))
    .header("Content-Type", "application/json")
    .timeout(Duration.ofSeconds(10))
    .body(jsonBytes)
    .build();

When Setters Are Acceptable

Despite the warnings, some situations genuinely warrant setters. The key is that these are deliberate decisions, not defaults:

Acceptable 1: Independent, Validated Properties

•When a field is truly independent of other fields
•When validation can be done entirely within the setter
•When there are no side effects beyond the single field change
•Example: setDescription(String) for a product with no description constraints

AcceptableSetters.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class UserProfile {
    private String displayName;
    private String bio;
    
    // Acceptable: Independent field, simple validation
    public void setDisplayName(String name) {
        if (name == null || name.length() > 50) {
            throw new IllegalArgumentException(
                "Display name must be 1-50 characters"
            );
        }
        this.displayName = name.trim();
    }
    
    // Acceptable: Independent field, optional value
    public void setBio(String bio) {
        if (bio != null && bio.length() > 500) {
            throw new IllegalArgumentException("Bio too long");
        }
        this.bio = bio;
    }
}

Acceptable 2: Framework/Library Requirements

•Some frameworks require setters for dependency injection
•ORM frameworks may need setters to hydrate objects from database
•Serialization frameworks might require setters
•Consider: Use constructor injection, protected setters, or builder patterns where possible

FrameworkSetters.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
// Framework requirement - JPA entity
@Entity
public class Product {
    @Id
    private Long id;
    private String name;
    private BigDecimal price;
    
    // JPA requires no-arg constructor
    protected Product() {}
    
    // Preferred: Create through rich constructor
    public Product(String name, BigDecimal price) {
        this.name = Objects.requireNonNull(name);
        this.price = Objects.requireNonNull(price);
    }
    
    // Package-private or protected setters for JPA
    void setId(Long id) { this.id = id; }
    void setName(String name) { this.name = name; }
    void setPrice(BigDecimal price) { this.price = price; }
    
    // Public API uses domain methods
    public void updatePrice(BigDecimal newPrice) {
        if (newPrice.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Price must be positive");
        }
        this.price = newPrice;
        // Log, notify, etc.
    }
}

Acceptable 3: Configuration Objects

•Objects that hold configuration before being used
•Clear lifecycle: configure, then freeze/use
•Consider: Builder pattern is often cleaner
•If using setters, document the expected usage pattern

Acceptable 4: Testing and Mocking

•Test fixtures may need to set specific states
•Mocking frameworks sometimes require setters
•Consider: Package-private setters visible only to tests
•Or: Test builders that encapsulate setup logic

The Setter Justification Rule

For every setter you create, you should be able to answer: 'Why can't this be set at construction time?' and 'Why can't this be a domain method?' If you can't answer satisfactorily, the setter probably shouldn't exist.

Refactoring Away from Setters

If you have existing code with setters, here's how to migrate toward better designs:

Step 1: Identify Setter Usage Patterns

•Find all call sites that use each setter
•Group them by what they're trying to accomplish
•Look for patterns: Are setters always called together? In a particular order?
•These patterns reveal the domain operations that should replace setters

Step 2: Create Domain Methods

•For each usage pattern, create a domain method that expresses the intent
•The method should take all necessary parameters at once
•It should validate, update fields, and handle side effects atomically
•Keep setters temporarily to avoid breaking existing code

Step 3: Migrate Call Sites

•Update callers to use new domain methods instead of setters
•Handle cases where the new method's contract differs from raw setters
•Add deprecation warnings to setters to discourage new usage
•Consider making setters package-private as intermediate step

Step 4: Remove Setters

•Once all call sites are migrated, delete the setters
•Consider making fields final where possible
•Update tests to use the new domain methods
•Celebrate your more encapsulated, robust design!

SetterRefactoring.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
// BEFORE: Setters everywhere
public class Employee {
    private String title;
    private BigDecimal salary;
    private String department;
    
    public void setTitle(String title) { this.title = title; }
    public void setSalary(BigDecimal salary) { this.salary = salary; }
    public void setDepartment(String dept) { this.department = dept; }
}
 
// Callers must coordinate
employee.setTitle("Senior Engineer");
employee.setSalary(new BigDecimal("120000"));
// What if someone forgets to update salary when promoting?
 
 
// AFTER: Domain methods encode business operations
public class Employee {
    private String title;
    private BigDecimal salary;
    private String department;
    
    public void promote(String newTitle, BigDecimal newSalary) {
        Objects.requireNonNull(newTitle, "Title required for promotion");
        if (newSalary.compareTo(this.salary) < 0) {
            throw new IllegalArgumentException(
                "Promotion salary must be higher than current"
            );
        }
        this.title = newTitle;
        this.salary = newSalary;
        // Could: log, notify HR, trigger review cycle, etc.
    }
    
    public void transfer(String newDepartment) {
        Objects.requireNonNull(newDepartment);
        String oldDepartment = this.department;
        this.department = newDepartment;
        // Could: notify old/new managers, update seating, etc.
    }
    
    public void adjustSalary(BigDecimal newSalary, String reason) {
        Objects.requireNonNull(reason, "Salary adjustment requires reason");
        this.salary = newSalary;
        // Log the adjustment with reason for compliance
    }
}

Summary: When to Avoid Setters

We've explored why setters are often harmful and when they should be avoided. Here are the key takeaways:

Key Takeaways

•Setters allow arbitrary mutation — They surrender control of object state to external code, undermining encapsulation.
•Setters can't maintain invariants — Individual field setters cannot enforce constraints that involve multiple fields.
•Setters scatter business logic — Rules about valid state changes end up duplicated in every caller.
•Avoid setters for identities, interdependent fields, state machines, and derived values — These are the most dangerous cases.
•Use alternatives — Rich constructors, domain methods, immutable objects with copy methods, and builders produce better designs.
•When setters are needed, limit their scope — package-private visibility, validation, and documentation help reduce risk.

What's Next:

We've now covered when to use getters and when to avoid setters. The next page introduces the Tell, Don't Ask principle—a powerful design guideline that ties these concepts together and points toward more behavioral, less data-centric object designs.

Page Complete

You now understand why setters are often more problematic than getters and when to avoid them. The key insight is that objects should control their own state transitions through domain methods, not expose raw mutation through setters. Next, we'll explore the Tell, Don't Ask principle that formalizes this approach.

3 / 4

Loading learning content...

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

Getters and Setters — When and Why

LevelBeginner

Duration60 mins

TopicGetters and Setters — When and Why

3 / 4

When to Avoid Setters

The Hidden Danger of Unlimited Mutation

In the previous page, we explored when getters are appropriate and when they leak implementation details. Now we turn to the more controversial topic: setters.

This page will teach you to recognize when setters are problematic, understand why they undermine encapsulation, and learn the alternatives that lead to stronger, more robust object designs.

A Paradigm Shift

Why Setters Are Problematic

To understand why setters are often harmful, consider what they really represent: unrestricted mutation of object state from anywhere in the codebase.

This creates several fundamental problems:

Problem 1: Setters Allow Invalid States

•Objects have invariants—conditions that must always be true
•Setters for individual fields can violate invariants that depend on multiple fields
•Example: setStartDate() and setEndDate() individually cannot enforce that start < end
•The object can be left in an inconsistent state between setter calls

SetterInvariantViolation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Invariant: startDate must be before endDate
class DateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    // These setters cannot enforce the invariant!
    public void setStartDate(LocalDate start) {
        this.startDate = start;  // What if start > endDate?
    }
    
    public void setEndDate(LocalDate end) {
        this.endDate = end;  // What if end < startDate?
    }
}
 
// Problem: Object can be in invalid state
DateRange range = new DateRange();
range.setEndDate(LocalDate.of(2024, 1, 1));
range.setStartDate(LocalDate.of(2024, 12, 31));  // start > end!
 
// Even with validation, the order of setter calls matters
range.setStartDate(LocalDate.of(2025, 1, 1));  // Invalid if end is 2024!

Problem 2: Setters Scatter Business Logic

•When objects have setters, callers must implement rules about when/how to call them
•Business logic ends up duplicated across multiple call sites
•Changes to rules require hunting down all places that use the setters
•The object becomes a dumb data holder with no behavior of its own

ScatteredBusinessLogic.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
// Setters push logic to callers
class Order {
    private OrderStatus status;
    private LocalDateTime shippedAt;
    private String trackingNumber;
    
    public void setStatus(OrderStatus status) { this.status = status; }
    public void setShippedAt(LocalDateTime time) { this.shippedAt = time; }
    public void setTrackingNumber(String num) { this.trackingNumber = num; }
}
 
// Every place that ships an order must know the logic:
// Location 1:
order.setStatus(OrderStatus.SHIPPED);
order.setShippedAt(LocalDateTime.now());
order.setTrackingNumber(tracking);
notificationService.sendShippedEmail(order);
 
// Location 2: Same logic, hopefully consistent...
order.setStatus(OrderStatus.SHIPPED);
order.setShippedAt(LocalDateTime.now());  // What if someone forgets this?
order.setTrackingNumber(tracking);
 
// Location 3: Oops, forgot to send notification!
order.setStatus(OrderStatus.SHIPPED);
order.setTrackingNumber(tracking);
// shippedAt is null! Notification not sent!

Problem 3: Setters Destroy Temporal Coupling Visibility

•Some operations must happen in a specific order
•Setters hide this temporal coupling—the order dependency is not visible in the API
•Callers must know (through documentation or trial and error) the required sequence
•Forgetting a step or reordering leads to subtle bugs

Problem 4: Setters Prevent Immutability

•Immutable objects are simpler, safer, and easier to reason about
•They can be shared freely without defensive copying
•They are inherently thread-safe
•But setters make objects mutable by definition

Problem 5: Setters Complicate Testing

•More possible states means more test cases needed
•Partial updates create exponentially more state combinations
•Tests must verify invariants after every setter combination
•Immutable objects have far fewer states to test

The Core Issue

When to Absolutely Avoid Setters

Certain situations should trigger an immediate "no setter" response. These are patterns where setters cause the most damage:

Avoid 1: Setters for Identity Fields

•Identity fields (IDs, primary keys) should never change after construction
•Changing identity breaks references, caching, equality contracts
•Use constructor initialization and make field final
•If ID isn't known at construction time, use a factory or separate ID assignment service

NoIdentitySetters.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
// ❌ NEVER: Setter for identity
public class User {
    private String id;
    
    public void setId(String id) {  // Dangerous!
        this.id = id;
    }
}
 
// ✅ CORRECT: Immutable identity
public class User {
    private final String id;  // Set once, never changes
    
    public User(String id, String name) {
        this.id = Objects.requireNonNull(id, "ID cannot be null");
        // ...
    }
    
    public String getId() {
        return id;
    }
    
    // No setId()!
}

Avoid 2: Setters for Interdependent Fields

•When multiple fields have invariants involving each other, individual setters cannot maintain consistency
•Example: Rectangle with width/height where area constraint applies
•Example: DateTime components that must form a valid date
•Provide domain methods that update related fields atomically

InterdependentFields.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
// ❌ BAD: Separate setters for interdependent fields
public class Circle {
    private double radius;
    private double area;  // Should always be PI * radius^2
    
    public void setRadius(double r) {
        this.radius = r;
        // Must remember to update area!
    }
    
    public void setArea(double a) {
        this.area = a;
        // Must update radius? What if they don't match?
    }
}
 
// ✅ CORRECT: Derive area, only expose meaningful mutation
public class Circle {
    private double radius;
    
    public Circle(double radius) {
        setRadius(radius);  // Use internal setter for validation
    }
    
    public double getRadius() { return radius; }
    
    // Computed property - no setter needed
    public double getArea() {
        return Math.PI * radius * radius;
    }
    
    // Meaningful domain method with validation
    public void scale(double factor) {
        if (factor <= 0) {
            throw new IllegalArgumentException("Scale must be positive");
        }
        this.radius *= factor;
    }
    
    // If setRadius is truly needed
    private void setRadius(double r) {
        if (r < 0) throw new IllegalArgumentException("Radius cannot be negative");
        this.radius = r;
    }
}

Avoid 3: Setters for State Machine Transitions

•Objects with lifecycle states (Order → Shipped → Delivered) have transition rules
•Not all transitions are valid: can't go from CANCELLED to SHIPPED
•A setStatus() method cannot express these constraints
•Use domain methods that represent valid transitions

StateMachineWithoutSetters.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
// ❌ BAD: Status setter allows invalid transitions
public class Order {
    private OrderStatus status = OrderStatus.PENDING;
    
    public void setStatus(OrderStatus status) {
        this.status = status;  // Any transition allowed!
    }
}
 
order.setStatus(OrderStatus.SHIPPED);
order.setStatus(OrderStatus.PENDING);  // Going backwards? Allowed!
 
 
// ✅ CORRECT: Domain methods enforce valid transitions
public class Order {
    private OrderStatus status = OrderStatus.PENDING;
    
    public OrderStatus getStatus() { return status; }
    
    // Explicit transition methods with rules
    public void confirm() {
        if (status != OrderStatus.PENDING) {
            throw new InvalidTransitionException(
                "Can only confirm pending orders, current: " + status
            );
        }
        this.status = OrderStatus.CONFIRMED;
        // Trigger side effects: notification, logging, etc.
    }
    
    public void ship(String trackingNumber) {
        if (status != OrderStatus.CONFIRMED) {
            throw new InvalidTransitionException(
                "Can only ship confirmed orders, current: " + status
            );
        }
        this.status = OrderStatus.SHIPPED;
        this.trackingNumber = trackingNumber;
        this.shippedAt = LocalDateTime.now();
    }
    
    public void deliver() {
        if (status != OrderStatus.SHIPPED) {
            throw new InvalidTransitionException(
                "Can only deliver shipped orders, current: " + status
            );
        }
        this.status = OrderStatus.DELIVERED;
        this.deliveredAt = LocalDateTime.now();
    }
    
    public void cancel() {
        if (status == OrderStatus.DELIVERED) {
            throw new InvalidTransitionException(
                "Cannot cancel delivered orders"
            );
        }
        this.status = OrderStatus.CANCELLED;
    }
}

Avoid 4: Setters When Validation Depends on Context

•Sometimes whether a value is valid depends on external context (time, other objects, configuration)
•A setter can't access this context to validate properly
•Domain methods can require context as parameters
•Or use domain services that have access to necessary context

ContextDependentValidation.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
// ❌ BAD: Setter can't validate against context
public class Appointment {
    private LocalDateTime time;
    
    public void setTime(LocalDateTime time) {
        // Can't check if doctor is available at this time!
        // Can't check if patient has conflicting appointments!
        this.time = time;
    }
}
 
// ✅ CORRECT: Domain method with context
public class Appointment {
    private LocalDateTime time;
    
    public void reschedule(
            LocalDateTime newTime,
            SchedulingService scheduler) {
        
        if (!scheduler.isDoctorAvailable(doctor, newTime)) {
            throw new SchedulingException("Doctor not available");
        }
        
        if (!scheduler.isPatientFree(patient, newTime)) {
            throw new SchedulingException("Patient has conflict");
        }
        
        LocalDateTime oldTime = this.time;
        this.time = newTime;
        
        // Notify affected parties
        scheduler.notifyReschedule(this, oldTime, newTime);
    }
}

Avoid 5: Setters for Derived/Cached Values

•Values computed from other fields shouldn't have setters
•Setting them independently creates inconsistency
•Use getters that compute on demand or cached properties that auto-update
•External code shouldn't even know these are cacheable

Alternatives to Setters

When you're tempted to add a setter, consider these alternatives that maintain encapsulation and invariants:

Alternative 1: Rich Constructors

•Initialize all required state at construction time
•Object is born valid and stays valid
•No 'half-constructed' states possible
•Use factory methods or builders for complex construction

RichConstructors.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
// ✅ Rich constructor - object born complete
public class Address {
    private final String street;
    private final String city;
    private final String postalCode;
    private final String country;
    
    public Address(String street, String city, 
                   String postalCode, String country) {
        // Validate everything at construction
        this.street = Objects.requireNonNull(street);
        this.city = Objects.requireNonNull(city);
        this.postalCode = validatePostalCode(postalCode, country);
        this.country = Objects.requireNonNull(country);
    }
    
    // No setters - object is immutable after construction
}
 
// For complex construction, use a builder
Address address = Address.builder()
    .street("123 Main St")
    .city("Springfield")
    .postalCode("12345")
    .country("USA")
    .build();  // Validates everything at build time

Alternative 2: Domain Methods (Command Methods)

•Replace setters with methods that express domain intent
•Methods can validate, maintain invariants, trigger side effects
•Method names document what the operation means in the domain
•Example: employee.promote(newTitle, newSalary) instead of two setters

DomainMethods.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
// ✅ Domain methods express intent and maintain invariants
public class BankAccount {
    private Money balance;
    private List<Transaction> history;
    
    // Instead of setBalance(), use domain operations
    public void deposit(Money amount) {
        if (amount.isNegative()) {
            throw new IllegalArgumentException("Cannot deposit negative");
        }
        this.balance = this.balance.add(amount);
        this.history.add(Transaction.deposit(amount));
    }
    
    public void withdraw(Money amount) {
        if (amount.isNegative()) {
            throw new IllegalArgumentException("Cannot withdraw negative");
        }
        if (amount.isGreaterThan(balance)) {
            throw new InsufficientFundsException();
        }
        this.balance = this.balance.subtract(amount);
        this.history.add(Transaction.withdrawal(amount));
    }
    
    public void transfer(BankAccount target, Money amount) {
        this.withdraw(amount);  // Validates and updates this account
        target.deposit(amount);  // Updates target account
        // Both accounts maintain their invariants
    }
}

Alternative 3: Immutable Objects with Copy Methods

•For value objects, make them fully immutable
•Provide methods that return new instances with modified values
•Pattern: withX() methods return new objects
•Thread-safe, no defensive copying needed, easy to reason about

ImmutableWithCopy.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
// ✅ Immutable value object with copy methods
public final class Money {
    private final BigDecimal amount;
    private final Currency currency;
    
    public Money(BigDecimal amount, Currency currency) {
        this.amount = amount.setScale(2, RoundingMode.HALF_UP);
        this.currency = currency;
    }
    
    // No setters - instead, return new instances
    public Money withAmount(BigDecimal newAmount) {
        return new Money(newAmount, this.currency);
    }
    
    public Money withCurrency(Currency newCurrency) {
        return new Money(this.amount, newCurrency);
    }
    
    // Operations return new instances
    public Money add(Money other) {
        ensureSameCurrency(other);
        return new Money(
            this.amount.add(other.amount), 
            this.currency
        );
    }
    
    public Money multiply(BigDecimal factor) {
        return new Money(
            this.amount.multiply(factor), 
            this.currency
        );
    }
}
 
// Usage
Money price = new Money(BigDecimal.valueOf(100), USD);
Money discounted = price.multiply(BigDecimal.valueOf(0.9));
// 'price' is unchanged, 'discounted' is new object

Alternative 4: Builder Pattern for Complex Configuration

•When objects need flexible construction with many optional fields
•Builder accumulates configuration, validates at build time
•Object is created in a valid state, then immutable
•Clear separation between configuration phase and usage phase

BuilderPattern.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
65
66
67
68
69
70
71
72
// ✅ Builder for complex construction
public class HttpRequest {
    private final String method;
    private final URI url;
    private final Map<String, String> headers;
    private final Duration timeout;
    private final byte[] body;
    
    private HttpRequest(Builder builder) {
        this.method = builder.method;
        this.url = builder.url;
        this.headers = Map.copyOf(builder.headers);
        this.timeout = builder.timeout;
        this.body = builder.body != null 
            ? builder.body.clone() 
            : null;
    }
    
    public static Builder builder() {
        return new Builder();
    }
    
    public static class Builder {
        private String method = "GET";
        private URI url;
        private Map<String, String> headers = new HashMap<>();
        private Duration timeout = Duration.ofSeconds(30);
        private byte[] body;
        
        public Builder method(String method) {
            this.method = method;
            return this;
        }
        
        public Builder url(URI url) {
            this.url = url;
            return this;
        }
        
        public Builder header(String name, String value) {
            this.headers.put(name, value);
            return this;
        }
        
        public Builder timeout(Duration timeout) {
            this.timeout = timeout;
            return this;
        }
        
        public Builder body(byte[] body) {
            this.body = body;
            return this;
        }
        
        public HttpRequest build() {
            Objects.requireNonNull(url, "URL is required");
            if (body != null && method.equals("GET")) {
                throw new IllegalStateException("GET cannot have body");
            }
            return new HttpRequest(this);
        }
    }
}
 
// Usage - fluent, validated at build time
HttpRequest request = HttpRequest.builder()
    .method("POST")
    .url(URI.create("https://api.example.com/data"))
    .header("Content-Type", "application/json")
    .timeout(Duration.ofSeconds(10))
    .body(jsonBytes)
    .build();

When Setters Are Acceptable

Despite the warnings, some situations genuinely warrant setters. The key is that these are deliberate decisions, not defaults:

Acceptable 1: Independent, Validated Properties

•When a field is truly independent of other fields
•When validation can be done entirely within the setter
•When there are no side effects beyond the single field change
•Example: setDescription(String) for a product with no description constraints

AcceptableSetters.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class UserProfile {
    private String displayName;
    private String bio;
    
    // Acceptable: Independent field, simple validation
    public void setDisplayName(String name) {
        if (name == null || name.length() > 50) {
            throw new IllegalArgumentException(
                "Display name must be 1-50 characters"
            );
        }
        this.displayName = name.trim();
    }
    
    // Acceptable: Independent field, optional value
    public void setBio(String bio) {
        if (bio != null && bio.length() > 500) {
            throw new IllegalArgumentException("Bio too long");
        }
        this.bio = bio;
    }
}

Acceptable 2: Framework/Library Requirements

•Some frameworks require setters for dependency injection
•ORM frameworks may need setters to hydrate objects from database
•Serialization frameworks might require setters
•Consider: Use constructor injection, protected setters, or builder patterns where possible

FrameworkSetters.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
// Framework requirement - JPA entity
@Entity
public class Product {
    @Id
    private Long id;
    private String name;
    private BigDecimal price;
    
    // JPA requires no-arg constructor
    protected Product() {}
    
    // Preferred: Create through rich constructor
    public Product(String name, BigDecimal price) {
        this.name = Objects.requireNonNull(name);
        this.price = Objects.requireNonNull(price);
    }
    
    // Package-private or protected setters for JPA
    void setId(Long id) { this.id = id; }
    void setName(String name) { this.name = name; }
    void setPrice(BigDecimal price) { this.price = price; }
    
    // Public API uses domain methods
    public void updatePrice(BigDecimal newPrice) {
        if (newPrice.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Price must be positive");
        }
        this.price = newPrice;
        // Log, notify, etc.
    }
}

Acceptable 3: Configuration Objects

•Objects that hold configuration before being used
•Clear lifecycle: configure, then freeze/use
•Consider: Builder pattern is often cleaner
•If using setters, document the expected usage pattern

Acceptable 4: Testing and Mocking

•Test fixtures may need to set specific states
•Mocking frameworks sometimes require setters
•Consider: Package-private setters visible only to tests
•Or: Test builders that encapsulate setup logic

The Setter Justification Rule

Refactoring Away from Setters

If you have existing code with setters, here's how to migrate toward better designs:

Step 1: Identify Setter Usage Patterns

•Find all call sites that use each setter
•Group them by what they're trying to accomplish
•Look for patterns: Are setters always called together? In a particular order?
•These patterns reveal the domain operations that should replace setters

Step 2: Create Domain Methods

•For each usage pattern, create a domain method that expresses the intent
•The method should take all necessary parameters at once
•It should validate, update fields, and handle side effects atomically
•Keep setters temporarily to avoid breaking existing code

Step 3: Migrate Call Sites

•Update callers to use new domain methods instead of setters
•Handle cases where the new method's contract differs from raw setters
•Add deprecation warnings to setters to discourage new usage
•Consider making setters package-private as intermediate step

Step 4: Remove Setters

•Once all call sites are migrated, delete the setters
•Consider making fields final where possible
•Update tests to use the new domain methods
•Celebrate your more encapsulated, robust design!

SetterRefactoring.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
// BEFORE: Setters everywhere
public class Employee {
    private String title;
    private BigDecimal salary;
    private String department;
    
    public void setTitle(String title) { this.title = title; }
    public void setSalary(BigDecimal salary) { this.salary = salary; }
    public void setDepartment(String dept) { this.department = dept; }
}
 
// Callers must coordinate
employee.setTitle("Senior Engineer");
employee.setSalary(new BigDecimal("120000"));
// What if someone forgets to update salary when promoting?
 
 
// AFTER: Domain methods encode business operations
public class Employee {
    private String title;
    private BigDecimal salary;
    private String department;
    
    public void promote(String newTitle, BigDecimal newSalary) {
        Objects.requireNonNull(newTitle, "Title required for promotion");
        if (newSalary.compareTo(this.salary) < 0) {
            throw new IllegalArgumentException(
                "Promotion salary must be higher than current"
            );
        }
        this.title = newTitle;
        this.salary = newSalary;
        // Could: log, notify HR, trigger review cycle, etc.
    }
    
    public void transfer(String newDepartment) {
        Objects.requireNonNull(newDepartment);
        String oldDepartment = this.department;
        this.department = newDepartment;
        // Could: notify old/new managers, update seating, etc.
    }
    
    public void adjustSalary(BigDecimal newSalary, String reason) {
        Objects.requireNonNull(reason, "Salary adjustment requires reason");
        this.salary = newSalary;
        // Log the adjustment with reason for compliance
    }
}

Summary: When to Avoid Setters

We've explored why setters are often harmful and when they should be avoided. Here are the key takeaways:

Key Takeaways

•Setters allow arbitrary mutation — They surrender control of object state to external code, undermining encapsulation.
•Setters can't maintain invariants — Individual field setters cannot enforce constraints that involve multiple fields.
•Setters scatter business logic — Rules about valid state changes end up duplicated in every caller.
•Avoid setters for identities, interdependent fields, state machines, and derived values — These are the most dangerous cases.
•Use alternatives — Rich constructors, domain methods, immutable objects with copy methods, and builders produce better designs.
•When setters are needed, limit their scope — package-private visibility, validation, and documentation help reduce risk.

What's Next:

Page Complete

3 / 4