7a:T588,// The Delegate Interface - defines what can be delegated interface DocumentFormatter { format(content: string): string; } // A concrete delegate implementation class MarkdownFormatter implements DocumentFormatter { format(content: string): string { // Transform markdown to formatted output return this.parseMarkdown(content); } private parseMarkdown(content: string): string { // Markdown parsing logic return content .replace(/\*\*(.+?)\*\*/g, '$1') .replace(/\*(.+?)\*/g, '$1'); } } // The Delegator - forwards formatting to its delegate class Printer { // Composition: Printer HAS-A DocumentFormatter private formatter: DocumentFormatter; constructor(formatter: DocumentFormatter) { this.formatter = formatter; } print(document: string): void { // DELEGATION: Forward formatting responsibility to delegate const formattedContent = this.formatter.format(document); // Printer handles its own responsibility: printing this.sendToDevice(formattedContent); } private sendToDevice(content: string): void { console.log('Printing:', content); } } // Usage const printer = new Printer(new MarkdownFormatter()); printer.print("**Hello** *World*"); // Output: Printing: Hello World7b:T5bd,// The Delegate Interface - defines what can be delegated public interface DocumentFormatter { String format(String content); } // A concrete delegate implementation public class MarkdownFormatter implements DocumentFormatter { @Override public String format(String content) { // Transform markdown to formatted output return parseMarkdown(content); } private String parseMarkdown(String content) { // Markdown parsing logic return content .replaceAll("\\*\\*(.+?)\\*\\*", "$1") .replaceAll("\\*(.+?)\\*", "$1"); } } // The Delegator - forwards formatting to its delegate public class Printer { // Composition: Printer HAS-A DocumentFormatter private final DocumentFormatter formatter; public Printer(DocumentFormatter formatter) { this.formatter = formatter; } public void print(String document) { // DELEGATION: Forward formatting responsibility to delegate String formattedContent = formatter.format(document); // Printer handles its own responsibility: printing sendToDevice(formattedContent); } private void sendToDevice(String content) { System.out.println("Printing: " + content); } } // Usage Printer printer = new Printer(new MarkdownFormatter()); printer.print("**Hello** *World*"); // Output: Printing: Hello World7c:T407,**Illustrating the Distinction** Consider two approaches to implementing a `Logger` that formats log messages: **Simple Method Call (Not True Delegation)**: ```typescript class Logger { private helper = new MessageHelper(); // Hardcoded dependency log(message: string): void { // Just using a helper—no intentional design for variation const formatted = this.helper.addTimestamp(message); console.log(formatted); } } ``` **True Delegation Pattern**: ```typescript class Logger { constructor(private formatter: MessageFormatter) {} // Injected interface log(message: string): void { // Intentional delegation—formatter is an extension point const formatted = this.formatter.format(message); console.log(formatted); } } ``` In the first case, `MessageHelper` is an implementation detail. In the second, `MessageFormatter` is an intentional extension point. The Logger *expects* different formatters to be plugged in—that's the design intent.7d:T5f4,// The Strategy interface - defines a family of behaviors interface FlyBehavior { fly(): string; } // Concrete strategies - different implementations class StandardFlying implements FlyBehavior { fly(): string { return "Flying with wings!"; } } class JetPoweredFlying implements FlyBehavior { fly(): string { return "Flying with jet propulsion!"; } } class NoFlying implements FlyBehavior { fly(): string { return "Sorry, I can't fly."; } } // Duck uses COMPOSITION to hold a FlyBehavior // Duck uses DELEGATION to implement fly() class Duck { // COMPOSITION: Duck has-a FlyBehavior private flyBehavior: FlyBehavior; constructor(flyBehavior: FlyBehavior) { this.flyBehavior = flyBehavior; } // DELEGATION: Duck forwards fly() to its FlyBehavior performFly(): string { return this.flyBehavior.fly(); } // Runtime flexibility: behavior can be changed! setFlyBehavior(newBehavior: FlyBehavior): void { this.flyBehavior = newBehavior; } } // Usage demonstrates the power of composition + delegation const mallard = new Duck(new StandardFlying()); console.log(mallard.performFly()); // "Flying with wings!" const rubberDuck = new Duck(new NoFlying()); console.log(rubberDuck.performFly()); // "Sorry, I can't fly." // Runtime behavior change—impossible with inheritance! mallard.setFlyBehavior(new JetPoweredFlying()); console.log(mallard.performFly()); // "Flying with jet propulsion!"7e:T669,// The Strategy interface - defines a family of behaviors public interface FlyBehavior { String fly(); } // Concrete strategies - different implementations public class StandardFlying implements FlyBehavior { @Override public String fly() { return "Flying with wings!"; } } public class JetPoweredFlying implements FlyBehavior { @Override public String fly() { return "Flying with jet propulsion!"; } } public class NoFlying implements FlyBehavior { @Override public String fly() { return "Sorry, I can't fly."; } } // Duck uses COMPOSITION to hold a FlyBehavior // Duck uses DELEGATION to implement fly() public class Duck { // COMPOSITION: Duck has-a FlyBehavior private FlyBehavior flyBehavior; public Duck(FlyBehavior flyBehavior) { this.flyBehavior = flyBehavior; } // DELEGATION: Duck forwards fly() to its FlyBehavior public String performFly() { return flyBehavior.fly(); } // Runtime flexibility: behavior can be changed! public void setFlyBehavior(FlyBehavior newBehavior) { this.flyBehavior = newBehavior; } } // Usage demonstrates the power of composition + delegation Duck mallard = new Duck(new StandardFlying()); System.out.println(mallard.performFly()); // "Flying with wings!" Duck rubberDuck = new Duck(new NoFlying()); System.out.println(rubberDuck.performFly()); // "Sorry, I can't fly." // Runtime behavior change—impossible with inheritance! mallard.setFlyBehavior(new JetPoweredFlying()); System.out.println(mallard.performFly()); // "Flying with jet propulsion!"7f:T46c,To effectively apply delegation in your designs, it helps to develop a clear mental model. Here are several useful ways to think about delegation: **Mental Model 1: The Expert Colleague** Think of delegation like working with a specialist colleague. You're a project manager (the delegator). When a task requires legal expertise, you don't try to learn law—you forward the task to the legal expert (the delegate). They handle it and give you the result. - You know *what* needs to be done (the interface) - The expert knows *how* to do it (the implementation) - You coordinate, they execute **Mental Model 2: The Configurable Machine** Imagine a coffee machine with interchangeable grinder modules. The machine (delegator) has a slot for a grinder (delegate). Different grinders produce different grinds. The machine doesn't need to know about burr grinders vs blade grinders—it just says "grind coffee" and uses whatever grinder is installed. - The machine defines the interface (input beans, output grounds) - Grinders implement the interface differently - Swapping grinders changes behavior without changing the machine80:T426,**Mental Model 3: The Orchestra Conductor** An orchestra conductor (delegator) doesn't play every instrument. They coordinate, giving cues to different specialists (delegates)—the violinist, the percussionist, the flutist. Each musician knows their craft; the conductor knows when and how to combine their contributions. This model is particularly relevant when objects delegate to multiple collaborators: ```typescript class OrderProcessor { constructor( private paymentGateway: PaymentGateway, private inventoryService: InventoryService, private notificationService: NotificationService ) {} processOrder(order: Order): void { // Delegate payment processing this.paymentGateway.charge(order.total); // Delegate inventory update this.inventoryService.reserve(order.items); // Delegate notification this.notificationService.sendConfirmation(order); } } ``` The `OrderProcessor` is the conductor, coordinating the work of three specialized delegates.81:T412,Delegation manifests in several forms, each with different characteristics. Understanding these variations helps you choose the right approach for your design: **1. Simple Forwarding** The delegator receives a request and forwards it directly to the delegate, returning the result unchanged: ```typescript class Printer { print(doc: Document): void { this.formatter.format(doc); // Forward } } ``` **2. Decorated Forwarding** The delegator adds behavior before or after delegating: ```typescript class LoggingPrinter { print(doc: Document): void { this.logger.log('Before print'); this.innerPrinter.print(doc); // Delegate this.logger.log('After print'); } } ``` **3. Coordinating Delegation** The delegator coordinates multiple delegates to fulfill a request: ```typescript class ReportGenerator { generate(): Report { const data = this.dataFetcher.fetch(); const analyzed = this.analyzer.analyze(data); return this.renderer.render(analyzed); } } ```82:T4af,**4. Conditional Delegation** The delegator selects which delegate to forward to based on the context: ```typescript class PaymentProcessor { processPayment(payment: Payment): void { if (payment.type === 'card') { this.cardGateway.process(payment); } else { this.bankGateway.process(payment); } } } ``` Note: This can often be improved using polymorphism: ```typescript class PaymentProcessor { process(payment: Payment): void { const gateway = this.gatewayFactory.getGateway(payment.type); gateway.process(payment); // Polymorphic delegation } } ``` **5. Self-Referential Delegation** In true delegation (as in prototype-based languages like JavaScript), the delegate can refer back to the original object. This allows the delegate to use the delegator's state or call its methods. Most class-based languages don't directly support this, but it can be simulated: ```typescript interface Delegate { doWork(context: Delegator): void; } class SomeDelegate implements Delegate { doWork(context: Delegator): void { // Can access the delegator's state! console.log(context.name); } } ```72:{"json":{"id":"seed_88724ac7c8548a13c4371c0198bae5a6","slug":"delegation-pattern","category":"System Design (LLD)","topic":"Delegation Pattern","title":"Delegation Pattern — Flexible Object Collaboration","description":"Master the delegation pattern, a fundamental technique for achieving flexible object collaboration. Learn how objects forward responsibilities to contained objects, understand the relationship between delegation and composition, and implement delegation effectively in your designs.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_38796ad8fc2d31a89ebf468826271618","title":"What Is Delegation?","order":0,"content":[{"id":"opening-hook","title":"The Art of Collaborative Objects","content":[{"data":{"content":"In the previous modules, we established that composition is often preferable to inheritance for building flexible, maintainable systems. But composition alone is just a structural relationship—objects containing other objects. The real power emerges when we understand **delegation**: the dynamic mechanism by which composed objects actually collaborate.\n\n**Delegation** is the act of one object forwarding a request to another object to handle. Rather than implementing behavior directly, an object entrusts that responsibility to a collaborator. This simple concept is surprisingly powerful, enabling runtime flexibility, clean separation of concerns, and elegant designs that inheritance simply cannot achieve.\n\nIf composition is the structure of \"has-a\" relationships, delegation is the *behavior* of those relationships—the protocol by which objects work together."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what delegation is, how it differs from simple method forwarding, its relationship to composition, and the mental model for thinking about delegating objects. You'll see delegation as the behavioral essence of composition—the mechanism that brings \"has-a\" relationships to life.","variant":"info"},"type":"callout"}]},{"id":"defining-delegation","title":"Defining Delegation","content":[{"data":{"content":"**Delegation** is a design technique where an object handles a request by forwarding it to a second object (the *delegate*) for processing. The first object doesn't implement the behavior itself; instead, it relies on its delegate to provide the implementation.\n\nThis concept is fundamental to object-oriented design, yet it's often overlooked in favor of discussing inheritance. Let's establish a precise definition:\n\n**Definition**: Delegation occurs when an object (the *delegator*) receives a message and responds by sending one or more messages to another object (the *delegate*), which performs the actual work. The delegator may then return the delegate's result, transform it, or combine it with other operations.\n\n**The Key Insight**: Delegation is not just \"calling another object's method.\" It's a *design decision* to assign responsibility to a collaborating object rather than implementing behavior internally."},"type":"text"},{"data":{"rows":[["Delegator","The object receiving the original request","Forwards work to the delegate"],["Delegate","The object that performs the actual work","Implements the delegated behavior"],["Delegation","The act of forwarding responsibility","The mechanism of collaboration"],["Protocol/Interface","The contract between delegator and delegate","Defines what can be delegated"]],"caption":"Delegation Terminology","headers":["Term","Definition","Role"]},"type":"table"},{"data":{"content":"**A Concrete Example**\n\nConsider a `Printer` class that needs to format documents before printing. Rather than implementing formatting logic itself, it delegates to a `DocumentFormatter`:\n\n- The `Printer` receives a print request\n- Instead of formatting the document internally, it forwards the formatting task to its `DocumentFormatter` delegate\n- The `DocumentFormatter` returns the formatted output\n- The `Printer` then handles the actual printing\n\nThe `Printer` *has* a `DocumentFormatter` (composition) and *uses* it by delegating formatting responsibility (delegation)."},"type":"text"},{"data":{"fileName":"basic-delegation-example","languages":[{"code":"$7a","label":"TypeScript","value":"typescript"},{"code":"$7b","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"The Separation of Concerns","content":"Notice how delegation creates a natural separation of concerns. The Printer focuses on printing—its core responsibility. Formatting knowledge is encapsulated in the formatter. Neither class needs to understand the other's internal workings. They collaborate through a well-defined interface.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"delegation-vs-method-calls","title":"Delegation vs Simple Method Calls","content":[{"data":{"content":"A common confusion arises: \"Isn't delegation just calling another object's method?\" While delegation involves method calls, it's conceptually distinct. Understanding this difference is crucial for applying delegation as a design pattern rather than an accidental implementation detail.\n\n**Simple Method Call**: Any object invoking a method on another object. This is just the mechanics of OOP—objects sending messages.\n\n**Delegation as Design Pattern**: A deliberate architectural decision where an object's behavior is intentionally implemented by forwarding to a collaborating object that can vary independently.\n\nThe difference lies in *intent* and *design*:"},"type":"text"},{"data":{"left":[{"data":{"items":["Ad-hoc usage of collaborating objects","Typically hardcoded to specific classes","Implementation detail, not architecture","No polymorphic variation intended","Tight coupling often present","Delegate is fixed at compile time"],"title":{"icon":"Info","text":"Simple Method Calls","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Intentional forwarding of responsibility","Delegate referenced through interface","Architectural decision for flexibility","Polymorphic variation is the point","Loose coupling through abstraction","Delegate can be swapped at runtime"],"title":{"icon":"CheckCircle","text":"Delegation Pattern","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"$7c"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Strategic Intent of Delegation","content":"Delegation as a pattern is about **strategic decoupling**. When you design with delegation, you're saying: \"This behavior is not my core responsibility. It could vary. I intentionally defer to a collaborator who specializes in this.\" This intent guides you to use interfaces, accept delegates through constructors, and think about what variations might be needed.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"composition-and-delegation","title":"The Relationship Between Composition and Delegation","content":[{"data":{"content":"Composition and delegation are deeply intertwined, but they describe different aspects of object relationships:\n\n- **Composition** describes the *structural* relationship: Object A contains (or references) Object B\n- **Delegation** describes the *behavioral* relationship: Object A uses Object B to perform some work\n\nYou cannot have delegation without some form of composition (the delegator must hold a reference to the delegate). But you can have composition without delegation (an object might contain another object but never ask it to do work).\n\n**Composition + Delegation = Flexible Behavior Reuse**\n\nThe power emerges when you combine them deliberately:\n\n1. **Composition** gives you the structural mechanism to hold collaborators\n2. **Delegation** gives you the behavioral protocol for using those collaborators\n3. **Interfaces** give you the abstraction for polymorphic variation\n\nTogether, they enable the kind of flexible, runtime-reconfigurable behavior that inheritance cannot provide."},"type":"text"},{"data":{"rows":[["Nature","Structural relationship","Behavioral protocol","Type relationship"],["Question Answered","What does this object contain?","How do objects collaborate?","What type is this object?"],["Binding","Can be runtime","Can be runtime","Compile-time only"],["Coupling","To interface (loose)","To protocol (loose)","To implementation (tight)"],["Flexibility","High (swap components)","High (swap behavior)","Low (fixed hierarchy)"],["Reuse Mechanism","Assembly","Forwarding","Inheriting"]],"caption":"Composition vs Delegation vs Inheritance","headers":["Aspect","Composition","Delegation","Inheritance"]},"type":"table"},{"data":{"content":"**The \"Favor Composition Over Inheritance\" Principle Revisited**\n\nRecall the famous Gang of Four principle. Now we can understand it more precisely:\n\n> \"Favor **composition and delegation** over class inheritance.\"\n\nThe principle isn't just about containing objects—it's about using those contained objects to implement behavior that would otherwise require inheritance. Delegation is the *mechanism* by which composition replaces inheritance.\n\n**Example: Replacing Inheritance with Composition + Delegation**\n\nInheritance approach:\n```\nclass Duck extends FlyingAnimal { }\n```\n\nComposition + Delegation approach:\n```\nclass Duck {\n constructor(private flyBehavior: FlyBehavior) { }\n fly() { this.flyBehavior.fly(); } // Delegation\n}\n```\n\nIn the second approach, `Duck` HAS a fly behavior (composition) and USES it when asked to fly (delegation). Different ducks can have different fly behaviors, and even the same duck can change its fly behavior at runtime."},"type":"text"},{"data":{"fileName":"composition-delegation-synergy","languages":[{"code":"$7d","label":"TypeScript","value":"typescript"},{"code":"$7e","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Sparkles","title":"The Synergy Unlocked","content":"Composition provides the **container**. Delegation provides the **collaboration protocol**. Interfaces provide the **abstraction for variation**. Together, they create systems where behavior is assembled from interchangeable parts rather than hardcoded into hierarchies.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"mental-model-delegation","title":"The Mental Model for Delegation","content":[{"data":{"content":"$7f"},"type":"text"},{"data":{"items":["**What responsibility is this object delegating?** — Be specific about the behavior being forwarded.","**Could this delegated behavior vary?** — If yes, delegation to an interface is appropriate.","**Is the delegate's interface well-defined?** — Clear contracts make for clean delegation.","**Who creates the delegate?** — Constructor injection keeps the delegator decoupled.","**Can the delegate be swapped at runtime?** — Consider if you need a setter method.","**Is the delegator just forwarding, or also coordinating?** — Both are valid delegation patterns."],"title":{"icon":"Lightbulb","text":"Delegation Design Questions","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"$80"},"type":"text"},{"data":{"icon":"Lightbulb","title":"When to Think \"Delegation\"","content":"Ask yourself: \"Am I implementing this behavior, or am I coordinating someone else to do it?\" If you find yourself writing code that's not the core responsibility of the class, consider delegation. The class that receives requests doesn't always have to be the one that fulfills them.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"forms-of-delegation","title":"Forms of Delegation","content":[{"data":{"content":"$81"},"type":"text"},{"data":{"rows":[["Simple Forwarding","Pass request directly to delegate","Single responsibility delegation","Printer → Formatter"],["Decorated Forwarding","Add behavior around delegation","Cross-cutting concerns (logging, caching)","CachingRepository → Repository"],["Coordinating","Orchestrate multiple delegates","Complex workflows","OrderProcessor → multiple services"],["Conditional Delegation","Choose delegate based on context","Polymorphic selection","PaymentProcessor → card/bank delegate"],["Chain Delegation","Delegate until one handles it","Handler chain scenarios","Chain of Responsibility pattern"]],"caption":"Delegation Patterns Comparison","headers":["Pattern","Description","Use Case","Example"]},"type":"table"},{"data":{"content":"$82"},"type":"text"},{"data":{"icon":"Info","title":"True Delegation vs Forwarding","content":"In academic literature, \"true delegation\" specifically means the delegate can reference the original receiver (self). In class-based languages like Java/TypeScript, what we typically call delegation is technically \"forwarding\" or \"consultation.\" In practice, the terms are used interchangeably, and the design benefits apply regardless of the technical distinction.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"delegation-in-patterns","title":"Delegation in Well-Known Patterns","content":[{"data":{"content":"Delegation is so fundamental that it appears as the core mechanism in many well-known design patterns. Recognizing these patterns helps you see delegation's broad applicability:\n\n**Strategy Pattern**\n\nThe Strategy pattern is perhaps the purest example of delegation. An object delegates an algorithm to a strategy object:\n\n- A `PaymentProcessor` delegates payment algorithm to `PaymentStrategy`\n- A `Sorter` delegates sorting algorithm to `SortingStrategy`\n- A `Compressor` delegates compression algorithm to `CompressionStrategy`\n\nThe delegator maintains a reference to a strategy interface and forwards algorithmic requests to it.\n\n**Decorator Pattern**\n\nDecorators use delegation to wrap objects with additional behavior:\n\n- The decorator receives a request\n- It may do some work, then delegates to the wrapped object\n- It may modify the result before returning\n\nThe decorator and the decorated object share the same interface, enabling transparent wrapping."},"type":"text"},{"data":{"items":["**Strategy** — Delegate the algorithm to a strategy object. Vary algorithms independently from clients.","**Decorator** — Delegate to the wrapped object while adding behavior. Extend functionality dynamically.","**Adapter** — Delegate to an adaptee while transforming the interface. Bridge incompatible interfaces.","**Proxy** — Delegate to the real subject while controlling access. Add indirection for various purposes.","**State** — Delegate to a state object that varies. Let behavior change with internal state.","**Chain of Responsibility** — Delegate to the next handler if unable to handle. Decouple senders from receivers.","**Composite** — Delegate to children for tree operations. Treat individual and composite uniformly."],"title":{"icon":"Target","text":"Patterns Built on Delegation","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Composite Pattern**\n\nComposite uses delegation to implement tree-structured hierarchies:\n\n- A composite node delegates operations to its children\n- Each child either handles the request (leaf) or further delegates (composite)\n- This creates recursive delegation through the tree\n\n**State Pattern**\n\nThe State pattern delegates behavior to an object representing current state:\n\n- A `Document` delegates behavior to its `DocumentState`\n- When state changes, a different state object is used\n- Same interface, different behavior through delegation\n\n**Observer Pattern (Event Listeners)**\n\nEven event systems use delegation:\n\n- The subject delegates notification to registered listeners\n- Each listener handles the notification independently\n- The subject doesn't know or care how listeners respond"},"type":"text"},{"data":{"icon":"Sparkles","title":"Patterns as Delegation Recipes","content":"When studying design patterns, notice how many are essentially different recipes for delegation. The Strategy pattern says \"delegate the algorithm.\" The State pattern says \"delegate to current state.\" The Decorator says \"delegate with added behavior.\" Understanding delegation deeply makes these patterns intuitive.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"benefits-of-delegation","title":"Benefits of Delegation","content":[{"data":{"content":"Having established what delegation is and how it manifests, let's consolidate its benefits. These advantages explain why delegation is a cornerstone of flexible object-oriented design:"},"type":"text"},{"data":{"items":["**Runtime Flexibility** — Behavior can be changed by swapping delegates at runtime. An inheritance-based design is fixed at compile time; delegation-based design adapts dynamically.","**Single Responsibility** — Objects focus on their core mission. Auxiliary behaviors are delegated to specialists. This aligns with the Single Responsibility Principle.","**Loose Coupling** — Delegators depend on interfaces, not concrete implementations. This makes the system easier to test, modify, and extend.","**Testability** — Mock delegates can be injected during testing. Test the delegator in isolation without needing all real dependencies.","**Reusability** — Delegates are reusable across different contexts. A `MarkdownFormatter` can be used by any class that needs markdown formatting.","**Open/Closed Compliance** — Add new behavior by adding new delegate implementations, without modifying existing code. The system is open for extension, closed for modification.","**Avoiding Inheritance Problems** — Delegation doesn't create fragile base class dependencies, rigid hierarchies, or tight coupling to parent implementations."],"title":{"icon":"CheckCircle","text":"Key Benefits of Delegation","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**The Testing Advantage Illustrated**\n\nConsider testing a `NotificationService` that delegates to an `EmailSender`:\n\n```typescript\n// Production code\nclass NotificationService {\n constructor(private emailSender: EmailSender) {}\n \n notify(user: User, message: string): void {\n this.emailSender.send(user.email, message);\n }\n}\n\n// Test code - easy to mock!\nit('should send email to user', () => {\n const mockEmailSender = {\n send: jest.fn() // Mock the delegate\n };\n \n const service = new NotificationService(mockEmailSender);\n service.notify({ email: 'test@example.com' }, 'Hello');\n \n expect(mockEmailSender.send).toHaveBeenCalledWith('test@example.com', 'Hello');\n});\n```\n\nWithout delegation, the `NotificationService` might instantiate its email sender internally, making testing much harder."},"type":"text"},{"data":{"icon":"Zap","title":"The Compound Effect","content":"These benefits compound. Loose coupling enables testability. Testability encourages better design. Single responsibility makes code clearer. Clarity reduces bugs. Runtime flexibility allows rapid iteration. Each benefit reinforces the others, creating a virtuous cycle of design quality.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: Understanding Delegation","content":[{"data":{"content":"We've established a comprehensive understanding of what delegation is and why it matters. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Delegation defined** — An object forwards responsibility to a collaborating object (the delegate) rather than implementing behavior itself.","**Beyond method calls** — Delegation as a pattern is an intentional design decision for flexibility, not just any method invocation.","**Composition + Delegation** — Composition provides the structure (has-a); delegation provides the behavior protocol (uses-for).","**Mental models** — Think of delegation as expert colleagues, configurable machines, or orchestra conductors.","**Multiple forms** — Delegation appears as simple forwarding, decorated forwarding, coordination, conditional selection, and chaining.","**Pattern foundation** — Many design patterns (Strategy, Decorator, State, etc.) are built on delegation.","**Tangible benefits** — Runtime flexibility, loose coupling, testability, reusability, and avoidance of inheritance problems."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand what delegation is conceptually, the next page examines the mechanics in detail: **Forwarding Requests to Contained Objects**. We'll explore the implementation patterns, the relationship between the delegator and delegate, and how to set up effective delegation in practice."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand delegation as a fundamental design technique—the behavioral mechanism that brings composition to life. Delegation is not just calling methods; it's a deliberate architectural choice for flexibility. Next, we'll explore how to implement effective delegation by examining the mechanics of forwarding requests to contained objects.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_add99eee330ca70312d207504d75208f","title":"Forwarding Requests to Contained Objects","order":1,"content":null,"isLocked":true},{"id":"seed_e74c52933c1eb8dffbfc20051c53765f","title":"Delegation vs Inheritance","order":2,"content":null,"isLocked":true},{"id":"seed_ca907f310533aed5f9888cf3165bc83e","title":"Implementing Delegation","order":3,"content":null,"isLocked":true}]}}