Getters And Setters When And Why - Learning Module

Loading content...

0/246

When to Use Getters

The Art of Thoughtful Exposure

Having established why accessors exist, we now face a practical question: When should you provide a getter? The answer is not as simple as "always" or "never"—it requires careful consideration of what information your object genuinely needs to share with the outside world.

Getters are often created reflexively—developers define a private field and immediately generate a getter, treating it as a mandatory pairing. This habit undermines encapsulation by exposing implementation details that should remain hidden.

This page teaches you to think critically about each getter: Is this information part of the object's public contract? Does exposing it serve the object's clients, or does it merely leak implementation details? The goal is to expose exactly what's needed—no more, no less.

What You Will Learn

By the end of this page, you will understand the legitimate use cases for getters, how to distinguish between appropriate exposure and information leakage, and how to design getters that serve your object's clients without compromising encapsulation. You'll develop a decision framework for determining when a getter is warranted.

The Getter Decision Framework

Before creating any getter, answer these questions:

1. Is this information part of the object's public identity?

Some information is intrinsic to what an object represents. A Person object naturally exposes a name. A Rectangle naturally exposes width and height. These are part of the object's conceptual identity, not implementation details.

2. Do clients genuinely need this information?

The key word is need. If clients need to display, compare, or base decisions on this value, a getter is warranted. If you're exposing information "just in case," you're leaking implementation details.

3. Can the object perform the operation instead?

Often, when clients request data, what they really want is for the object to do something with that data. Instead of providing a getter so clients can perform a calculation, consider whether the object should perform that calculation itself.

4. Is the representation stable?

If the internal representation might change significantly, exposing it through a getter locks you into that representation or forces complex conversions later.

Getter Decision Framework
Question	If Yes	If No
Is it part of public identity?	Strong candidate for getter	Probably shouldn't expose
Do clients genuinely need it?	Consider providing getter	Don't create getter
Can object perform operation instead?	Provide behavior, not data	Getter may be appropriate
Is representation stable?	Safe to expose through getter	Consider abstracting or omitting

The Principle of Minimal Exposure

Start with no getters. Add each one deliberately when you have a concrete use case. This is the opposite of the typical approach (generate all getters, maybe remove some later), and it leads to much tighter encapsulation.

Legitimate Use Cases for Getters

Let's examine the scenarios where getters are genuinely appropriate and enhance rather than undermine your design.

Use Case 1: Identity and Core Attributes

•Objects have identity—attributes that define what they represent
•These are part of the public contract and typically stable
•Examples: Person.getName(), Order.getId(), Product.getSku()
•These getters expose what the object is, not how it's implemented

IdentityGetters.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
// Identity attributes - appropriate for getters
public class Employee {
    private final String employeeId;
    private final String name;
    private final String department;
    private LocalDate hireDate;
    
    // Identity getter - this IS the employee's identity
    public String getEmployeeId() {
        return employeeId;
    }
    
    // Core attribute - clients need this for display
    public String getName() {
        return name;
    }
    
    // Core attribute - used for organizational queries
    public String getDepartment() {
        return department;
    }
    
    // Core attribute - needed for HR calculations
    public LocalDate getHireDate() {
        return hireDate;
    }
}

Use Case 2: Presentation and Display

•UI layers need to display object state to users
•Reports need to render object information
•APIs need to serialize objects for clients
•These are legitimate external needs that require state access

PresentationGetters.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
// Presentation-focused getters
public class Order {
    private String orderId;
    private LocalDateTime createdAt;
    private List<OrderLine> lines;
    private Money subtotal;
    private Money tax;
    private Money total;
    
    // Presentation: Display order reference
    public String getOrderId() {
        return orderId;
    }
    
    // Presentation: Show when order was placed
    public LocalDateTime getCreatedAt() {
        return createdAt;
    }
    
    // Presentation: Display price breakdown
    public Money getSubtotal() {
        return subtotal;
    }
    
    public Money getTax() {
        return tax;
    }
    
    public Money getTotal() {
        return total;
    }
    
    // Presentation: List items in UI
    public List<OrderLine> getLines() {
        return Collections.unmodifiableList(lines);
    }
    
    // Computed presentation value
    public int getItemCount() {
        return lines.stream()
            .mapToInt(OrderLine::getQuantity)
            .sum();
    }
}

Use Case 3: Decision Support for External Logic

•Sometimes external systems legitimately need to make decisions based on object state
•Sorting, filtering, and grouping collections require access to comparison values
•Configuration systems may need to inspect object properties
•The key is that the decision logic belongs externally, not in the object

DecisionSupportGetters.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
// Decision support - external code needs these values
public class Task {
    private String title;
    private Priority priority;
    private LocalDateTime dueDate;
    private TaskStatus status;
    
    // Getters for external decision-making
    public Priority getPriority() { return priority; }
    public LocalDateTime getDueDate() { return dueDate; }
    public TaskStatus getStatus() { return status; }
}
 
// External code legitimately uses these for sorting/filtering
List<Task> urgentTasks = tasks.stream()
    .filter(t -> t.getPriority() == Priority.HIGH)
    .filter(t -> t.getDueDate().isBefore(tomorrow))
    .sorted(comparing(Task::getDueDate))
    .collect(toList());
 
// Configuration system inspects properties
if (task.getStatus() == TaskStatus.BLOCKED) {
    notificationService.alertTeamLead(task);
}

Use Case 4: Computed Properties

•Getters don't have to return stored fields—they can compute values
•This is actually a strength: internal representation is hidden
•Examples: Circle.getArea(), Person.getAge(), Order.isOverdue()
•The caller gets the value they need without knowing how it's derived

ComputedPropertyGetters.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
public class Subscription {
    private LocalDate startDate;
    private SubscriptionPlan plan;
    
    // Computed: no field for 'expirationDate'
    public LocalDate getExpirationDate() {
        return startDate.plus(plan.getDuration());
    }
    
    // Computed: no field for 'isActive'
    public boolean isActive() {
        return LocalDate.now().isBefore(getExpirationDate());
    }
    
    // Computed: no field for 'daysRemaining'
    public long getDaysRemaining() {
        return ChronoUnit.DAYS.between(
            LocalDate.now(), 
            getExpirationDate()
        );
    }
    
    // Computed: no field for 'percentage used'
    public double getUsagePercentage() {
        long total = ChronoUnit.DAYS.between(
            startDate, 
            getExpirationDate()
        );
        long elapsed = ChronoUnit.DAYS.between(
            startDate, 
            LocalDate.now()
        );
        return (double) elapsed / total * 100;
    }
}

Use Case 5: Object Comparison and Equality

•Implementing equals(), hashCode(), and compareTo() requires field access
•However, these methods are usually inside the class, not external
•For external comparison (sorting), exposing comparison keys is appropriate
•Consider if a Comparator could be provided instead of raw getters

Use Case 6: Testing and Debugging

•Tests need to verify object state after operations
•Debuggers and logging need to inspect object contents
•These are valid reasons for getters—but consider alternatives
•Package-private getters or dedicated test interfaces can limit exposure

Getters That Should Raise Concerns

Not all getters are created equal. Some patterns suggest that a getter is actually a design problem in disguise.

Warning Sign 1: Getter Chains

•When you see a.getB().getC().getD(), encapsulation is breaking down
•This violates the Law of Demeter (talk only to your immediate friends)
•Each .get in the chain increases coupling to internal structure
•If B's internal representation changes, all callers break

GetterChains.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// ❌ BAD: Getter chain exposes deep structure
double salary = employee
    .getDepartment()
    .getManager()
    .getCompensation()
    .getBaseSalary();
 
// If any intermediate class changes structure, this breaks
// The caller now knows: Employee has Department,
// Department has Manager, Manager has Compensation, etc.
 
 
// ✅ BETTER: Ask the object to perform the operation
// Employee knows how to find relevant salary information
Optional<Double> managerSalary = employee.getManagerSalary();
 
// Or provide a focused interface
interface SalaryService {
    Optional<Money> getManagerSalaryFor(Employee employee);
}

Warning Sign 2: Getters Followed by Conditionals

•Pattern: if (obj.getStatus() == X) { doA(); } else if (obj.getStatus() == Y) { doB(); }
•This suggests the object should own that behavior
•The conditional logic belongs inside the object, not scattered in callers
•Consider moving the behavior to the object itself—polymorphism may help

GetterConditionals.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
// ❌ BAD: Getter + conditional logic scattered in callers
public class PaymentProcessor {
    public void process(Payment payment) {
        if (payment.getStatus() == PaymentStatus.PENDING) {
            processNewPayment(payment);
        } else if (payment.getStatus() == PaymentStatus.AUTHORIZED) {
            capturePayment(payment);
        } else if (payment.getStatus() == PaymentStatus.FAILED) {
            retryPayment(payment);
        }
        // This logic is duplicated everywhere payments are handled
    }
}
 
 
// ✅ BETTER: Payment owns its behavior
public class Payment {
    private PaymentStatus status;
    private PaymentStrategy strategy;
    
    public void process(PaymentProcessor processor) {
        // Object knows its own behavior
        strategy.process(this, processor);
    }
    
    // Or use polymorphism through state pattern
    public void advance() {
        this.status = status.next(this);
    }
}

Warning Sign 3: Getters for Internal Infrastructure

•Exposing internal data structures: getInternalMap(), getCache()
•Exposing implementation helpers: getValidator(), getSerializer()
•Exposing configuration details: getConnectionString(), getBufferSize()
•These are implementation details, not part of the object's conceptual identity

InternalInfrastructureGetters.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
// ❌ BAD: Exposing internal infrastructure
public class UserRepository {
    private HikariDataSource dataSource;
    private Map<Long, User> cache;
    private UserValidator validator;
    
    // These expose implementation details!
    public DataSource getDataSource() { return dataSource; }
    public Map<Long, User> getCache() { return cache; }
    public UserValidator getValidator() { return validator; }
}
 
 
// ✅ BETTER: Hide infrastructure behind domain operations
public class UserRepository {
    private HikariDataSource dataSource;
    private Map<Long, User> cache;
    private UserValidator validator;
    
    // Domain operations - infrastructure is hidden
    public Optional<User> findById(Long id) {
        return Optional.ofNullable(cache.get(id))
            .or(() -> loadFromDatabase(id));
    }
    
    public void save(User user) {
        validator.validate(user);
        saveToDatabase(user);
        cache.put(user.getId(), user);
    }
    
    // If monitoring is needed, provide focused methods
    public int getCacheSize() { return cache.size(); }
    public HealthStatus getHealth() { /* check dataSource */ }
}

Warning Sign 4: Getters for Mutable Collections

•Returning raw mutable collections breaks encapsulation entirely
•Callers can modify the internal state without going through setters
•All invariant protection is bypassed
•Always return unmodifiable views or defensive copies

MutableCollectionGetters.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
// ❌ DANGEROUS: Returning mutable collection
public class ShoppingCart {
    private List<CartItem> items = new ArrayList<>();
    
    public List<CartItem> getItems() {
        return items;  // Caller can do anything!
    }
}
 
// External code breaks all invariants:
cart.getItems().clear();  // Empty the cart without proper handling
cart.getItems().add(null);  // Add invalid data
cart.getItems().set(0, new CartItem(freeProduct, 1000));  // Steal!
 
 
// ✅ SAFE: Return unmodifiable view
public class ShoppingCart {
    private List<CartItem> items = new ArrayList<>();
    
    public List<CartItem> getItems() {
        return Collections.unmodifiableList(items);
    }
    
    // All modifications go through controlled methods
    public void addItem(Product product, int quantity) {
        // Validate, update totals, fire events, etc.
    }
}
 
 
// ✅ ALTERNATIVE: Return a stream for iteration
public Stream<CartItem> items() {
    return items.stream();
}

Designing Good Getters

When you've determined that a getter is warranted, follow these principles to design it well:

Principle 1: Name for the Concept, Not the Field

•Getter names should reflect the conceptual value, not the storage mechanism
•Prefer getAge() over getBirthDateField() even if age is computed from birthDate
•This allows internal representation to change while interface stays stable
•Names should make sense to domain experts, not just developers

Principle 2: Return Immutable or Copied Data

•Never return mutable internal references
•For collections: Collections.unmodifiableList(list) or new ArrayList<>(list)
•For complex objects: return defensive copies or immutable value objects
•For dates: LocalDate is immutable (safe), but Date is mutable (copy it!)

ImmutableReturns.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
public class Event {
    private final String name;
    private final Date legacyStartDate;  // Mutable old API
    private final LocalDateTime modernStartDate;  // Immutable new API
    private final List<Attendee> attendees;
    
    // Safe: String is immutable
    public String getName() {
        return name;
    }
    
    // Safe: LocalDateTime is immutable
    public LocalDateTime getModernStartDate() {
        return modernStartDate;
    }
    
    // Defensive copy: Date is mutable!
    public Date getLegacyStartDate() {
        return new Date(legacyStartDate.getTime());
    }
    
    // Unmodifiable view: prevents external modification
    public List<Attendee> getAttendees() {
        return Collections.unmodifiableList(attendees);
    }
    
    // For deep hierarchies, consider deep copies or immutable wrappers
}

Principle 3: Consider Nullability Carefully

•Can this value ever be absent? Make it explicit in the return type
•Java: Return Optional<T> for nullable values, not bare T
•Document whether null is a valid return value in languages without optionals
•Alternatively, use the Null Object pattern to avoid null entirely

NullabilityDesign.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
public class Customer {
    private String customerId;      // Always present
    private String email;           // Required
    private String phoneNumber;     // Optional
    private Address shippingAddress; // Optional
    private String nickName;        // Optional, has default
    
    // Clear: never null
    public String getCustomerId() {
        return customerId;
    }
    
    // Clear: never null
    public String getEmail() {
        return email;
    }
    
    // Explicit: might be absent
    public Optional<String> getPhoneNumber() {
        return Optional.ofNullable(phoneNumber);
    }
    
    // Explicit: might be absent
    public Optional<Address> getShippingAddress() {
        return Optional.ofNullable(shippingAddress);
    }
    
    // Alternative: provide default, never null
    public String getDisplayName() {
        return nickName != null ? nickName : email.split("@")[0];
    }
}
 
// Usage is now self-documenting
customer.getPhoneNumber()
    .ifPresent(phone -> sendSMS(phone, message));
 
String label = customer.getShippingAddress()
    .map(Address::getLabel)
    .orElse("No shipping address");

Principle 4: Keep Getters Simple and Fast

•Callers expect getters to be cheap (O(1) time complexity)
•If computation is expensive, document it or use a different name
•Consider caching if computation is expensive but values are stable
•Names like calculate...() or compute...() signal possible expense

GetterPerformance.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
public class Report {
    private List<Transaction> transactions;
    private Money cachedTotal;
    private boolean totalValid;
    
    // Simple getter - always fast
    public int getTransactionCount() {
        return transactions.size();  // O(1)
    }
    
    // Computed but cached - fast after first call
    public Money getTotal() {
        if (!totalValid) {
            cachedTotal = computeTotal();
            totalValid = true;
        }
        return cachedTotal;
    }
    
    // Name signals this might be slow
    public DetailedBreakdown calculateDetailedBreakdown() {
        // Expensive computation - name makes this clear
        return analyzeTransactions(transactions);
    }
    
    // Invalidate cache when data changes
    public void addTransaction(Transaction t) {
        transactions.add(t);
        totalValid = false;  // Invalidate cache
    }
}

Principle 5: Be Consistent in Naming Conventions

•Follow language conventions: getX() in Java, x property in C#/Kotlin/Python
•For booleans: isActive(), hasPermission(), canEdit() read naturally
•Boolean getters shouldn't be named getIsActive() (redundant)
•Collection getters often work well as plural nouns: getItems(), getUsers()

The Getter Test: Questions to Ask

Before adding any getter, run it through this checklist. Each "no" answer is a reason to reconsider whether the getter should exist.

The Getter Justification Checklist

•Do clients actually need this value? Can you point to specific code that will consume it?
•Is this part of the object's conceptual identity? Would a domain expert recognize this as a property of the object?
•Is the object the right source? Or should the value come from somewhere else (a service, another object)?
•Could the object perform the operation instead? Is the caller getting data just to do something the object could do itself?
•Is the representation stable? If you expose this, are you locking yourself into this representation?
•Is the return safe? Are you returning an immutable value or defensive copy?
•Does the name communicate intent? Will someone reading the code understand what this represents?

When in Doubt, Don't

If you can't clearly justify a getter, don't create it. You can always add one later when a genuine need arises. Removing a getter from a public API, however, is a breaking change. Start conservative.

Alternatives to Getters

Often, when you're tempted to add a getter, there's a better design that keeps behavior inside the object. Here are common alternatives:

Alternative 1: Move the Behavior to the Object

•Instead of cart.getTotal() so you can if (total > limit), ask cart.exceedsLimit(limit)
•Instead of user.getRole() for permission checks, ask user.canPerform(action)
•This keeps business logic in one place, not scattered among callers

BehaviorInsteadOfGetter.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ Getter forces caller to implement logic
Money total = cart.getTotal();
if (total.isGreaterThan(spendingLimit)) {
    throw new SpendingLimitExceededException();
}
 
// ✅ Object owns the behavior
if (cart.exceedsSpendingLimit(spendingLimit)) {
    throw new SpendingLimitExceededException();
}
 
// Or even better - object handles the consequence
cart.validateAgainstSpendingLimit(spendingLimit);  // Throws if exceeded

Alternative 2: Provide a Focused Interface

•Instead of exposing all fields, provide an interface for the specific need
•For serialization: implement a toDto() method that returns exactly what's needed
•For display: provide a toString() or format() method
•For comparison: provide a Comparator rather than exposing sortable fields

FocusedInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// ❌ Exposing fields for sorting
public String getLastName() { return lastName; }
public String getFirstName() { return firstName; }
 
// Caller must know how to sort
users.sort((a, b) -> {
    int last = a.getLastName().compareTo(b.getLastName());
    return last != 0 ? last : a.getFirstName().compareTo(b.getFirstName());
});
 
 
// ✅ Provide the comparator
public static final Comparator<User> BY_NAME = 
    Comparator.comparing(User::lastName)
              .thenComparing(User::firstName);
 
// Caller just uses it
users.sort(User.BY_NAME);

Alternative 3: Double Dispatch / Visitor

•When external code needs to process object data in varying ways
•Instead of exposing data through getters, accept a callback/visitor
•The object controls what data is shared and in what form
•Particularly useful for formatting, serialization, and polymorphic operations

DoubleDispatch.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
// ❌ Exposing data for external processing
public String getCardNumber() { return cardNumber; }
public String getExpiry() { return expiry; }
public String getCvv() { return cvv; }
 
// External code processes sensitive data directly (unsafe!)
 
 
// ✅ Accept a processor that handles the data
public interface PaymentProcessor {
    void process(String cardNumber, String expiry, String cvv);
}
 
public void processPayment(PaymentProcessor processor) {
    // Object controls how data is shared
    processor.process(
        maskCardNumber(cardNumber),  // Can mask or transform
        expiry,
        cvv
    );
}
 
// Even better for security: never expose CVV at all
public PaymentToken tokenize(TokenizationService service) {
    return service.tokenize(this);  // Service has secure access
}

Summary: When to Use Getters

We've examined when getters are appropriate and when they indicate a design problem. Here are the key takeaways:

Key Takeaways

•Start with minimal exposure — Add getters deliberately when genuine needs arise, not reflexively for every field.
•Legitimate uses exist — Identity attributes, presentation data, comparison values, computed properties, and testing are valid reasons for getters.
•Watch for warning signs — Getter chains, getters followed by conditionals, exposed infrastructure, and mutable collection returns suggest design problems.
•Design getters carefully — Name for concepts, return immutable data, handle nullability explicitly, keep performance predictable.
•Consider alternatives — Moving behavior to the object, providing focused interfaces, and using visitor patterns often produce better designs than exposing data through getters.
•Use the checklist — Before each getter, ask whether it's truly needed and whether the object could do the work instead.

What's Next:

We've explored when getters are appropriate. The next page tackles the more controversial topic: when to avoid setters. Setters are often more problematic than getters, and understanding when to omit them is key to building truly encapsulated objects.

Page Complete

You now have a decision framework for when to provide getters. The key insight is that each getter should be a deliberate choice that serves the object's clients, not a reflexive pairing with every private field. Next, we'll explore why setters are often the bigger encapsulation problem.