Delegation Design Pattern in C# with Real Examples | Software Architecture Guide
- Sudhir mangla
- Design Patterns
- 01 Apr, 2025
Hey there, fellow code wrangler! Ready to dive into the world of design patterns? Today, we’re zooming in on the Delegation Design Pattern. Think of it as the secret sauce that makes your codebase more flexible and easier to manage. So, grab your favorite beverage, and let’s embark on this journey together!
What Is the Delegation Design Pattern?
Imagine you’re the CEO of a bustling tech startup. You can’t possibly handle every task yourself, right? So, you delegate responsibilities to your team members—each an expert in their domain. Similarly, in the realm of software design, the Delegation Design Pattern allows an object to hand off tasks to a helper object. This approach promotes composition over inheritance, leading to more modular and adaptable code.
In simpler terms, delegation involves one object relying on another to execute a specific task. It’s like saying, “Hey, I trust you to handle this for me,” allowing for a clean separation of concerns and enhanced code reuse.
Principles Behind Delegation
At its core, delegation is anchored in a few fundamental principles:
-
Separation of Concerns: By delegating tasks, each class focuses on its primary responsibility, leading to a more organized codebase.
-
Composition Over Inheritance: Instead of inheriting behaviors, classes can compose behaviors dynamically, offering greater flexibility.
-
Encapsulation: Delegation keeps the internal workings of classes hidden, exposing only what’s necessary. This ensures that changes in one part of the system have minimal impact on others.
When to Use the Delegation Pattern
So, when should you consider using the Delegation Design Pattern? Here are some scenarios:
-
Dynamic Behavior Assignment: When you want to change an object’s behavior at runtime without altering its class.
-
Reducing Inheritance Complexity: If your class hierarchy is becoming unwieldy, delegation can simplify relationships by promoting composition.
-
Enhancing Testability: Delegated components can be mocked or stubbed independently, making unit testing more straightforward.
-
Promoting Reusability: Shared behaviors can be encapsulated in delegate classes and reused across different parts of the application.
Key Components of the Delegation Pattern
To effectively implement the Delegation Design Pattern, it’s essential to understand its primary components:
-
Delegator: The object that delegates responsibility to another object. It knows which task needs delegation but doesn’t handle the task itself.
-
Delegate: The helper object that performs the actual task on behalf of the delegator. It encapsulates the behavior that can be reused or changed independently.
-
Common Interface: Both the delegator and delegate adhere to a shared interface, ensuring that the delegator can call the delegate’s methods without knowing its concrete implementation.
Implementing Delegation in C#
Alright, let’s roll up our sleeves and see how we can implement the Delegation Design Pattern in C#. We’ll walk through a detailed example to solidify our understanding.
Scenario: A Notification System
Imagine we’re building a notification system that can send messages via different channels, such as email and SMS. We’ll use delegation to allow the system to choose the appropriate notification method at runtime.
Step 1: Define the Common Interface
First, we’ll define an interface that outlines the contract for our notification methods:
public interface INotification
{
void Send(string message);
}This interface declares a Send method that accepts a message string. Any class implementing this interface will provide its own version of the Send method.
Step 2: Implement Concrete Delegate Classes
Next, we’ll create concrete classes that implement the INotification interface. Each class will handle a specific notification method.
Email Notification:
public class EmailNotification : INotification
{
public void Send(string message)
{
Console.WriteLine($"Sending Email: {message}");
// Logic to send email
}
}SMS Notification:
public class SmsNotification : INotification
{
public void Send(string message)
{
Console.WriteLine($"Sending SMS: {message}");
// Logic to send SMS
}
}Both classes implement the Send method, but each provides its own specific behavior for sending notifications.
Step 3: Create the Delegator Class
Now, we’ll create a Notifier class that will delegate the notification task to an INotification instance:
public class Notifier
{
private INotification _notification;
public Notifier(INotification notification)
{
_notification = notification;
}
public void Notify(string message)
{
_notification.Send(message);
}
// Optional: Method to change the notification method at runtime
public void SetNotificationMethod(INotification notification)
{
_notification = notification;
}
}The Notifier class has a private field _notification of type INotification. It uses this field to delegate the Send method call. The constructor initializes _notification, and there’s an optional SetNotificationMethod method to change the notification method at runtime.
Step 4: Utilize the Delegation Pattern
Finally, let’s see how we can use the Notifier class to send notifications:
class Program
{
static void Main(string[] args)
{
// Using Email Notification
INotification emailNotification = new EmailNotification();
Notifier notifier = new Notifier(emailNotification);
notifier.Notify("Hello via Email!");
// Switching to SMS Notification
INotification smsNotification = new SmsNotification();
notifier.SetNotificationMethod(smsNotification);
notifier.Notify("Hello via SMS!");
}
}Output:
Sending Email: Hello via Email!
Sending SMS: Hello via SMS!In this example:
-
We first create an
EmailNotificationinstance and pass it to theNotifierconstructor. When we callNotify, it delegates the call to theEmailNotification’sSendmethod. -
We then create an
SmsNotificationinstance and change the notification method at runtime usingSetNotificationMethod. Subsequent calls toNotifyare delegated to theSmsNotification’sSendmethod.
This approach demonstrates the flexibility of the Delegation Design Pattern, allowing the behavior to be changed dynamically at runtime.
🔁 Different Ways to Implement Delegation in C#
C# gives us a few cool ways to implement delegation. You’re not locked into just one style—there’s flexibility depending on how you want to build your system.
1. Classic Object-Oriented Delegation (Using Interfaces)
You’ve already seen this in the earlier section. We define a shared interface, implement it in a delegate class, and use composition in the delegator to call the delegate’s methods.
Here’s a refresh in one line:
public class Printer { public void Print() => Console.WriteLine("Printing..."); }
public class Document { private Printer _printer = new Printer(); public void Print() => _printer.Print(); }That’s delegation! The Document delegates the printing task to the Printer.
2. Using Delegates (C# Language Feature)
C# has a built-in feature literally called delegates. It’s a type-safe function pointer and a natural fit for the delegation pattern.
public delegate void NotificationDelegate(string message);
public class NotificationService
{
public void SendEmail(string message) => Console.WriteLine($"Email: {message}");
public void SendSms(string message) => Console.WriteLine($"SMS: {message}");
}
class Program
{
static void Main()
{
NotificationService service = new NotificationService();
NotificationDelegate notifier = service.SendEmail;
notifier("Hello via Delegate!");
notifier = service.SendSms;
notifier("Hello via SMS Delegate!");
}
}Pretty slick, right? You can switch behaviors on the fly.
3. Using Events (Built on Delegates)
Events are like delegates with a few safety rules slapped on. They’re perfect for publish-subscribe models and UI programming.
public class Button
{
public event Action Clicked;
public void Click() => Clicked?.Invoke();
}
class Program
{
static void Main()
{
Button button = new Button();
button.Clicked += () => Console.WriteLine("Button was clicked!");
button.Click();
}
}Here, the button doesn’t know what will happen when it’s clicked—it just delegates that responsibility to the subscribers.
4. Using Action and Func (Built-in Generic Delegates)
These make delegation a breeze.
public class MathProcessor
{
public void Process(Func<int, int, int> operation, int a, int b)
{
int result = operation(a, b);
Console.WriteLine($"Result: {result}");
}
}
class Program
{
static void Main()
{
var processor = new MathProcessor();
processor.Process((x, y) => x + y, 10, 5); // Delegating addition
processor.Process((x, y) => x * y, 10, 5); // Delegating multiplication
}
}🧠 Real-World Use Cases for Delegation
Delegation shows up in real-world apps more than you might think. Let’s run through some places where it really shines:
✅ 1. UI Frameworks (Like WinForms, WPF, MAUI)
Ever hooked up a button click? That’s delegation in disguise.
myButton.Click += HandleClick;The button delegates the “what should I do when clicked” behavior to you.
✅ 2. Strategy Pattern
Delegation is a key enabler for Strategy. You pick a behavior at runtime and plug it in. Want a different algorithm? Just delegate to a different class.
✅ 3. Event-Driven Systems
Whether it’s a stock trading app or a real-time dashboard, event handlers delegate responsibility to event listeners.
✅ 4. Logging Systems
A centralized logger might delegate the actual writing to different outputs: file, database, cloud. All plug-and-play!
✅ 5. Middleware and Pipelines
ASP.NET Core uses delegation in its request pipeline. Each middleware component handles the request and then delegates it to the next.
app.Use(async (context, next) =>
{
// Do something before
await next();
// Do something after
});✅ Advantages of the Delegation Pattern
So why should you reach for delegation? Here’s your shortlist:
🔹 1. Decoupling
Your classes don’t need to know how something is done—just that it will be done.
🔹 2. Reusability
Delegate classes can be reused across multiple contexts.
🔹 3. Runtime Flexibility
Behavior can change on the fly—especially handy with delegates or strategy pattern.
🔹 4. Testing Made Easy
Mocking delegates or injected behavior is a breeze. You can isolate and test behaviors independently.
🔹 5. Composition Over Inheritance
Avoid the deep inheritance tree and compose your objects smartly.
⚠️ Disadvantages of Delegation
No rose without thorns, right? Delegation isn’t always sunshine and rainbows.
⚫ 1. Indirection Overhead
You’re adding another layer between the caller and the action. That can make debugging a bit trickier.
⚫ 2. More Boilerplate
Especially with the interface-based style, delegation can introduce extra interfaces and wrapper classes.
⚫ 3. Performance
Not a huge deal in most apps, but it can introduce minor performance costs due to indirection and context switching.
⚫ 4. Too Much Flexibility?
With great power comes… yeah. If overused, it can make your architecture harder to trace and understand.
🧾 Conclusion: Should You Use Delegation?
If you’re building scalable, maintainable, and testable applications in C#, the Delegation Design Pattern is your friend. It fits beautifully with modern principles like SOLID, especially the Single Responsibility and Open/Closed principles.
Here’s the deal: delegation is like having a skilled assistant on your team. You give them the “what”, and they take care of the “how”. This makes your code less tangled, more modular, and easier to grow.
Whether you’re building notification systems, middleware, UI apps, or just want to follow good object-oriented design—knowing when and how to delegate will take your architecture game to the next level.
So next time you’re designing a class and you think: “Should this class really be doing all of this?”—it might be time to delegate.
