Problem: Behavior Depends on State - State Pattern | OneNoughtOne

0/246

System Design (LLD)Behavioral Patterns

State Pattern

LevelIntermediate

Duration55 mins

TopicBehavioral Patterns

1 / 4

Problem: Behavior Depends on State

When Objects Must Change Their Behavior

Consider a seemingly simple scenario: you're building a document editor, and a document can be in different states—Draft, Under Review, Approved, or Published. Each state determines what actions are available and how the document responds to those actions.

In the Draft state, anyone can edit the document. Under Review, only reviewers can add comments. Once Approved, the document is read-only except for administrators. After Publishing, it's completely immutable.

This sounds straightforward until you start implementing it. Suddenly, every method in your Document class needs conditional logic checking the current state. The edit() method has four branches. The approve() method has four branches. The publish() method has four branches. Your clean, focused class becomes a labyrinth of conditionals where every operation must first ask: "What state am I in?"

What You Will Learn

By the end of this page, you will understand why state-dependent behavior creates deep structural problems in object-oriented design. You'll see how naive conditional approaches violate fundamental design principles, become maintenance nightmares, and resist testability. This understanding is essential before we explore how the State Pattern elegantly resolves these issues.

The Nature of State-Dependent Behavior

State-dependent behavior is ubiquitous in software systems. An object's state represents its current condition or mode at any given moment, and this state fundamentally determines how the object responds to requests.

What makes behavior state-dependent?

Behavior is state-dependent when:

The same method call produces different results based on internal conditions
Available operations vary depending on the object's current mode
Transitions between modes follow specific rules that constrain possible sequences
The object's identity remains constant while its behavior changes dramatically

This is fundamentally different from simple conditional branching. We're not just choosing between two options once—we're dealing with a continuous behavioral metamorphosis where the object essentially becomes a different actor while retaining its identity.

State-Dependent Behavior Across Domains
Domain	Entity	States	State-Dependent Behavior
E-commerce	Order	Pending, Paid, Shipped, Delivered, Cancelled	cancel() works in Pending/Paid, illegal in Delivered
Networking	TCP Connection	Closed, Listen, SYN_Sent, Established, Close_Wait	send() only works in Established state
Gaming	Character	Alive, Stunned, Dead, Invulnerable	attack() has no effect when Dead or Stunned
Media	Video Player	Stopped, Playing, Paused, Buffering	pause() only meaningful when Playing
Finance	Account	Active, Frozen, Closed, Overdrawn	withdraw() rejected when Frozen or Closed
IoT	Smart Thermostat	Heating, Cooling, Idle, Away, Sleep	setTemperature() behavior varies by mode

The key insight: In each of these examples, the operations remain the same (cancel, send, attack, pause, withdraw, setTemperature), but their implementations vary dramatically based on state. The operation's signature doesn't change—its semantics do.

This behavioral polymorphism based on internal state is the phenomenon we must model. The question is: how do we model it cleanly?

State vs. Type

A critical distinction: we're discussing runtime behavioral variation, not static type hierarchies. A connection doesn't change its class from TcpConnection to UdpConnection—it remains a TcpConnection throughout its lifecycle. But its behavior when receiving packets changes fundamentally based on whether it's in the ESTABLISHED or CLOSE_WAIT state. This is dynamic, not static, polymorphism.

The Naive Approach: Conditional Logic

When developers first encounter state-dependent behavior, the natural instinct is to use conditional statements. After all, if we need different behavior based on a variable, a switch statement or if-else chain seems like the obvious solution.

Let's examine this approach in detail with a realistic example: modeling a vending machine.

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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
// Naive implementation: State modeled as enum with conditionals everywhere
enum VendingMachineState {
    IDLE,           // Waiting for coins
    HAS_COINS,      // Coins inserted, waiting for selection
    DISPENSING,     // Dispensing product
    OUT_OF_STOCK    // Product unavailable
}
 
class VendingMachine {
    private state: VendingMachineState = VendingMachineState.IDLE;
    private balance: number = 0;
    private inventory: Map<string, number> = new Map();
 
    insertCoin(amount: number): void {
        // Different behavior based on current state
        switch (this.state) {
            case VendingMachineState.IDLE:
                this.balance += amount;
                this.state = VendingMachineState.HAS_COINS;
                console.log(`Coin accepted. Balance: ${this.balance}`);
                break;
 
            case VendingMachineState.HAS_COINS:
                this.balance += amount;
                console.log(`Additional coin accepted. Balance: ${this.balance}`);
                break;
 
            case VendingMachineState.DISPENSING:
                console.log("Please wait, dispensing in progress...");
                // Coin is rejected during dispensing
                break;
 
            case VendingMachineState.OUT_OF_STOCK:
                console.log("Machine is out of stock. Returning coin.");
                // Return the coin immediately
                break;
        }
    }
 
    selectProduct(productId: string): void {
        switch (this.state) {
            case VendingMachineState.IDLE:
                console.log("Please insert coins first.");
                break;
 
            case VendingMachineState.HAS_COINS:
                const price = this.getPrice(productId);
                const stock = this.inventory.get(productId) ?? 0;
 
                if (stock === 0) {
                    console.log("Product out of stock.");
                    this.state = VendingMachineState.OUT_OF_STOCK;
                } else if (this.balance >= price) {
                    this.state = VendingMachineState.DISPENSING;
                    this.dispenseProduct(productId);
                    this.balance -= price;
                    this.state = this.balance > 0 
                        ? VendingMachineState.HAS_COINS 
                        : VendingMachineState.IDLE;
                } else {
                    console.log(`Insufficient balance. Need ${price - this.balance} more.`);
                }
                break;
 
            case VendingMachineState.DISPENSING:
                console.log("Please wait, dispensing in progress...");
                break;
 
            case VendingMachineState.OUT_OF_STOCK:
                console.log("Machine is out of stock. Please refund your coins.");
                break;
        }
    }
 
    refund(): void {
        switch (this.state) {
            case VendingMachineState.IDLE:
                console.log("No coins to refund.");
                break;
 
            case VendingMachineState.HAS_COINS:
                console.log(`Refunding ${this.balance} cents.`);
                this.balance = 0;
                this.state = VendingMachineState.IDLE;
                break;
 
            case VendingMachineState.DISPENSING:
                console.log("Cannot refund during dispensing.");
                break;
 
            case VendingMachineState.OUT_OF_STOCK:
                console.log(`Refunding ${this.balance} cents.`);
                this.balance = 0;
                this.state = VendingMachineState.IDLE;
                break;
        }
    }
 
    // ... many more methods, each with similar switch statements
}

At first glance, this code seems acceptable. It's readable, the logic is explicit, and it works correctly. But hidden within this straightforward implementation are structural time bombs waiting to detonate as the system grows.

The Problems with Conditional State Management

The conditional approach to state-dependent behavior creates cascading problems that compound over time. These aren't minor inconveniences—they represent fundamental violations of sound object-oriented design principles.

Fundamental Problems with Conditional State Logic

•Open/Closed Principle Violation — Adding a new state (e.g., MAINTENANCE_MODE) requires modifying every method with state-dependent logic. You cannot extend behavior without modifying existing code.
•Single Responsibility Principle Violation — The class now has two responsibilities: doing its job AND managing state transitions. Each method contains both business logic AND state machine logic.
•Scattered State Logic — Understanding how the DISPENSING state works requires reading every method in the class. State behavior is distributed across the entire codebase.
•Duplicated Transition Logic — The same transition rules are repeated across methods. If the rule 'you cannot do X while DISPENSING' changes, you must find and update every occurrence.
•Testing Complexity — To test one state thoroughly, you must navigate through conditional branches in every method. State-specific test coverage becomes difficult to isolate.
•Cognitive Overload — Developers must mentally track all possible states while reading any method. The cognitive cost of understanding the system grows exponentially with states.

The exponential growth problem:

Consider the mathematical reality. With S states and M methods, the conditional approach creates S × M conditional branches. Our vending machine has 4 states and 3 methods shown, meaning 12 branches. But real systems are larger:

States	Methods	Conditional Branches
4	5	20
6	8	48
10	12	120
15	15	225

Each branch is a potential bug location. Each branch must be tested. Each branch represents cognitive load for anyone reading the code.

The Forgetting Problem

The most insidious risk: when adding a new method, developers must remember to handle ALL states. When adding a new state, developers must remember to update ALL methods. Forgetting just one creates a runtime error or undefined behavior. The compiler can't help because switch statements with enums don't require exhaustive handling in most languages.

A Deeper Look: The Order Lifecycle

Let's examine a more complex real-world example: an e-commerce order processing system. Orders move through multiple states, each with distinct rules about what operations are permitted and what side effects they trigger.

This state machine has 13 states and numerous transitions. Now consider the operations an order must support:

cancel() — Only valid in certain states, with different side effects
updateShippingAddress() — Only before shipping
requestRefund() — Valid only after delivery, within time window
addItem() — Only in Created state
applyDiscount() — Only before payment
trackPackage() — Only after shipping
confirmDelivery() — Only in Shipped state

Using conditionals, each of these 7+ methods needs branches for all 13 states. That's 91 conditional branches just for the core operations—not counting validation, logging, event emission, and other cross-cutting concerns.

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
class Order {
    private state: OrderState;
    
    cancel(): void {
        switch (this.state) {
            case OrderState.CREATED:
                // Release inventory reservation
                this.releaseInventory();
                this.notifyCustomer("Order cancelled before payment");
                this.state = OrderState.CANCELLED;
                break;
                
            case OrderState.PAYMENT_PENDING:
                // Cancel payment hold
                this.cancelPaymentHold();
                this.releaseInventory();
                this.notifyCustomer("Order cancelled, payment voided");
                this.state = OrderState.CANCELLED;
                break;
                
            case OrderState.PAID:
                // Initiate refund
                this.initiateRefund();
                this.releaseInventory();
                this.notifyCustomer("Order cancelled, refund initiated");
                this.state = OrderState.CANCELLED;
                break;
                
            case OrderState.PROCESSING:
                // Stop warehouse, initiate refund
                this.haltWarehouseProcessing();
                this.initiateRefund();
                this.notifyCustomer("Order cancelled during processing");
                this.state = OrderState.CANCELLED;
                break;
                
            case OrderState.SHIPPED:
                throw new IllegalStateException(
                    "Cannot cancel shipped order. Please request a return instead."
                );
                
            case OrderState.DELIVERED:
            case OrderState.RETURN_REQUESTED:
            case OrderState.RETURNED:
            case OrderState.REFUNDED:
            case OrderState.COMPLETED:
                throw new IllegalStateException(
                    "Order in terminal state, cancellation not possible."
                );
                
            default:
                throw new IllegalStateException("Unknown order state");
        }
    }
    
    // Imagine 6 more methods like this, each with 13 cases...
}

This Code is Unmaintainable

If the business adds a 'Backordered' state, you must update EVERY method. If payment refund logic changes, you must find every conditional branch handling post-payment cancellation. If you want to add logging, you must add it to every branch. This code does not scale with complexity.

The Testing Nightmare

Conditional state management creates testing challenges that compound exponentially. Let's analyze what comprehensive testing actually requires.

Testing Challenges

•Setup complexity — Testing one state requires correctly initializing all preceding states
•Combinatorial explosion — Must test every state × method combination
•Transition coverage — Must verify every valid transition occurs correctly
•Invalid transition coverage — Must verify every invalid transition is rejected
•Side effect isolation — Hard to isolate state-specific side effects for verification
•Regression risk — Changes anywhere risk breaking state logic elsewhere

Test Count Analysis

•Valid operations: S × M tests (91 for order example)
•Invalid operations: S × M × (rejected cases) tests
•State transitions: 2^T tests for T transitions (thousands)
•Edge cases: Multiple per state/operation combination
•Integration: State sequences across operations
•Regression: All above, repeated for any change

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
describe('Order cancellation', () => {
    // Must test cancel() in EVERY state
    
    describe('when in CREATED state', () => {
        it('should release inventory');
        it('should notify customer with correct message');
        it('should transition to CANCELLED');
        it('should NOT attempt payment operations');
    });
    
    describe('when in PAYMENT_PENDING state', () => {
        it('should cancel payment hold');
        it('should release inventory');
        it('should notify customer with correct message');
        it('should transition to CANCELLED');
    });
    
    describe('when in PAID state', () => {
        it('should initiate refund');
        it('should release inventory');
        it('should notify customer with correct message');
        it('should transition to CANCELLED');
    });
    
    describe('when in PROCESSING state', () => {
        it('should halt warehouse processing');
        it('should initiate refund');
        it('should notify customer with correct message');
        it('should transition to CANCELLED');
    });
    
    describe('when in SHIPPED state', () => {
        it('should throw IllegalStateException');
        it('should not modify order state');
        it('should not trigger any side effects');
    });
    
    // ... 8 more state-specific describe blocks for cancel() alone
    
    // Then repeat ALL of this for every other method:
    // updateShippingAddress(), requestRefund(), addItem(), 
    // applyDiscount(), trackPackage(), confirmDelivery()...
});

The Isolation Problem

The biggest testing problem isn't test count—it's isolation. To test SHIPPED state behavior, you must first transition through CREATED → PAYMENT_PENDING → PAID → PROCESSING → SHIPPED. Any bug in earlier transitions contaminates your SHIPPED tests. You're not testing state behavior; you're testing transition chains.

Real-World Consequences

The theoretical problems translate directly into practical engineering costs. Let's examine real-world scenarios where conditional state management has created significant issues.

Engineering Costs of Conditional State Logic

•Feature velocity degradation — As states accumulate, adding new features requires changes across ever-more files. What starts as a 2-hour feature becomes a 2-day feature.
•Bug reproduction difficulty — 'It only fails when the order is in Processing AND was paid with a gift card AND has more than 3 items.' Reproducing state-dependent bugs requires complex setup.
•Onboarding friction — New developers must understand the entire state machine before safely modifying any method. The learning curve scales with system complexity.
•Refactoring paralysis — Teams become afraid to refactor because state logic is so distributed. Technical debt accumulates because cleanup is too risky.
•Silent failures — Missing switch cases don't fail at compile time. Systems quietly misbehave in unexpected states until customers report issues.
•Audit and compliance nightmares — For regulated systems, proving 'this action cannot occur in that state' requires tracing logic across the entire codebase.

Impact on Team Productivity
System Complexity	Time to Add State	Time to Add Operation	Bug Fix Time
Simple (4 states, 5 operations)	4 hours	4 hours	2 hours
Medium (8 states, 10 operations)	2 days	2 days	1 day
Complex (15 states, 20 operations)	1 week	1 week	3 days
Enterprise (30+ states, 50+ operations)	2-3 weeks	2-3 weeks	1 week

The Rewrite Temptation

Teams often reach a breaking point where management asks: 'Should we rewrite this from scratch?' The answer is usually no—rewrites are risky and expensive. But the question arises because conditional state logic has made the existing system unmaintainable. Proper state management patterns prevent reaching this point.

Recognizing When You Need a Better Solution

Not every conditional is a problem. Simple two-state toggles (enabled/disabled) or straightforward mode switches may not warrant pattern application. The key is recognizing when complexity has crossed the threshold where conditional logic becomes a liability.

Code Smells Indicating State Pattern Need

•Multiple switch statements on the same variable — When you see switch(state) in more than 2-3 methods, state logic is spreading.
•Long methods with deep conditional nesting — Methods that say 'if state is A, then if condition X, then if sub-condition Y...' are trying to encode state machines in conditionals.
•Frequent 'illegal state' exceptions — Many operations throwing exceptions for 'wrong state' indicates complex state-dependent validity.
•State variable checked before every action — When every method starts with 'first, check what state we're in', the state is dominating the design.
•Parallel state evolution — Adding a new state requires touching many files. Adding a new operation requires checking all states.
•Comments explaining state transitions — When you need comments like '// Can only reach here from PAID state', the logic has become opaque.
•State-specific magic numbers or flags — Using booleans like isProcessing, hasBeenPaid, waitingForShipment alongside a state enum suggests incomplete state modeling.

The Rule of Three States

A practical heuristic: Once you have three or more states with three or more state-dependent methods, consider the State Pattern. Below this threshold, conditionals may be simpler. Above it, the pattern's structural benefits outweigh its additional classes.

Questions to ask before applying the pattern:

Is the state finite and well-defined? States should be discrete, not continuous. If there are potentially infinite states, a different approach is needed.
Are transitions between states constrained? If any state can transition to any other, you might have a simpler mode switch rather than a true state machine.
Does behavior genuinely vary by state? If most operations are state-independent with just occasional checks, full pattern application may be overkill.
Will the state machine evolve? If states and operations are fixed forever, the overhead of the pattern may not pay off. If evolution is expected, the pattern's extensibility becomes essential.
Is the team comfortable with the pattern? Patterns require shared understanding. A well-implemented conditional approach may be better than a poorly understood pattern.

Summary: The Case for a Better Approach

We've thoroughly examined why state-dependent behavior creates structural problems when handled with conditional logic. Let's consolidate these insights:

Key Takeaways

•State-dependent behavior is pervasive — Objects frequently need to behave differently based on their internal state, with the same operation having different effects.
•Conditional approaches don't scale — While initially simple, switch/if-else state handling creates exponential complexity as states and operations grow.
•SOLID principles are violated — Adding states or operations requires modifying existing code, logic is scattered, and responsibilities are mixed.
•Testing becomes impractical — Combinatorial explosion of state × operation × transition tests, combined with setup complexity, makes comprehensive testing difficult.
•Real engineering costs emerge — Slower feature development, harder debugging, steeper onboarding, and growing technical debt.
•Recognition criteria exist — Code smells like repeated switch statements, deep conditional nesting, and frequent illegal state exceptions indicate pattern need.

What's next:

Having established the problem clearly, we're ready to explore the elegant solution: the State Pattern. In the next page, we'll see how treating each state as a separate object with its own behavior transforms the monolithic conditional approach into a clean, extensible, testable design where:

Each state encapsulates its own behavior
Adding new states requires no modification of existing code
Operations are defined once and delegated appropriately
Testing becomes state-focused and isolated
The system remains maintainable regardless of complexity

Page Complete

You now understand why state-dependent behavior creates fundamental design challenges. The conditional approach that seems natural at first creates maintenance nightmares, testing difficulties, and violation of core design principles. Next, we'll see how the State Pattern addresses these problems through polymorphic state objects.