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

Getters and Setters — When and Why

LevelBeginner

Duration60 mins

TopicGetters and Setters — When and Why

4 / 4

Tell, Don't Ask Principle Introduction

A Principle That Changes How You Design

Throughout this module, we've explored when to use getters, when to avoid setters, and how accessors relate to encapsulation. Now we'll crystallize these insights into a powerful design principle that provides a memorable decision-making tool: Tell, Don't Ask.

This principle, first articulated by Andy Hunt and Dave Thomas in their "Pragmatic Programmer" work and refined in the object-oriented design community, captures the essence of good encapsulation in four simple words. Once you internalize it, you'll find yourself naturally designing more robust, maintainable, and truly object-oriented systems.

The principle states: Instead of asking an object for data and then acting on that data, tell the object what to do.

This simple reframing transforms how you think about object responsibilities and leads naturally to designs where behavior lives with the data it operates on.

What You Will Learn

By the end of this page, you will understand the Tell, Don't Ask principle, recognize patterns that violate it, learn refactoring strategies that honor it, and understand where the principle has limits. You'll have a practical tool for making design decisions about object responsibilities.

Understanding Tell, Don't Ask

The Ask Pattern (Anti-pattern):

In the "Ask" pattern, code retrieves information from an object and then makes decisions based on that information:

1. Get data from object
2. Examine the data
3. Make a decision
4. Possibly modify the object or take other action

This pattern seems natural—after all, we need information to act. But it has a critical flaw: it puts the decision-making logic in the wrong place.

The Tell Pattern (Preferred):

In the "Tell" pattern, code tells the object what to do and trusts it to handle the details:

1. Tell object what outcome you want
2. Object makes decisions internally
3. Object acts or responds appropriately

This pattern keeps the logic close to the data it operates on.

AskPattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ❌ ASK Pattern
// "Let me check your state and decide"
 
if (account.getBalance() < amount) {
    throw new InsufficientFundsException();
}
account.setBalance(
    account.getBalance() - amount
);
transactionLog.record(
    account.getId(), 
    "withdrawal", 
    amount
);

TellPattern.java
1
2
3
4
5
6
7
8
9
10
// ✅ TELL Pattern
// "Please handle this withdrawal"
 
account.withdraw(amount);
 
// The object handles:
// - Balance check
// - Balance update
// - Transaction logging
// - Any other invariants

Why Tell is Better:

Single Responsibility: The withdrawal logic lives in one place—the BankAccount class—not scattered across callers.
Encapsulation Preserved: Callers don't need to know about balance, transaction logs, or validation rules. The internal implementation is hidden.
Consistency Guaranteed: Every withdrawal goes through the same logic. No caller can forget the transaction log or skip validation.
Easier Evolution: If withdrawal rules change (overdraft protection, daily limits), you modify one place.
Command Intent: withdraw(amount) expresses business intent. setBalance(getBalance() - amount) expresses mechanism.

The Mental Model

Think of objects as intelligent agents that know how to do their job, not as data bags that you manipulate from outside. You're delegating work to a capable entity, not micromanaging a passive container.

Recognizing Ask Patterns in Code

Ask patterns often hide in plain sight. Here are common signatures to watch for:

Pattern 1: Getter Followed by Conditional

•Shape: if (obj.getX() == condition) { doSomething(obj); }
•The decision logic belongs inside obj, not in the caller
•Consider: Can obj make this decision? Can obj perform the action?

GetterConditional.java
1
2
3
4
5
6
7
8
9
10
11
// ❌ ASK: Getter + conditional
if (order.getStatus() == OrderStatus.PENDING) {
    order.setStatus(OrderStatus.CONFIRMED);
    emailService.sendConfirmation(order.getCustomerEmail());
    inventoryService.reserve(order.getItems());
}
 
// ✅ TELL: Object handles its own state transition
order.confirm(emailService, inventoryService);
// Order internally checks preconditions, updates state,
// and coordinates side effects

Pattern 2: Multi-Getter Calculations

•Shape: result = calculate(obj.getA(), obj.getB(), obj.getC())
•If calculation uses multiple values from one object, it probably belongs in that object
•Consider: Should the object return the calculated result directly?

MultiGetterCalculation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Extracting data to calculate externally
double tax = calculateTax(
    order.getSubtotal(),
    order.getShippingAddress().getState(),
    order.getItems().stream()
        .map(Item::getTaxCategory)
        .collect(toList())
);
order.setTax(tax);
 
// ✅ TELL: Object knows how to calculate its own tax
order.calculateTax(taxService);
// Order provides its data to taxService internally

Pattern 3: Getter Chain Navigation

•Shape: obj.getA().getB().getC()
•Violates Law of Demeter—too much knowledge of internal structure
•Each accessor in the chain deepens coupling
•Consider: Can the first object provide what you need directly?

GetterChain.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Chain reveals deep structure
if (employee.getDepartment().getManager().getApprovalLimit() 
        >= request.getAmount()) {
    request.approve();
}
 
// ✅ TELL: Ask the right object
if (employee.canApprove(request)) {
    request.approve();
}
 
// Or even better, tell the request to seek approval
request.requestApprovalFrom(employee);

Pattern 4: Null-Check Cascades

•Shape: if (obj.getX() != null && obj.getX().getY() != null)
•Null checks before each accessor indicate structural knowledge
•Consider: Object should handle null cases internally, return Optional, or use Null Object pattern

NullCheckCascade.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Null checks cascade
String city = "Unknown";
if (user.getAddress() != null) {
    if (user.getAddress().getCity() != null) {
        city = user.getAddress().getCity();
    }
}
 
// ✅ TELL: Object handles the complexity
String city = user.getCityOrDefault("Unknown");
 
// Or with Optional
String city = user.getCity().orElse("Unknown");

Pattern 5: Feature Envy

•A method uses more features of another class than its own
•Classic code smell indicating misplaced responsibility
•The method should likely move to the class it's "envious" of

FeatureEnvy.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
// ❌ ASK: This method is envious of Order
class ReportGenerator {
    public String generateOrderSummary(Order order) {
        // Uses only Order's data
        return String.format(
            "Order %s: %d items, total $%.2f, status: %s",
            order.getId(),
            order.getItems().size(),
            order.getTotal().doubleValue(),
            order.getStatus()
        );
    }
}
 
// ✅ TELL: Move the method to where the data lives
class Order {
    public String getSummary() {
        return String.format(
            "Order %s: %d items, total $%.2f, status: %s",
            id, items.size(), total.doubleValue(), status
        );
    }
}
 
// Or use a formatting service that Order calls
class Order {
    public String format(OrderFormatter formatter) {
        return formatter.format(this);  // Double dispatch
    }
}

Refactoring Toward Tell

When you spot an Ask pattern, here are techniques to transform it into a Tell pattern:

Technique 1: Move Behavior to Data Owner

•Identify which object owns the data being examined
•Move the decision/calculation to that object
•Replace getter calls with a method call that expresses the intent
•The new method name should be a verb (action) not a noun (data)

MoveBehavior.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
// BEFORE: Logic in caller
public void applyDiscount(Order order, DiscountCode code) {
    if (order.getTotal() >= code.getMinimum() 
            && order.getCustomer().isMember()
            && code.isValid()) {
        double discount = order.getTotal() * code.getPercentage();
        order.setDiscount(discount);
    }
}
 
// AFTER: Logic moved to Order
public class Order {
    public void applyDiscount(DiscountCode code) {
        if (!canApplyDiscount(code)) {
            return;  // Or throw
        }
        this.discount = calculateDiscount(code);
    }
    
    private boolean canApplyDiscount(DiscountCode code) {
        return total.compareTo(code.getMinimum()) >= 0
            && customer.isMember()
            && code.isValid();
    }
    
    private Money calculateDiscount(DiscountCode code) {
        return total.multiply(code.getPercentage());
    }
}
 
// Caller just tells
order.applyDiscount(code);

Technique 2: Replace Conditional with Polymorphism

•When code asks for a type/status and switches behavior, use polymorphism
•Create subclasses or strategy objects for each case
•Each subclass/strategy knows its own behavior
•Caller just tells the object to act—it acts appropriately for its type

ReplaceConditionalWithPolymorphism.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
// BEFORE: Type check + switch
void processPayment(Payment payment) {
    switch (payment.getType()) {
        case CREDIT_CARD:
            processCreditCard(
                payment.getCardNumber(), 
                payment.getAmount()
            );
            break;
        case PAYPAL:
            processPayPal(
                payment.getEmail(), 
                payment.getAmount()
            );
            break;
        case BANK_TRANSFER:
            processBankTransfer(
                payment.getAccountNumber(), 
                payment.getAmount()
            );
            break;
    }
}
 
// AFTER: Polymorphic behavior
interface Payment {
    void process(PaymentProcessor processor);
}
 
class CreditCardPayment implements Payment {
    public void process(PaymentProcessor processor) {
        processor.chargeCreditCard(cardNumber, amount);
    }
}
 
class PayPalPayment implements Payment {
    public void process(PaymentProcessor processor) {
        processor.chargePayPal(email, amount);
    }
}
 
// Caller just tells
payment.process(processor);

Technique 3: Use Callback/Visitor Pattern

•When external code needs object data for processing (formatting, serialization)
•Instead of exposing data through getters, accept a processor
•Object passes its data to the processor in a controlled way
•Object controls what data is exposed and how

CallbackPattern.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
// BEFORE: Expose data for external processing
public class Person {
    private String firstName;
    private String lastName;
    private LocalDate birthDate;
    private Address address;
    
    // Getters for everything
    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public LocalDate getBirthDate() { return birthDate; }
    public Address getAddress() { return address; }
}
 
// External code assembles the data
String report = String.format("%s %s, born %s, lives at %s",
    person.getFirstName(),
    person.getLastName(),
    person.getBirthDate(),
    person.getAddress()
);
 
 
// AFTER: Accept a visitor/formatter
public class Person {
    private String firstName;
    private String lastName;
    private LocalDate birthDate;
    private Address address;
    
    public void describeTo(PersonFormatter formatter) {
        formatter.addName(firstName, lastName);
        formatter.addBirthDate(birthDate);
        address.describeTo(formatter);  // Tell pattern continues
    }
}
 
// Usage
PersonFormatter formatter = new ReportFormatter();
person.describeTo(formatter);
String report = formatter.getResult();

Technique 4: Provide Predicates Instead of Properties

•Instead of getStatus(), provide isActive(), isPending(), canBeEdited()
•Predicate methods encapsulate the logic of what status means
•Callers express intent, not implementation
•Status representation can change without affecting callers

PredicatesInsteadOfProperties.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
// BEFORE: Expose status, caller interprets
if (order.getStatus() == OrderStatus.PENDING 
    || order.getStatus() == OrderStatus.ON_HOLD) {
    showEditButton();
}
 
// AFTER: Object knows what status means
if (order.canBeEdited()) {
    showEditButton();
}
 
// In Order class
public boolean canBeEdited() {
    return status == OrderStatus.PENDING 
        || status == OrderStatus.ON_HOLD;
}
 
public boolean isAwaitingPayment() {
    return status == OrderStatus.PENDING 
        && paymentStatus == PaymentStatus.UNPAID;
}
 
public boolean canBeCancelled() {
    return !isShipped() && !isDelivered();
}

Limits and Nuances

Like all principles, Tell, Don't Ask has limits. Understanding these nuances helps you apply it wisely rather than dogmatically.

Nuance 1: Presentation Layers Need Data

•UI layers must display object information—they legitimately ask for data
•Views and templates need getters to render information
•The key distinction: presentation displays data, it doesn't use it to make business decisions
•Consider: DTOs or view models that expose exactly what UI needs

PresentationLayer.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Acceptable: UI needs to display data
public class OrderView {
    public void render(Order order) {
        // Presentation needs data to display
        display("Order #" + order.getId());
        display("Status: " + order.getStatusLabel());
        display("Total: " + order.getFormattedTotal());
        
        // Not making business decisions with this data
    }
}
 
// Even better: Order provides a view model
public class Order {
    public OrderViewDTO toViewDTO() {
        return new OrderViewDTO(
            id,
            status.getLabel(),
            total.format(),
            getItemDescriptions()
        );
    }
}

Nuance 2: Some Decisions Span Objects

•Sometimes a decision legitimately involves multiple objects
•No single object has all the information needed
•Domain services or use case coordinators gather data from multiple sources
•The service is the 'telling' point—don't scatter this logic across callers

CrossObjectDecisions.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// When decision spans objects, use a domain service
public class ShippingCalculator {
    public Money calculateShipping(
            Order order, 
            Carrier carrier, 
            Warehouse warehouse) {
        
        // This decision needs data from multiple objects
        // It's okay to ask each object for relevant info
        
        Distance distance = warehouse.distanceTo(
            order.getShippingAddress()
        );
        Weight weight = order.getTotalWeight();
        
        return carrier.calculateRate(distance, weight);
    }
}
 
// The key: this logic is in ONE place (the service)
// Not scattered across multiple callers

Nuance 3: Query Methods Are Fine

•Not every getter violates Tell, Don't Ask
•Query methods that return information without triggering decisions are often appropriate
•The principle targets: getter → decision → action patterns
•Pure observation for logging, monitoring, display is generally acceptable

Nuance 4: Functional Programming Style

•In FP, data and functions are separate—asking for data is the norm
•Tell, Don't Ask is specifically an OOP principle
•In OOP, we couple data with behavior—that's the point of objects
•Hybrid styles may relax this for value objects while applying it to entities

Balance Over Dogma

Tell, Don't Ask is a guideline, not a law. Apply it to drive business logic into objects where it belongs. Don't apply it so rigidly that you create awkward APIs or violate other good design principles. The goal is maintainable, understandable code—not religious adherence to any single principle.

Tell, Don't Ask in Practice

Let's see a complete example of refactoring code from Ask-heavy to Tell-based design:

BeforeRefactoring.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
// Ask-heavy code: logic scattered in callers
public class OrderService {
    
    public void submitOrder(Order order, PaymentInfo payment) {
        // ASK: Check if order has items
        if (order.getItems().isEmpty()) {
            throw new EmptyOrderException();
        }
        
        // ASK: Calculate total (reaching into order internals)
        double total = 0;
        for (OrderItem item : order.getItems()) {
            total += item.getPrice() * item.getQuantity();
        }
        
        // ASK: Apply discounts if customer is premium
        if (order.getCustomer().getMembershipLevel() 
                == MembershipLevel.PREMIUM) {
            total = total * 0.9; // 10% off
        }
        
        // ASK: Check stock
        for (OrderItem item : order.getItems()) {
            if (inventoryService.getStock(item.getProductId()) 
                    < item.getQuantity()) {
                throw new InsufficientStockException();
            }
        }
        
        // ASK: Validate payment
        if (payment.getCardNumber() == null 
                || payment.getCardNumber().length() != 16) {
            throw new InvalidPaymentException();
        }
        
        // Process payment
        paymentService.charge(payment.getCardNumber(), total);
        
        // Update order status
        order.setStatus(OrderStatus.SUBMITTED);
        order.setSubmittedAt(LocalDateTime.now());
        order.setTotal(total);
        
        // Reserve inventory
        for (OrderItem item : order.getItems()) {
            inventoryService.reserve(
                item.getProductId(), 
                item.getQuantity()
            );
        }
        
        // Send confirmation
        emailService.send(
            order.getCustomer().getEmail(),
            "Order Confirmation",
            "Your order #" + order.getId() + " has been submitted."
        );
    }
}

Quick Reference Guide

Use this guide to quickly identify and refactor Ask patterns:

Pattern Recognition and Refactoring Guide
You See...	Ask For...	Tell Instead...
`if (obj.getX() == Y)`	State to check	`if (obj.isY())` or `obj.doIfY()`
`obj.setX(obj.getX() + 1)`	Value to modify	`obj.incrementX()` or `obj.addToX(1)`
`calculate(obj.getA(), obj.getB())`	Data for calculation	`obj.calculate()` or `obj.getCalculated()`
`obj.getA().getB().getC()`	Deeply nested data	`obj.getC()` (add delegation method)
`for (x : obj.getList())`	Collection to iterate	`obj.forEach(action)` or `obj.doForEach()`
`obj.setStatus(X); obj.setTime(Y)`	Multiple fields to set	`obj.transitionTo(X)` (handles both)

The Refactoring Question

When you're about to write obj.getX(), pause and ask: "What am I going to DO with X?" If the answer involves a decision or action, that logic probably belongs in obj.

Summary: Tell, Don't Ask

The Tell, Don't Ask principle captures the essence of good object-oriented encapsulation. Here are the key takeaways:

Key Takeaways

•Tell objects what to do, don't ask for their data — This keeps behavior with the data it operates on.
•Recognize Ask patterns — Getter + conditional, multi-getter calculations, getter chains, and feature envy are warning signs.
•Refactor by moving behavior — Push decision logic into the object that owns the data.
•Use polymorphism and callbacks — Replace type-checking conditionals with polymorphic dispatch.
•Provide predicates over properties — canEdit() instead of exposing status for callers to interpret.
•Know the limits — Presentation layers need data, some decisions span objects, and query methods are fine.

Module Complete:

You've now completed the module on Getters and Setters. You understand why accessors exist, when getters are appropriate, when to avoid setters, and how the Tell, Don't Ask principle ties these concepts together into actionable design guidance.

The key insight from this entire module: Objects should be active participants with behavior, not passive data bags that external code manipulates. When you design with this mindset, encapsulation becomes natural, code becomes more maintainable, and objects become more powerful.

Module Complete

Congratulations! You've mastered the principles behind getters and setters. You now have a framework for deciding when to expose data, when to keep it private, and how to design objects that own their behavior. The Tell, Don't Ask principle will serve as a guiding light in your object-oriented design journey.

4 / 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

4 / 4

Tell, Don't Ask Principle Introduction

A Principle That Changes How You Design

The principle states: Instead of asking an object for data and then acting on that data, tell the object what to do.

This simple reframing transforms how you think about object responsibilities and leads naturally to designs where behavior lives with the data it operates on.

What You Will Learn

Understanding Tell, Don't Ask

The Ask Pattern (Anti-pattern):

In the "Ask" pattern, code retrieves information from an object and then makes decisions based on that information:

1. Get data from object
2. Examine the data
3. Make a decision
4. Possibly modify the object or take other action

This pattern seems natural—after all, we need information to act. But it has a critical flaw: it puts the decision-making logic in the wrong place.

The Tell Pattern (Preferred):

In the "Tell" pattern, code tells the object what to do and trusts it to handle the details:

1. Tell object what outcome you want
2. Object makes decisions internally
3. Object acts or responds appropriately

This pattern keeps the logic close to the data it operates on.

AskPattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ❌ ASK Pattern
// "Let me check your state and decide"
 
if (account.getBalance() < amount) {
    throw new InsufficientFundsException();
}
account.setBalance(
    account.getBalance() - amount
);
transactionLog.record(
    account.getId(), 
    "withdrawal", 
    amount
);

TellPattern.java
1
2
3
4
5
6
7
8
9
10
// ✅ TELL Pattern
// "Please handle this withdrawal"
 
account.withdraw(amount);
 
// The object handles:
// - Balance check
// - Balance update
// - Transaction logging
// - Any other invariants

Why Tell is Better:

Single Responsibility: The withdrawal logic lives in one place—the BankAccount class—not scattered across callers.
Encapsulation Preserved: Callers don't need to know about balance, transaction logs, or validation rules. The internal implementation is hidden.
Consistency Guaranteed: Every withdrawal goes through the same logic. No caller can forget the transaction log or skip validation.
Easier Evolution: If withdrawal rules change (overdraft protection, daily limits), you modify one place.
Command Intent: withdraw(amount) expresses business intent. setBalance(getBalance() - amount) expresses mechanism.

The Mental Model

Recognizing Ask Patterns in Code

Ask patterns often hide in plain sight. Here are common signatures to watch for:

Pattern 1: Getter Followed by Conditional

•Shape: if (obj.getX() == condition) { doSomething(obj); }
•The decision logic belongs inside obj, not in the caller
•Consider: Can obj make this decision? Can obj perform the action?

GetterConditional.java
1
2
3
4
5
6
7
8
9
10
11
// ❌ ASK: Getter + conditional
if (order.getStatus() == OrderStatus.PENDING) {
    order.setStatus(OrderStatus.CONFIRMED);
    emailService.sendConfirmation(order.getCustomerEmail());
    inventoryService.reserve(order.getItems());
}
 
// ✅ TELL: Object handles its own state transition
order.confirm(emailService, inventoryService);
// Order internally checks preconditions, updates state,
// and coordinates side effects

Pattern 2: Multi-Getter Calculations

•Shape: result = calculate(obj.getA(), obj.getB(), obj.getC())
•If calculation uses multiple values from one object, it probably belongs in that object
•Consider: Should the object return the calculated result directly?

MultiGetterCalculation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Extracting data to calculate externally
double tax = calculateTax(
    order.getSubtotal(),
    order.getShippingAddress().getState(),
    order.getItems().stream()
        .map(Item::getTaxCategory)
        .collect(toList())
);
order.setTax(tax);
 
// ✅ TELL: Object knows how to calculate its own tax
order.calculateTax(taxService);
// Order provides its data to taxService internally

Pattern 3: Getter Chain Navigation

•Shape: obj.getA().getB().getC()
•Violates Law of Demeter—too much knowledge of internal structure
•Each accessor in the chain deepens coupling
•Consider: Can the first object provide what you need directly?

GetterChain.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Chain reveals deep structure
if (employee.getDepartment().getManager().getApprovalLimit() 
        >= request.getAmount()) {
    request.approve();
}
 
// ✅ TELL: Ask the right object
if (employee.canApprove(request)) {
    request.approve();
}
 
// Or even better, tell the request to seek approval
request.requestApprovalFrom(employee);

Pattern 4: Null-Check Cascades

•Shape: if (obj.getX() != null && obj.getX().getY() != null)
•Null checks before each accessor indicate structural knowledge
•Consider: Object should handle null cases internally, return Optional, or use Null Object pattern

NullCheckCascade.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ASK: Null checks cascade
String city = "Unknown";
if (user.getAddress() != null) {
    if (user.getAddress().getCity() != null) {
        city = user.getAddress().getCity();
    }
}
 
// ✅ TELL: Object handles the complexity
String city = user.getCityOrDefault("Unknown");
 
// Or with Optional
String city = user.getCity().orElse("Unknown");

Pattern 5: Feature Envy

•A method uses more features of another class than its own
•Classic code smell indicating misplaced responsibility
•The method should likely move to the class it's "envious" of

FeatureEnvy.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
// ❌ ASK: This method is envious of Order
class ReportGenerator {
    public String generateOrderSummary(Order order) {
        // Uses only Order's data
        return String.format(
            "Order %s: %d items, total $%.2f, status: %s",
            order.getId(),
            order.getItems().size(),
            order.getTotal().doubleValue(),
            order.getStatus()
        );
    }
}
 
// ✅ TELL: Move the method to where the data lives
class Order {
    public String getSummary() {
        return String.format(
            "Order %s: %d items, total $%.2f, status: %s",
            id, items.size(), total.doubleValue(), status
        );
    }
}
 
// Or use a formatting service that Order calls
class Order {
    public String format(OrderFormatter formatter) {
        return formatter.format(this);  // Double dispatch
    }
}

Refactoring Toward Tell

When you spot an Ask pattern, here are techniques to transform it into a Tell pattern:

Technique 1: Move Behavior to Data Owner

•Identify which object owns the data being examined
•Move the decision/calculation to that object
•Replace getter calls with a method call that expresses the intent
•The new method name should be a verb (action) not a noun (data)

MoveBehavior.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
// BEFORE: Logic in caller
public void applyDiscount(Order order, DiscountCode code) {
    if (order.getTotal() >= code.getMinimum() 
            && order.getCustomer().isMember()
            && code.isValid()) {
        double discount = order.getTotal() * code.getPercentage();
        order.setDiscount(discount);
    }
}
 
// AFTER: Logic moved to Order
public class Order {
    public void applyDiscount(DiscountCode code) {
        if (!canApplyDiscount(code)) {
            return;  // Or throw
        }
        this.discount = calculateDiscount(code);
    }
    
    private boolean canApplyDiscount(DiscountCode code) {
        return total.compareTo(code.getMinimum()) >= 0
            && customer.isMember()
            && code.isValid();
    }
    
    private Money calculateDiscount(DiscountCode code) {
        return total.multiply(code.getPercentage());
    }
}
 
// Caller just tells
order.applyDiscount(code);

Technique 2: Replace Conditional with Polymorphism

•When code asks for a type/status and switches behavior, use polymorphism
•Create subclasses or strategy objects for each case
•Each subclass/strategy knows its own behavior
•Caller just tells the object to act—it acts appropriately for its type

ReplaceConditionalWithPolymorphism.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
// BEFORE: Type check + switch
void processPayment(Payment payment) {
    switch (payment.getType()) {
        case CREDIT_CARD:
            processCreditCard(
                payment.getCardNumber(), 
                payment.getAmount()
            );
            break;
        case PAYPAL:
            processPayPal(
                payment.getEmail(), 
                payment.getAmount()
            );
            break;
        case BANK_TRANSFER:
            processBankTransfer(
                payment.getAccountNumber(), 
                payment.getAmount()
            );
            break;
    }
}
 
// AFTER: Polymorphic behavior
interface Payment {
    void process(PaymentProcessor processor);
}
 
class CreditCardPayment implements Payment {
    public void process(PaymentProcessor processor) {
        processor.chargeCreditCard(cardNumber, amount);
    }
}
 
class PayPalPayment implements Payment {
    public void process(PaymentProcessor processor) {
        processor.chargePayPal(email, amount);
    }
}
 
// Caller just tells
payment.process(processor);

Technique 3: Use Callback/Visitor Pattern

•When external code needs object data for processing (formatting, serialization)
•Instead of exposing data through getters, accept a processor
•Object passes its data to the processor in a controlled way
•Object controls what data is exposed and how

CallbackPattern.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
// BEFORE: Expose data for external processing
public class Person {
    private String firstName;
    private String lastName;
    private LocalDate birthDate;
    private Address address;
    
    // Getters for everything
    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public LocalDate getBirthDate() { return birthDate; }
    public Address getAddress() { return address; }
}
 
// External code assembles the data
String report = String.format("%s %s, born %s, lives at %s",
    person.getFirstName(),
    person.getLastName(),
    person.getBirthDate(),
    person.getAddress()
);
 
 
// AFTER: Accept a visitor/formatter
public class Person {
    private String firstName;
    private String lastName;
    private LocalDate birthDate;
    private Address address;
    
    public void describeTo(PersonFormatter formatter) {
        formatter.addName(firstName, lastName);
        formatter.addBirthDate(birthDate);
        address.describeTo(formatter);  // Tell pattern continues
    }
}
 
// Usage
PersonFormatter formatter = new ReportFormatter();
person.describeTo(formatter);
String report = formatter.getResult();

Technique 4: Provide Predicates Instead of Properties

•Instead of getStatus(), provide isActive(), isPending(), canBeEdited()
•Predicate methods encapsulate the logic of what status means
•Callers express intent, not implementation
•Status representation can change without affecting callers

PredicatesInsteadOfProperties.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
// BEFORE: Expose status, caller interprets
if (order.getStatus() == OrderStatus.PENDING 
    || order.getStatus() == OrderStatus.ON_HOLD) {
    showEditButton();
}
 
// AFTER: Object knows what status means
if (order.canBeEdited()) {
    showEditButton();
}
 
// In Order class
public boolean canBeEdited() {
    return status == OrderStatus.PENDING 
        || status == OrderStatus.ON_HOLD;
}
 
public boolean isAwaitingPayment() {
    return status == OrderStatus.PENDING 
        && paymentStatus == PaymentStatus.UNPAID;
}
 
public boolean canBeCancelled() {
    return !isShipped() && !isDelivered();
}

Limits and Nuances

Like all principles, Tell, Don't Ask has limits. Understanding these nuances helps you apply it wisely rather than dogmatically.

Nuance 1: Presentation Layers Need Data

•UI layers must display object information—they legitimately ask for data
•Views and templates need getters to render information
•The key distinction: presentation displays data, it doesn't use it to make business decisions
•Consider: DTOs or view models that expose exactly what UI needs

PresentationLayer.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Acceptable: UI needs to display data
public class OrderView {
    public void render(Order order) {
        // Presentation needs data to display
        display("Order #" + order.getId());
        display("Status: " + order.getStatusLabel());
        display("Total: " + order.getFormattedTotal());
        
        // Not making business decisions with this data
    }
}
 
// Even better: Order provides a view model
public class Order {
    public OrderViewDTO toViewDTO() {
        return new OrderViewDTO(
            id,
            status.getLabel(),
            total.format(),
            getItemDescriptions()
        );
    }
}

Nuance 2: Some Decisions Span Objects

•Sometimes a decision legitimately involves multiple objects
•No single object has all the information needed
•Domain services or use case coordinators gather data from multiple sources
•The service is the 'telling' point—don't scatter this logic across callers

CrossObjectDecisions.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// When decision spans objects, use a domain service
public class ShippingCalculator {
    public Money calculateShipping(
            Order order, 
            Carrier carrier, 
            Warehouse warehouse) {
        
        // This decision needs data from multiple objects
        // It's okay to ask each object for relevant info
        
        Distance distance = warehouse.distanceTo(
            order.getShippingAddress()
        );
        Weight weight = order.getTotalWeight();
        
        return carrier.calculateRate(distance, weight);
    }
}
 
// The key: this logic is in ONE place (the service)
// Not scattered across multiple callers

Nuance 3: Query Methods Are Fine

•Not every getter violates Tell, Don't Ask
•Query methods that return information without triggering decisions are often appropriate
•The principle targets: getter → decision → action patterns
•Pure observation for logging, monitoring, display is generally acceptable

Nuance 4: Functional Programming Style

•In FP, data and functions are separate—asking for data is the norm
•Tell, Don't Ask is specifically an OOP principle
•In OOP, we couple data with behavior—that's the point of objects
•Hybrid styles may relax this for value objects while applying it to entities

Balance Over Dogma

Tell, Don't Ask in Practice

Let's see a complete example of refactoring code from Ask-heavy to Tell-based design:

BeforeRefactoring.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
// Ask-heavy code: logic scattered in callers
public class OrderService {
    
    public void submitOrder(Order order, PaymentInfo payment) {
        // ASK: Check if order has items
        if (order.getItems().isEmpty()) {
            throw new EmptyOrderException();
        }
        
        // ASK: Calculate total (reaching into order internals)
        double total = 0;
        for (OrderItem item : order.getItems()) {
            total += item.getPrice() * item.getQuantity();
        }
        
        // ASK: Apply discounts if customer is premium
        if (order.getCustomer().getMembershipLevel() 
                == MembershipLevel.PREMIUM) {
            total = total * 0.9; // 10% off
        }
        
        // ASK: Check stock
        for (OrderItem item : order.getItems()) {
            if (inventoryService.getStock(item.getProductId()) 
                    < item.getQuantity()) {
                throw new InsufficientStockException();
            }
        }
        
        // ASK: Validate payment
        if (payment.getCardNumber() == null 
                || payment.getCardNumber().length() != 16) {
            throw new InvalidPaymentException();
        }
        
        // Process payment
        paymentService.charge(payment.getCardNumber(), total);
        
        // Update order status
        order.setStatus(OrderStatus.SUBMITTED);
        order.setSubmittedAt(LocalDateTime.now());
        order.setTotal(total);
        
        // Reserve inventory
        for (OrderItem item : order.getItems()) {
            inventoryService.reserve(
                item.getProductId(), 
                item.getQuantity()
            );
        }
        
        // Send confirmation
        emailService.send(
            order.getCustomer().getEmail(),
            "Order Confirmation",
            "Your order #" + order.getId() + " has been submitted."
        );
    }
}

Quick Reference Guide

Use this guide to quickly identify and refactor Ask patterns:

Pattern Recognition and Refactoring Guide
You See...	Ask For...	Tell Instead...
`if (obj.getX() == Y)`	State to check	`if (obj.isY())` or `obj.doIfY()`
`obj.setX(obj.getX() + 1)`	Value to modify	`obj.incrementX()` or `obj.addToX(1)`
`calculate(obj.getA(), obj.getB())`	Data for calculation	`obj.calculate()` or `obj.getCalculated()`
`obj.getA().getB().getC()`	Deeply nested data	`obj.getC()` (add delegation method)
`for (x : obj.getList())`	Collection to iterate	`obj.forEach(action)` or `obj.doForEach()`
`obj.setStatus(X); obj.setTime(Y)`	Multiple fields to set	`obj.transitionTo(X)` (handles both)

The Refactoring Question

When you're about to write obj.getX(), pause and ask: "What am I going to DO with X?" If the answer involves a decision or action, that logic probably belongs in obj.

Summary: Tell, Don't Ask

The Tell, Don't Ask principle captures the essence of good object-oriented encapsulation. Here are the key takeaways:

Key Takeaways

•Tell objects what to do, don't ask for their data — This keeps behavior with the data it operates on.
•Recognize Ask patterns — Getter + conditional, multi-getter calculations, getter chains, and feature envy are warning signs.
•Refactor by moving behavior — Push decision logic into the object that owns the data.
•Use polymorphism and callbacks — Replace type-checking conditionals with polymorphic dispatch.
•Provide predicates over properties — canEdit() instead of exposing status for callers to interpret.
•Know the limits — Presentation layers need data, some decisions span objects, and query methods are fine.

Module Complete:

Module Complete

4 / 4