Tell Dont Ask - Learning Module

Loading content...

0/246

Pushing Behavior to Data

Where Should Behavior Live?

Consider this question: Where does the logic for calculating a rectangle's area belong?

Option A — In a GeometryService that takes a rectangle and computes its area:

const area = geometryService.calculateArea(rectangle);

Option B — In the Rectangle itself:

const area = rectangle.getArea();

Most developers instinctively choose Option B. The rectangle knows its own width and height—why should some external service calculate its area? The data lives in Rectangle, so the behavior should too.

This intuition captures a fundamental principle: behavior should gravitate to where the data it operates on resides. Yet in complex systems, this intuition gets buried under layers of 'service' classes, 'manager' objects, and 'utility' helpers—all of which pull behavior away from data.

What You Will Learn

By the end of this page, you will understand why behavior separated from its data creates maintenance nightmares, how to identify misplaced behavior in existing code, systematic techniques for relocating logic to where it belongs, and how proper co-location of behavior and data creates cohesive, maintainable objects.

The Co-Location Principle

At the heart of object-oriented programming lies a simple but profound idea: objects bundle data and the behavior that operates on that data together. This bundling isn't arbitrary—it's the mechanism that makes encapsulation possible.

When behavior lives with its data:

The data can be hidden (private)
The behavior can access data directly without exposing it
Changes to data representation don't ripple through the codebase
The object becomes a coherent unit of responsibility

When behavior is separated from its data:

The data must be exposed (via getters) for external logic to use
Multiple places contain logic for the same data
Changes to data require updating all places that use it
Objects become fragmented across the codebase

The Information Expert Pattern

The GRASP principle 'Information Expert' formalizes this: assign responsibility to the class that has the information needed to fulfill it. If an object has the data, it should have the behavior. If behavior requires data from multiple objects, assign it to the object with the most relevant information—or create a new abstraction that bundles the needed data together.

The Cohesion Dimension:

'Pushing behavior to data' is another way of saying 'increase cohesion.' High cohesion means a class's methods and properties are strongly related—they all revolve around a unified concept.

When you pull behavior away from data:

The data class becomes less cohesive (it's now just a container)
The behavior class becomes artifically cohesive around operations it shouldn't own
The system's conceptual integrity fractures

When you push behavior to data:

Each class has a complete, coherent set of responsibilities
Classes align with domain concepts
The code mirrors how you naturally think about the problem

Identifying Misplaced Behavior

Before you can push behavior to where it belongs, you need to recognize when it's in the wrong place. Here are the diagnostic patterns that reveal misplaced behavior:

Signs of Misplaced Behavior

•Service classes with domain logic — When OrderService contains business rules about orders, that logic belongs in Order.
•Helper or Utility classes — Utilities like StringHelper.capitalize(string) suggest String should have a capitalize() method (many languages now do).
•Multiple places doing the same calculation — If three classes all compute 'days until expiration' from a date, that logic should live in a date or expiration-related object.
•Functions that take an object and return a derived value — calculateTax(order) suggests order.calculateTax() would be more appropriate.
•Conditionals based on object state — if (user.getRole() === 'admin') scattered throughout suggests user.hasAdminPermission() or polymorphism.
•Data Transfer Objects (DTOs) with no behavior — While DTOs are fine for crossing boundaries, domain objects should never be behavior-free.
•'Manager' or 'Handler' classes — Names like UserManager or OrderHandler often indicate behavior stolen from User and Order.

The Locality Test:

To diagnose whether behavior is misplaced, apply this test:

Identify the data the behavior uses
Identify where that data lives (which class)
Ask: Could this behavior live in that class?
If yes, it probably should

If a method primarily uses data from another class, that's a strong signal for relocation. The goal is for each method to primarily use data from its own class.

misplaced-behavior-example.ts
TypeScript
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
// Misplaced: Behavior is in the wrong place
class DiscountService {
    calculateDiscount(customer: Customer): number {
        // This method uses customer data extensively
        const totalSpent = customer.getTotalSpent();
        const memberSince = customer.getMemberSince();
        const tier = customer.getTier();
        
        // Logic based entirely on Customer's data
        if (tier === 'gold') {
            return 0.2; // 20% discount
        } else if (tier === 'silver') {
            return 0.1; // 10% discount
        } else if (totalSpent > 10000) {
            return 0.05; // 5% discount for high spenders
        } else if (this.yearsAsMember(memberSince) > 5) {
            return 0.05; // 5% loyalty discount
        }
        return 0;
    }
    
    private yearsAsMember(date: Date): number {
        // More logic that should live with Customer or a Date abstraction
        return /* calculation */;
    }
}
 
// Behavior pushed to where data lives
class Customer {
    private totalSpent: number;
    private memberSince: Date;
    private tier: CustomerTier;
    
    getDiscount(): number {
        // Customer knows its own discount rules
        if (this.tier === CustomerTier.Gold) {
            return 0.2;
        } else if (this.tier === CustomerTier.Silver) {
            return 0.1;
        } else if (this.totalSpent > 10000) {
            return 0.05;
        } else if (this.yearsAsMember() > 5) {
            return 0.05;
        }
        return 0;
    }
    
    private yearsAsMember(): number {
        // Encapsulated - Customer calculates its own tenure
        const now = new Date();
        return now.getFullYear() - this.memberSince.getFullYear();
    }
}

The Relocation Refactoring

Moving behavior to where it belongs is often called the Move Method refactoring. It's one of the most common and valuable refactorings in object-oriented development. Here's a systematic approach:

Move Method: Step-by-Step

•Examine the method — Identify all the data and methods it references from other classes
•Determine the target — The class whose data is used most heavily is usually the right destination
•Check feasibility — Ensure moving the method won't create circular dependencies or access issues
•Copy the method — Create a new method on the target class with the same body
•Adapt the body — Replace references to target.getData() with direct field access (since you're now inside the target)
•Replace original — Change the original method to delegate to the new location: return target.newMethod()
•Inline if appropriate — If the original is now just a delegation, consider removing it entirely
•Test thoroughly — Ensure behavior is preserved

When the Target Isn't Obvious:

Sometimes a method uses data from multiple classes equally. In these cases:

Prefer the class with more methods using this data — Keeps the class cohesive
Consider creating a new abstraction — If the behavior represents a distinct concept, create a class for it
Use composition — Perhaps a new object that combines the relevant data
Keep it where it is but have it tell, not ask — Let it delegate to each relevant object

There's rarely a single correct answer—design involves judgment. But the goal remains: minimize the extraction of data, maximize delegation of behavior.

relocation-refactoring.ts
TypeScript
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
// Before: Method in ReportGenerator uses mostly Order data
class ReportGenerator {
    generateOrderSummary(order: Order): string {
        const items = order.getItems();
        const customer = order.getCustomer();
        const total = order.getTotal();
        const date = order.getDate();
        
        let summary = `Order from ${customer.getName()} on ${date}
`;
        summary += items.map(i => 
            `- ${i.getProduct().getName()}: $${i.getTotal()}`
        ).join('
');
        summary += `
Total: $${total}`;
        
        return summary;
    }
}
 
// After Step 1-3: Identify that Order is the target
 
// After Step 4-5: Method moved to Order
class Order {
    private items: OrderItem[];
    private customer: Customer;
    private total: number;
    private date: Date;
    
    generateSummary(): string {
        // Direct field access instead of getters
        let summary = `Order from ${this.customer.getName()} on ${this.date}
`;
        summary += this.items.map(item => 
            `- ${item.getProductName()}: $${item.getTotal()}`
        ).join('
');
        summary += `
Total: $${this.total}`;
        
        return summary;
    }
}
 
// After Step 6-7: Original can delegate or be removed
class ReportGenerator {
    generateOrderSummary(order: Order): string {
        // Now just delegates
        return order.generateSummary();
    }
    
    // ... other report methods that aren't order-specific
}

The Incremental Approach

Don't try to relocate all misplaced behavior at once. Move one method, ensure tests pass, then move the next. Incremental refactoring reduces risk and allows you to learn as you go. Each successful move builds confidence and improves the design.

Rich vs Anemic Domain Models

The ultimate consequence of not pushing behavior to data is the Anemic Domain Model anti-pattern, identified by Martin Fowler as "one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment."

In an anemic domain model:

Domain objects contain only data (fields, getters, setters)
All business logic lives in 'service' classes
Objects are essentially data structures
The 'object-oriented' code is actually procedural

The Rich Domain Model is the opposite:

Domain objects contain both data and behavior
Business logic lives in the objects that have the relevant data
Objects are true objects—intelligent entities that do things
The code is genuinely object-oriented

anemic-model.ts
TypeScript
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
// Anemic Domain Model
class Account {
    // Just data - no behavior
    private balance: number;
    private status: string;
    private overdraftLimit: number;
    
    getBalance(): number { 
        return this.balance; 
    }
    setBalance(b: number) { 
        this.balance = b; 
    }
    getStatus(): string { 
        return this.status; 
    }
    setStatus(s: string) { 
        this.status = s; 
    }
    getOverdraftLimit(): number { 
        return this.overdraftLimit; 
    }
}
 
// All logic in service
class AccountService {
    withdraw(account: Account, amount: number) {
        if (account.getStatus() !== 'active') {
            throw new Error('Inactive account');
        }
        const balance = account.getBalance();
        const limit = account.getOverdraftLimit();
        if (balance - amount < -limit) {
            throw new Error('Overdraft exceeded');
        }
        account.setBalance(balance - amount);
    }
}

rich-model.ts
TypeScript
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
// Rich Domain Model
class Account {
    private balance: number;
    private status: AccountStatus;
    private overdraftLimit: number;
    
    // Behavior WITH the data
    withdraw(amount: number): void {
        this.ensureActive();
        this.ensureWithinLimit(amount);
        this.balance -= amount;
    }
    
    private ensureActive(): void {
        if (this.status !== AccountStatus.Active) {
            throw new InactiveAccountError();
        }
    }
    
    private ensureWithinLimit(amount: number): void {
        if (this.balance - amount < -this.overdraftLimit) {
            throw new OverdraftLimitExceededError();
        }
    }
    
    // Getters only when truly needed externally
    getBalance(): number { 
        return this.balance; 
    }
}
 
// Service coordinates, doesn't contain logic
class AccountService {
    withdraw(accountId: string, amount: number) {
        const account = this.repository.find(accountId);
        account.withdraw(amount); // Tell!
        this.repository.save(account);
    }
}

Why Anemic Models Persist:

Despite being an anti-pattern, anemic models are common. Why?

Database-first thinking — ORM tools often generate entity classes from tables, which are naturally anemic
Layered architecture misunderstandings — 'Services should have logic' is a common misinterpretation
Familiarity with procedural code — Developers from procedural backgrounds find anemic models easier
Transaction script pattern — Simple CRUD apps don't suffer as much from anemic models
Testing convenience — Some find testing data-only objects easier (though this is false economy)

The problem is that as systems grow complex, anemic models amplify that complexity—logic spreads, duplication multiplies, and the domain becomes incomprehensible.

The Hidden Cost of Anemic Models

Anemic models seem simple initially. But they pay interest over time: every new feature requires understanding which service has which logic, duplicated validations appear everywhere, and the 'domain' exists only in developers' heads—not in the code. Rich models front-load design effort but compound returns over time.

Behavior in Layered Architectures

A common source of confusion is how 'pushing behavior to data' interacts with layered architectures. If domain objects have behavior, what do services do? Let's clarify the appropriate role of each layer:

Layer Responsibilities in Rich Domain Models
Layer	Appropriate Responsibilities	NOT Appropriate
Domain Objects	Business rules, validations, state transitions, domain calculations, invariant enforcement	Persistence, external service calls, UI concerns, cross-cutting concerns
Application Services	Use case orchestration, transaction management, security checks, calling domain methods, coordinating between aggregates	Business rules, domain calculations—these belong in domain objects
Infrastructure	Persistence implementation, external APIs, messaging, file systems	Business logic—infrastructure is mechanistic, not intelligent
Presentation	UI rendering, input handling, data formatting for display	Business decisions—these should be delegated to domain

The Service Layer's True Role:

In a rich domain model, services become thin orchestrators rather than fat logic containers. They:

Retrieve domain objects from repositories
Tell domain objects what to do (the actual business logic happens inside the domain object)
Persist the result through repositories
Handle cross-cutting concerns like transactions and security

Services answer 'what use cases exist?' but domain objects answer 'what are the business rules?'

thin-service-example.ts
TypeScript
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
// A properly thin application service
class OrderApplicationService {
    constructor(
        private orderRepository: OrderRepository,
        private inventoryService: InventoryService,
        private eventPublisher: EventPublisher
    ) {}
    
    async processOrder(orderId: string): Promise<void> {
        // 1. Retrieve the domain object
        const order = await this.orderRepository.findById(orderId);
        if (!order) {
            throw new OrderNotFoundError(orderId);
        }
        
        // 2. Tell the domain object what to do (business logic is inside)
        order.process();  // Order knows how to process itself
        
        // 3. Tell other services (they know their logic too)
        await this.inventoryService.reserveItems(order.getItems());
        
        // 4. Persist the result
        await this.orderRepository.save(order);
        
        // 5. Handle cross-cutting concerns
        await this.eventPublisher.publish(new OrderProcessedEvent(order));
    }
}
 
// Order contains the real business logic
class Order {
    private status: OrderStatus;
    private items: OrderItem[];
    private processedAt?: Date;
    
    process(): void {
        // Business rule: can only process pending orders
        if (this.status !== OrderStatus.Pending) {
            throw new InvalidOrderStateError(
                `Cannot process order in status ${this.status}`
            );
        }
        
        // Business rule: must have items
        if (this.items.length === 0) {
            throw new EmptyOrderError();
        }
        
        // State transition with invariant enforcement
        this.status = OrderStatus.Processing;
        this.processedAt = new Date();
        
        // Tell items to process themselves
        this.items.forEach(item => item.markProcessing());
    }
}

Domain-Driven Design Alignment

This layering follows Domain-Driven Design principles. The domain layer is the heart of the application, containing the 'ubiquitous language' and business rules. Application services exist to support the domain, not to contain the logic themselves. Infrastructure serves both. When behavior is pushed to data, DDD emerges naturally.

Behavior Location Heuristics

Deciding where behavior belongs isn't always straightforward. Here are practical heuristics to guide your decisions:

Where Should This Behavior Live?

•Whose data is it? — If the behavior primarily uses data from one object, that object should own the behavior.
•Who changes as a result? — Behavior often belongs to the object whose state changes as a result of the action.
•Who in the domain would do this? — Think about the real-world analog. In reality, who performs this action?
•What's the business statement? — 'An order calculates its total' suggests order.calculateTotal(). 'A calculator calculates order totals' suggests anemia.
•Where would you look for it? — New developers should find behavior where they expect it. If 'discount logic' lives in Order, that's intuitive.
•What minimizes dependencies? — Place behavior where it requires the fewest external dependencies.
•What supports polymorphism? — If different subtypes should behave differently, the behavior belongs in the base class (as abstract or virtual).

Handling Multi-Object Behavior:

Some behavior genuinely involves multiple objects. For example, 'transfer money between accounts' involves two accounts. Options include:

Put it in one of them: sourceAccount.transferTo(targetAccount, amount) — Source 'owns' the transfer action
Create a dedicated object: new Transfer(source, target, amount).execute() — Transfer encapsulates the operation
Use a domain service: bankingService.transfer(source, target, amount) — Appropriate when no single object makes sense

Even with domain services, preference goes to delegating: the service uses source.withdraw() and target.deposit() rather than manipulating account internals directly.

The Refactoring Safety Net

If you're unsure, pick a reasonable location and continue. As you develop more of the system, misplacement becomes obvious: you'll see feature envy, duplication, or awkward dependencies. Then refactor. Good tests make relocation safe. Don't let analysis paralysis prevent progress.

Practical Refactoring Patterns

Let's examine common patterns for pushing behavior to data in real codebases. These patterns appear repeatedly across domains and provide templates for refactoring:

Problem: External code checks object type and branches accordingly.

Solution: Push behavior into subclasses and use polymorphism.

conditional-to-polymorphism.ts
TypeScript
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
// Before: Conditional based on type
class PaymentProcessor {
    process(payment: Payment): void {
        if (payment.getType() === 'credit') {
            // Credit card logic
            this.validateCard(payment.getCardNumber());
            this.chargeCard(payment.getCardNumber(), payment.getAmount());
        } else if (payment.getType() === 'bank') {
            // Bank transfer logic
            this.validateAccount(payment.getBankAccount());
            this.transfer(payment.getBankAccount(), payment.getAmount());
        } else if (payment.getType() === 'crypto') {
            // Crypto logic
            this.validateWallet(payment.getWalletAddress());
            this.sendCrypto(payment.getWalletAddress(), payment.getAmount());
        }
    }
}
 
// After: Polymorphism - each payment knows how to process itself
abstract class Payment {
    protected amount: number;
    
    abstract process(): void;
}
 
class CreditCardPayment extends Payment {
    private cardNumber: string;
    
    process(): void {
        this.validateCard();
        this.chargeCard();
    }
    
    private validateCard(): void { /* ... */ }
    private chargeCard(): void { /* ... */ }
}
 
class BankTransferPayment extends Payment {
    private bankAccount: string;
    
    process(): void {
        this.validateAccount();
        this.transfer();
    }
    
    private validateAccount(): void { /* ... */ }
    private transfer(): void { /* ... */ }
}
 
// Processor now just tells
class PaymentProcessor {
    process(payment: Payment): void {
        payment.process();  // Polymorphism does the rest
    }
}

Summary: Pushing Behavior to Data

We've explored the principle of co-locating behavior with data. Let's consolidate the key insights:

Key Takeaways

•Behavior belongs where data lives — This is the essence of encapsulation in object-oriented design.
•'Information Expert' assigns responsibility to the class with the relevant data.
•Misplaced behavior shows up as service classes with logic, utility classes, and duplicated calculations.
•Move Method refactoring relocates behavior to appropriate objects systematically.
•Rich domain models have behavior-full domain objects; anemic models have data-only objects.
•Services should orchestrate, not contain business logic—they tell domain objects what to do.
•Heuristics guide placement: who owns the data, who changes, what's the business statement.
•Common patterns: conditional to polymorphism, calculation extraction, self-validating objects.

What's Next:

Now that we understand both the interaction style (tell, don't ask) and the placement principle (behavior with data), we'll see Tell, Don't Ask in action through concrete examples. We'll examine real-world scenarios across different domains and see how TDA transforms code from procedural to truly object-oriented.

Page Complete

You now understand why behavior should live where data lives, how to identify misplaced behavior, and systematic techniques for relocating logic to appropriate objects. You can distinguish rich from anemic domain models and know how layered architectures work with behavior-rich objects. Next, we'll see these principles applied in real-world examples.