Problem — Adding Behavior Dynamically - Decorator Pattern | OneNoughtOne

0/246

System Design LLDStructural Patterns

Decorator Pattern

LevelIntermediate

Duration60 mins

TopicStructural Patterns

1 / 4

Problem — Adding Behavior Dynamically

The Fundamental Challenge of Object Extension

In software engineering, change is the only constant. Requirements evolve, features accumulate, and systems grow in unexpected directions. One of the most common challenges we face is how to add new behavior to existing objects without destabilizing the codebase.

This isn't merely a theoretical concern—it's a daily reality in production systems. Consider what happens when:

A simple logging system needs to add compression, encryption, and buffering capabilities
A UI component must support multiple rendering styles, animations, and accessibility features
A data access layer requires caching, validation, and audit trails
A notification service needs formatting, filtering, and delivery options

The intuitive approach—inheritance—quickly reveals fundamental limitations that can trap development teams in architectural dead ends.

What You Will Learn

By the end of this page, you will understand why adding behavior through inheritance leads to class explosion, recognize the symptoms of this problem in real codebases, and comprehend the fundamental constraints that make dynamic behavior extension necessary. This foundation prepares you for the Decorator pattern solution.

The Inheritance Trap

When we first learn object-oriented programming, inheritance appears as a powerful mechanism for code reuse and extension. Need a ColoredWindow? Extend Window. Need a BorderedWindow? Extend Window. The syntax is elegant, the intent is clear, and for simple hierarchies, this works perfectly.

But what happens when behaviors need to combine?

Let's walk through a realistic scenario. Imagine we're building a text component system for a document editor. Our base class is TextComponent, which renders plain text.

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
// Base component
class TextComponent {
    protected text: string;
    
    constructor(text: string) {
        this.text = text;
    }
    
    render(): string {
        return this.text;
    }
}
 
// We need bold text capability
class BoldTextComponent extends TextComponent {
    render(): string {
        return `<b>${super.render()}</b>`;
    }
}
 
// We need italic text capability
class ItalicTextComponent extends TextComponent {
    render(): string {
        return `<i>${super.render()}</i>`;
    }
}
 
// We need underlined text capability  
class UnderlinedTextComponent extends TextComponent {
    render(): string {
        return `<u>${super.render()}</u>`;
    }
}

So far, this seems reasonable. We have four classes: one base and three extensions. But now consider the requirements that arrive next week:

Bold AND italic text is needed
Bold AND underlined text is needed
Italic AND underlined text is needed
All three combined is needed

Our class count explodes:

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
// Combination classes start multiplying
class BoldItalicTextComponent extends TextComponent {
    render(): string {
        return `<b><i>${super.render()}</i></b>`;
    }
}
 
class BoldUnderlinedTextComponent extends TextComponent {
    render(): string {
        return `<b><u>${super.render()}</u></b>`;
    }
}
 
class ItalicUnderlinedTextComponent extends TextComponent {
    render(): string {
        return `<i><u>${super.render()}</u></i>`;
    }
}
 
class BoldItalicUnderlinedTextComponent extends TextComponent {
    render(): string {
        return `<b><i><u>${super.render()}</u></i></b>`;
    }
}
 
// Current class count: 8 classes for 3 features
// Pattern: 2^n combinations for n features

Exponential Growth Pattern

With just 3 optional features, we need 2³ = 8 classes (including the base). Add a fourth feature (strikethrough) and we need 2⁴ = 16 classes. A fifth feature (superscript) requires 2⁵ = 32 classes. This is unsustainable—the math works against us exponentially.

Real-World Class Explosion

The text formatting example might seem contrived, but class explosion is a genuine problem in production systems. Let's examine a more realistic scenario: stream processing in an I/O system.

Consider a file stream that needs to support various capabilities:

Stream Capabilities Required

•Buffering — Reduce I/O operations by batching reads/writes
•Compression — Reduce data size (gzip, zlib, lz4)
•Encryption — Secure data in transit/at rest (AES, ChaCha20)
•Checksumming — Verify data integrity (CRC32, SHA256)
•Rate Limiting — Control throughput for fair resource usage
•Logging — Record operations for debugging/auditing
•Metrics — Collect performance statistics
•Retry Logic — Handle transient failures

With 8 optional capabilities, inheritance requires 2⁸ = 256 distinct classes to cover all combinations. This isn't hypothetical—early Java I/O libraries struggled with this exact problem before adopting decorator-based designs.

But the numbers tell only part of the story. Let's examine the deeper problems:

Problems with Inheritance-Based Extension
Problem	Description	Consequence
Class Count Maintenance	Each new feature doubles the class count	Adding feature #9 requires creating 256 new classes
Code Duplication	Combination classes duplicate logic from multiple parents	Bug fixes must be applied across dozens of files
Static Binding	Combinations are fixed at compile time	Cannot add/remove capabilities at runtime based on context
Testing Complexity	Each class requires dedicated test suites	256 classes × tests per class = unmanageable test matrix
Naming Nightmare	Names encode combinations: BufferedCompressedEncryptedChecksummedStream	Unreadable, unmaintainable, error-prone
Inflexible Ordering	Subclass determines fixed feature order	Cannot compress-then-encrypt vs encrypt-then-compress dynamically

The Core Violation

This approach violates the Open/Closed Principle at its foundation. Every new feature requires modifying (or massively extending) the existing class structure. The system is closed for extension precisely where it should be open.

The Static vs Dynamic Problem

Inheritance creates a static relationship—the connection between parent and child is fixed at compile time. This rigidity conflicts with real-world requirements that demand runtime flexibility.

Consider these runtime scenarios that inheritance cannot address:

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
// Scenario 1: User-configurable behavior
// User preferences determine which features are active
function createStreamFromUserPreferences(
    prefs: UserPreferences
): Stream {
    // With inheritance, we'd need massive switch/case logic:
    if (prefs.buffered && prefs.encrypted && prefs.compressed) {
        return new BufferedEncryptedCompressedStream();
    } else if (prefs.buffered && prefs.encrypted) {
        return new BufferedEncryptedStream();
    } else if (prefs.buffered && prefs.compressed) {
        return new BufferedCompressedStream();
    }
    // ... 256 branches for all combinations
    
    // This is unmaintainable and violates OCP
}
 
// Scenario 2: Conditional behavior based on runtime state
// Encryption only when data is sensitive
function processDocument(doc: Document): Stream {
    const baseStream = new FileStream(doc.path);
    
    // How do we conditionally add encryption?
    // With inheritance, impossible without pre-built combinations
    if (doc.classification === 'SECRET') {
        // Need: "add encryption to existing stream"
        // Have: "pick the right pre-built class"
    }
    
    return baseStream; // Wrong—no way to add behavior
}
 
// Scenario 3: Feature toggling
// Enable/disable behaviors based on feature flags
function getDataStream(config: FeatureFlags): Stream {
    // Features can be toggled on/off per deployment
    // Cannot predict combinations needed at compile time
    const needsCompression = config.isEnabled('compression');
    const needsEncryption = config.isEnabled('encryption');
    const needsMetrics = config.isEnabled('metrics');
    
    // Inheritance cannot handle this dynamically
}

The fundamental mismatch:

Inheritance is designed for is-a relationships that are permanent and intrinsic. A Cat is-a Animal always and forever. But many behaviors are has-a or uses-a relationships that are contextual and optional. A stream uses compression when needed, but isn't fundamentally a compressed thing.

When we model optional behaviors as inheritance, we conflate identity with capability. The result is bloated hierarchies that encode combinations rather than features.

The Key Insight

We need a mechanism that treats behaviors as attachable components rather than inherited identities. Instead of creating new types for each combination, we want to compose behaviors onto objects at runtime—like attaching accessories to a core object rather than building new object types.

Single Inheritance Constraints

Most mainstream object-oriented languages—Java, C#, TypeScript, Python (in practice)—use single inheritance for classes. You can extend only one parent class. This constraint makes the combinatorial problem even more severe.

Let's examine why multiple inheritance wouldn't solve the problem anyway:

Why Multiple Inheritance Fails

•Diamond Problem — Ambiguous method resolution when multiple parents share a common ancestor
•State Conflicts — Multiple parents may assume incompatible internal state management
•Method Collision — Same method name in multiple parents creates ambiguity
•Compilation Complexity — Linearization algorithms (C3) add mental overhead
•Still Static — Even with MI, combinations are fixed at compile time

What We Actually Need

•Runtime composition — Add behaviors when objects are created or executing
•Order control — Determine feature application sequence dynamically
•Additive behavior — Layer new behavior without modifying existing code
•Transparency — Decorated objects should be usable like originals
•Selective application — Apply only the behaviors needed in each context

Even languages with multiple inheritance (C++, Python via mixins) don't solve the core problem. We're not seeking more powerful inheritance—we're seeking an alternative to inheritance for behavioral extension.

The solution requires composition over inheritance: building objects from pluggable parts rather than extending fixed hierarchies.

The Problem with Conditional Logic

When faced with inheritance limitations, developers often reach for conditional logic instead. "Let's add flags and if-statements," the reasoning goes. "One class, all behaviors controlled by flags."

This approach is arguably worse than class explosion:

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
class ConfigurableStream {
    private enableBuffering: boolean;
    private enableCompression: boolean;
    private enableEncryption: boolean;
    private enableChecksum: boolean;
    private enableLogging: boolean;
    private enableMetrics: boolean;
    private enableRetry: boolean;
    private enableRateLimit: boolean;
    
    // Constructor becomes unwieldy
    constructor(config: {
        buffering?: boolean;
        compression?: boolean;
        encryption?: boolean;
        checksum?: boolean;
        logging?: boolean;
        metrics?: boolean;
        retry?: boolean;
        rateLimit?: boolean;
    }) {
        this.enableBuffering = config.buffering ?? false;
        this.enableCompression = config.compression ?? false;
        // ... 6 more assignments
    }
    
    write(data: Buffer): void {
        let processedData = data;
        
        // Conditional logic litters every method
        if (this.enableLogging) {
            this.logOperation('write', data.length);
        }
        
        if (this.enableMetrics) {
            this.recordMetric('write_start', Date.now());
        }
        
        if (this.enableRetry) {
            processedData = this.withRetry(() => 
                this.processWrite(processedData)
            );
        } else {
            processedData = this.processWrite(processedData);
        }
        
        if (this.enableChecksum) {
            this.updateChecksum(processedData);
        }
        
        if (this.enableCompression) {
            processedData = this.compress(processedData);
        }
        
        if (this.enableEncryption) {
            processedData = this.encrypt(processedData);
        }
        
        if (this.enableBuffering) {
            this.addToBuffer(processedData);
            if (this.bufferFull()) {
                this.flushBuffer();
            }
        } else {
            this.writeToUnderlying(processedData);
        }
        
        if (this.enableRateLimit) {
            this.enforceRateLimit();
        }
        
        if (this.enableMetrics) {
            this.recordMetric('write_end', Date.now());
        }
        
        // Every method becomes a maze of conditionals
    }
    
    // This class now has:
    // - 8 boolean fields
    // - Conditional checks in every method
    // - Intertwined logic that's hard to test
    // - Impossible to extend without modification
}

Problems with the Flag Approach

•Single Responsibility Violation — One class handles 8+ distinct responsibilities
•Open/Closed Violation — Adding feature #9 requires modifying every method
•Testing Nightmare — Must test 2⁸ = 256 flag combinations
•Cyclomatic Complexity — Methods become unreadable conditional mazes
•Order Coupling — Flag check order is hardcoded and unchangeable
•Performance Overhead — All conditionals evaluated even when disabled
•Difficult Debugging — Behavior depends on flag state, hard to trace
•Extension Impossible — Cannot add custom behaviors without source modification

The God Class Anti-Pattern

What started as a simple stream class has become a God Class—a bloated object that does everything. This violates nearly every SOLID principle. The flag-based approach trades class explosion for complexity implosion, where one class collapses under its own weight.

Feature Order Matters

A subtlety often overlooked: the order in which behaviors are applied can change the result dramatically. This isn't an edge case—it's a fundamental characteristic of composed behavior.

Consider encryption and compression:

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
// Order 1: Compress then Encrypt
function compressThenEncrypt(data: Buffer): Buffer {
    const compressed = compress(data);  // Reduces size
    return encrypt(compressed);          // Then secures it
}
// Result: Efficient! Encrypted data is smaller.
 
// Order 2: Encrypt then Compress
function encryptThenCompress(data: Buffer): Buffer {
    const encrypted = encrypt(data);     // Secures first
    return compress(encrypted);           // Then tries to compress
}
// Result: Inefficient! Encrypted data appears random, 
// compression finds few patterns, minimal size reduction.
 
// -----------------------------------------------------
// Real-world example: Hashing and validation
 
// Order 1: Hash the original, then encrypt
function hashThenEncrypt(data: Buffer): { encrypted: Buffer; hash: string } {
    const hash = computeHash(data);       // Hash of original
    const encrypted = encrypt(data);
    return { encrypted, hash };
}
// Receiver: Can verify hash matches decrypted content
 
// Order 2: Encrypt first, then hash
function encryptThenHash(data: Buffer): { encrypted: Buffer; hash: string } {
    const encrypted = encrypt(data);
    const hash = computeHash(encrypted);  // Hash of encrypted bytes
    return { encrypted, hash };
}
// Receiver: Can verify encrypted bytes weren't tampered,
// but cannot verify original content without decryption

With inheritance, order is fixed at class definition time. CompressedEncryptedStream and EncryptedCompressedStream are different classes with different behaviors. If we need both orders, we need both classes—doubling our already explosive class count.

What we need is the ability to specify order at object creation time:

// Ideal: compose behaviors in desired order
const efficientStream = new Stream()
    .addCompression()    // Applied first (innermost)
    .addEncryption();    // Applied second (outermost)

const secureFirstStream = new Stream()
    .addEncryption()     // Applied first (innermost)
    .addCompression();   // Applied second (outermost)

This compositional model—unavailable through inheritance—is exactly what the Decorator pattern provides.

Symptoms in Production Codebases

Before you can apply the Decorator pattern, you must recognize when the problem exists. Here are telltale signs that a codebase is suffering from behavior extension problems:

Code Smells Indicating Decorator Need

•Deeply nested inheritance hierarchies — 4+ levels of inheritance for behavioral variation suggests class explosion has begun
•Classes named with multiple adjectives — BufferedCompressedEncryptedLoggedRetryingStream reveals encoded combinations
•Boolean flags controlling behavior — enableX, useY, withZ parameters indicate flag-based anti-pattern
•Copy-pasted behavior code — Same compression logic in 6 different classes suggests missing abstraction
•Frequent modifications to add features — Every new feature requires touching base classes
•Parallel hierarchies — WidgetA, CachedWidgetA, LoggedWidgetA, CachedLoggedWidgetA running in parallel
•Factory methods with massive switch statements — Factory logic encoding all possible combinations
•Interleaved concerns in methods — Logging, caching, and core logic mixed together

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
// Warning signs in actual code:
 
// Smell 1: Multi-adjective class names
class CachedCompressedPaginatedFilteredSortedRepository {
    // This class tries to be everything
}
 
// Smell 2: Boolean flag explosion
interface DataServiceOptions {
    enableCache?: boolean;
    cacheTimeout?: number;
    enableLogging?: boolean;
    logLevel?: 'debug' | 'info' | 'warn';
    enableMetrics?: boolean;
    metricsPrefix?: string;
    enableRetry?: boolean;
    maxRetries?: number;
    retryDelay?: number;
    enableCircuitBreaker?: boolean;
    circuitBreakerThreshold?: number;
    enableRateLimit?: boolean;
    rateLimit?: number;
    // ... 10 more optional behaviors
}
 
// Smell 3: Copy-paste in parallel classes
class UserRepository {
    async findById(id: string): Promise<User> {
        const cached = await this.cache.get(`user:${id}`);
        if (cached) return cached;
        const user = await this.db.findById(id);
        await this.cache.set(`user:${id}`, user);
        return user;
    }
}
 
class ProductRepository {
    async findById(id: string): Promise<Product> {
        // Identical caching logic, copy-pasted
        const cached = await this.cache.get(`product:${id}`);
        if (cached) return cached;
        const product = await this.db.findById(id);
        await this.cache.set(`product:${id}`, product);
        return product;
    }
}
 
// Smell 4: Factory with encoded combinations
function createStream(type: string): Stream {
    switch (type) {
        case 'buffered': return new BufferedStream();
        case 'compressed': return new CompressedStream();
        case 'encrypted': return new EncryptedStream();
        case 'buffered-compressed': return new BufferedCompressedStream();
        case 'buffered-encrypted': return new BufferedEncryptedStream();
        case 'compressed-encrypted': return new CompressedEncryptedStream();
        case 'buffered-compressed-encrypted': 
            return new BufferedCompressedEncryptedStream();
        // ... this never ends
    }
}

Recognition Leads to Solution

Once you recognize these patterns, you're prepared to apply the Decorator pattern. The next page shows how wrapping objects with decorator layers solves all these problems elegantly, enabling flexible runtime composition without class explosion.

The Problem Crystallized

Let's consolidate everything we've explored into a clear problem statement:

The Core Problem

•We need to add responsibilities to objects, not classes—specific instances may need different behaviors than others of the same type
•Behaviors must combine flexibly—any subset of capabilities should be applicable to any object without predefined combinations
•Order of behavior application matters—we need control over which behavior executes first, second, third
•Decisions must be deferrable to runtime—configuration, user preferences, and system state should influence which behaviors are attached
•The solution must be open for extension—adding new behaviors should not require modifying existing code
•Original objects must remain accessible—decorated objects must be usable wherever the original type was expected

Why Common Approaches Fail
Approach	Why It Fails	Principle Violated
Class per combination	2ⁿ classes for n features—exponential explosion	Maintainability, DRY
Multiple inheritance	Diamond problem, still compile-time bound	Simplicity, flexibility
Boolean flags	God class with conditional mazes	SRP, OCP, testability
Plugin systems	Often over-engineered for simple cases	KISS, YAGNI

What we need is a pattern that:

Treats behaviors as composable units attached to objects
Enables runtime combination in any order
Maintains type compatibility with the original interface
Follows the Open/Closed Principle—new behaviors = new classes, no modification
Keeps each behavior isolated and independently testable

The Decorator pattern delivers exactly this solution. On the next page, we'll see how wrapping objects with decorator layers creates flexible, composable behavior that scales linearly (not exponentially) with feature count.

Page Complete

You now understand the fundamental problem that the Decorator pattern solves: how to add behaviors to objects dynamically without inheritance explosion, flag-based complexity, or compile-time rigidity. The next page reveals the elegant solution—wrapping objects with decorator layers to compose behavior at runtime.