79:T693,// 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 }7a:T97a,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 }7b:T55a,// 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 decryption7c:T7e5,// 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 { 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 { // 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 } }71:{"json":{"id":"seed_fb3b9e445ec2d4de363f2205aff8d43e","slug":"decorator-pattern","category":"System Design LLD","topic":"Structural Patterns","title":"Decorator Pattern","description":"Master the Decorator pattern for adding behavior to objects dynamically. Understand when and how to compose flexible capabilities without explosive inheritance hierarchies, and learn to distinguish decoration from inheritance-based extension.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_ea9ec1351921f6b8f7d90baf2785b399","title":"Problem — Adding Behavior Dynamically","order":0,"content":[{"id":"opening-context","title":"The Fundamental Challenge of Object Extension","content":[{"data":{"content":"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.\n\nThis isn't merely a theoretical concern—it's a daily reality in production systems. Consider what happens when:\n\n- A simple logging system needs to add compression, encryption, and buffering capabilities\n- A UI component must support multiple rendering styles, animations, and accessibility features\n- A data access layer requires caching, validation, and audit trails\n- A notification service needs formatting, filtering, and delivery options\n\nThe intuitive approach—inheritance—quickly reveals fundamental limitations that can trap development teams in architectural dead ends."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"inheritance-trap","title":"The Inheritance Trap","content":[{"data":{"content":"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.\n\n**But what happens when behaviors need to combine?**\n\nLet'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."},"type":"text"},{"data":{"code":"// Base component\nclass TextComponent {\n protected text: string;\n \n constructor(text: string) {\n this.text = text;\n }\n \n render(): string {\n return this.text;\n }\n}\n\n// We need bold text capability\nclass BoldTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\n// We need italic text capability\nclass ItalicTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\n// We need underlined text capability \nclass UnderlinedTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}","title":"Initial Hierarchy — Simple Extension","language":"typescript"},"type":"code"},{"data":{"content":"So far, this seems reasonable. We have four classes: one base and three extensions. But now consider the requirements that arrive next week:\n\n- **Bold AND italic** text is needed\n- **Bold AND underlined** text is needed\n- **Italic AND underlined** text is needed\n- **All three combined** is needed\n\nOur class count explodes:"},"type":"text"},{"data":{"code":"// Combination classes start multiplying\nclass BoldItalicTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\nclass BoldUnderlinedTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\nclass ItalicUnderlinedTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\nclass BoldItalicUnderlinedTextComponent extends TextComponent {\n render(): string {\n return `${super.render()}`;\n }\n}\n\n// Current class count: 8 classes for 3 features\n// Pattern: 2^n combinations for n features","title":"Combinatorial Explosion Begins","language":"typescript"},"type":"code"},{"data":{"icon":"AlertCircle","title":"Exponential Growth Pattern","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"real-world-explosion","title":"Real-World Class Explosion","content":[{"data":{"content":"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**.\n\nConsider a file stream that needs to support various capabilities:"},"type":"text"},{"data":{"items":["**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"],"title":{"icon":"Layers","text":"Stream Capabilities Required","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"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.\n\nBut the numbers tell only part of the story. Let's examine the deeper problems:"},"type":"text"},{"data":{"rows":[["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"]],"caption":"Problems with Inheritance-Based Extension","headers":["Problem","Description","Consequence"]},"type":"table"},{"data":{"icon":"XCircle","title":"The Core Violation","content":"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.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"static-dynamic-problem","title":"The Static vs Dynamic Problem","content":[{"data":{"content":"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**.\n\nConsider these runtime scenarios that inheritance cannot address:"},"type":"text"},{"data":{"code":"$79","title":"Runtime Behavior Requirements","language":"typescript"},"type":"code"},{"data":{"content":"**The fundamental mismatch:**\n\nInheritance 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.\n\nWhen we model optional behaviors as inheritance, we conflate identity with capability. The result is bloated hierarchies that encode combinations rather than features."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Key Insight","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"single-inheritance-constraints","title":"Single Inheritance Constraints","content":[{"data":{"content":"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.\n\nLet's examine why multiple inheritance *wouldn't* solve the problem anyway:"},"type":"text"},{"data":{"left":[{"data":{"items":["**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"],"title":{"icon":"XCircle","text":"Why Multiple Inheritance Fails","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**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"],"title":{"icon":"CheckCircle","text":"What We Actually Need","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"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.\n\nThe solution requires **composition over inheritance**: building objects from pluggable parts rather than extending fixed hierarchies."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"conditional-logic-problem","title":"The Problem with Conditional Logic","content":[{"data":{"content":"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.\"\n\nThis approach is arguably worse than class explosion:"},"type":"text"},{"data":{"code":"$7a","title":"The Flag-Based Anti-Pattern","language":"typescript"},"type":"code"},{"data":{"items":["**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"],"title":{"icon":"AlertCircle","text":"Problems with the Flag Approach","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Skull","title":"The God Class Anti-Pattern","content":"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.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"feature-order-matters","title":"Feature Order Matters","content":[{"data":{"content":"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.\n\nConsider encryption and compression:"},"type":"text"},{"data":{"code":"$7b","title":"Order-Dependent Results","language":"typescript"},"type":"code"},{"data":{"content":"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.\n\nWhat we need is the ability to specify order at object creation time:\n\n```typescript\n// Ideal: compose behaviors in desired order\nconst efficientStream = new Stream()\n .addCompression() // Applied first (innermost)\n .addEncryption(); // Applied second (outermost)\n\nconst secureFirstStream = new Stream()\n .addEncryption() // Applied first (innermost)\n .addCompression(); // Applied second (outermost)\n```\n\nThis compositional model—unavailable through inheritance—is exactly what the Decorator pattern provides."},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"symptoms-production-codebases","title":"Symptoms in Production Codebases","content":[{"data":{"content":"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:"},"type":"text"},{"data":{"items":["**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"],"title":{"icon":"Search","text":"Code Smells Indicating Decorator Need","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"code":"$7c","title":"Real Code Smell Example","language":"typescript"},"type":"code"},{"data":{"icon":"Lightbulb","title":"Recognition Leads to Solution","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"problem-summary","title":"The Problem Crystallized","content":[{"data":{"content":"Let's consolidate everything we've explored into a clear problem statement:"},"type":"text"},{"data":{"type":"ordered","items":["**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"],"title":{"icon":"FileText","text":"The Core Problem","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"rows":[["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"]],"caption":"Why Common Approaches Fail","headers":["Approach","Why It Fails","Principle Violated"]},"type":"table"},{"data":{"content":"**What we need is a pattern that:**\n\n- Treats behaviors as composable units attached to objects\n- Enables runtime combination in any order\n- Maintains type compatibility with the original interface\n- Follows the Open/Closed Principle—new behaviors = new classes, no modification\n- Keeps each behavior isolated and independently testable\n\n**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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_c67c5af73f2d10fcbbcbba780a0f5568","title":"Solution — Wrapping with Decorators","order":1,"content":null,"isLocked":true},{"id":"seed_d8a7c3d56eb523a309de128a7129b778","title":"Decorator vs Inheritance","order":2,"content":null,"isLocked":true},{"id":"seed_09d85a6e4a6b4ddfd61214347831a292","title":"Use Cases and Examples","order":3,"content":null,"isLocked":true}]}}