The Morning Dev

Mastering the Decorator Pattern in C#: Avoid These 7 Common Mistakes That Break Your Code

Have you ever needed to add new functionality to an existing class without modifying its source code? Or perhaps you wanted to combine different behaviors dynamically at runtime? If you’ve struggled with creating endless subclasses or violating the Open-Closed Principle, you’re not alone. The Decorator Pattern offers an elegant solution to these common software development challenges, but it’s also one of the most misunderstood design patterns among C# developers.

In this comprehensive guide, we’ll explore the Decorator Pattern through the lens of real-world problems, examine the most common mistakes developers make, and provide practical C# examples that you can implement immediately. By the end of this article, you’ll have a deep understanding of when and how to use this powerful pattern effectively.

What Is the Decorator Pattern and Why Should You Care?

The Decorator Pattern is a structural design pattern that allows you to attach new behaviors to objects by placing them inside special wrapper objects. Think of it like adding toppings to a pizza – you don’t change the base pizza, you just layer additional features on top.

At its core, the Decorator Pattern solves a fundamental problem in object-oriented programming: how do you extend an object’s functionality without creating an explosion of subclasses or modifying existing code? This pattern provides a flexible alternative to inheritance by using composition instead.

The Real-World Problem It Solves

Imagine you’re building a notification system for a software application. Initially, you only need email notifications, but over time, requirements evolve:

  • Some users want SMS notifications
  • Others prefer push notifications
  • Business users need notifications with encryption
  • Developers want logging capabilities
  • Premium users get priority delivery

Using traditional inheritance, you’d end up with dozens of classes: EmailNotifier, SMSNotifier, EncryptedEmailNotifier, LoggedSMSNotifier, PriorityEncryptedEmailNotifier, and so on. The Decorator Pattern eliminates this combinatorial explosion by allowing you to compose behaviors dynamically.

Understanding the Decorator Pattern Structure in C#

Before diving into common mistakes, let’s establish a solid foundation with the pattern’s structure. The Decorator Pattern consists of four key components:

Visual Representation: UML Class Diagram

Understanding the Decorator Pattern becomes much clearer when you can visualize the relationships between its components. The UML diagram below illustrates the complete structure of the pattern, showing how the interface, concrete components, abstract decorator, and concrete decorators work together.

decorator pattern uml diagram
decorator-pattern flow example

The diagram demonstrates several key aspects:

Structural Relationships: You can see how all components implement the same INotifier interface, ensuring that decorators can wrap both concrete components and other decorators seamlessly.

Composition Over Inheritance: Notice how the NotifierDecorator contains a reference to INotifier (shown by the aggregation relationship), rather than inheriting from a concrete class. This composition enables the flexible chaining behavior.

Decorator Chain Example: The bottom section shows a practical example of how decorators wrap around each other, creating a chain where each decorator adds its own behavior while delegating to the next component in the chain.

Execution Flow: The execution flows from the outermost decorator (RetryDecorator) through each layer until it reaches the core component (EmailNotifier), with each decorator adding its functionality either before, after, or around the delegated call.

This visual representation helps clarify why the Decorator Pattern is so powerful for building flexible, composable systems without creating an explosion of subclasses.

1. Component Interface

This defines the contract that both concrete components and decorators must implement:

				
					public interface INotifier
{
    void Send(string message);
}

2. Concrete Component

The base implementation that provides core functionality:

				
					public class EmailNotifier : INotifier
{
    private readonly string email;
    
    public EmailNotifier(string email)
    {
        this.email = email;
    }
    
    public void Send(string message)
    {
        Console.WriteLine($"Sending email to {email}: {message}");
    }
}

3. Base Decorator

An abstract class that implements the component interface and maintains a reference to a component:

				
					public abstract class NotifierDecorator : INotifier
{
    protected readonly INotifier notifier;
    
    protected NotifierDecorator(INotifier notifier)
    {
        this.notifier = notifier ?? throw new ArgumentNullException(nameof(notifier));
    }
    
    public virtual void Send(string message)
    {
        notifier.Send(message);
    }
}

4. Concrete Decorators

These add specific behaviors to the component:

				
					public class EncryptionDecorator : NotifierDecorator
{
    public EncryptionDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        string encryptedMessage = Encrypt(message);
        base.Send(encryptedMessage);
    }
    
    private string Encrypt(string message)
    {
        // Simplified encryption logic
        return $"[ENCRYPTED: {message}]";
    }
}

public class LoggingDecorator : NotifierDecorator
{
    public LoggingDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        Console.WriteLine($"[LOG] Sending notification at {DateTime.Now}");
        base.Send(message);
        Console.WriteLine("[LOG] Notification sent successfully");
    }
}

The 7 Most Common Decorator Pattern Mistakes (And How to Fix Them)

Now that we understand the basic structure, let’s examine the mistakes that trip up even experienced developers.

Mistake #1: Incomplete Interface Implementation

The Problem: Creating decorators that don’t implement all methods from the component interface, leading to broken functionality and unexpected behavior.

Why It Happens: Developers often focus on the specific method they want to decorate and forget about other interface members, especially when interfaces grow over time.

Wrong Approach:

				
					public interface IDataProcessor
{
    void ProcessData(string data);
    void ValidateData(string data);
    string GetStatus();
}

// This decorator only implements ProcessData - WRONG!
public class CachingDecorator : IDataProcessor
{
    private readonly IDataProcessor processor;
    
    public CachingDecorator(IDataProcessor processor)
    {
        this.processor = processor;
    }
    
    public void ProcessData(string data)
    {
        // Check cache first, then process
        processor.ProcessData(data);
    }
    
    // Missing ValidateData and GetStatus implementations!
}

Correct Approach:

				
					public class CachingDecorator : IDataProcessor
{
    private readonly IDataProcessor processor;
    private readonly Dictionary<string, string> cache = new();
    
    public CachingDecorator(IDataProcessor processor)
    {
        this.processor = processor;
    }
    
    public void ProcessData(string data)
    {
        if (!cache.ContainsKey(data))
        {
            processor.ProcessData(data);
            cache[data] = "processed";
        }
    }
    
    // Properly delegate ALL interface methods
    public void ValidateData(string data)
    {
        processor.ValidateData(data);
    }
    
    public string GetStatus()
    {
        return processor.GetStatus();
    }
}

Prevention Strategy: Use abstract base decorators and compiler warnings to catch missing implementations early.

Mistake #2: Creating Overly Deep Decorator Chains

The Problem: Building decorator chains that are too deep, making debugging nearly impossible and creating performance bottlenecks.

Why It Happens: The flexibility of the pattern can be addictive. Developers keep adding “just one more decorator” until the chain becomes unwieldy.

Signs of the Problem:

				
					// This chain is getting out of control
var notifier = new RetryDecorator(
    new CompressionDecorator(
        new EncryptionDecorator(
            new LoggingDecorator(
                new ValidationDecorator(
                    new CachingDecorator(
                        new MetricsDecorator(
                            new EmailNotifier("user@example.com")
                        )
                    )
                )
            )
        )
    )
);

Better Approach:

				
					public class NotifierBuilder
{
    private INotifier notifier;
    
    public NotifierBuilder(INotifier baseNotifier)
    {
        this.notifier = baseNotifier;
    }
    
    public NotifierBuilder AddLogging()
    {
        notifier = new LoggingDecorator(notifier);
        return this;
    }
    
    public NotifierBuilder AddEncryption()
    {
        notifier = new EncryptionDecorator(notifier);
        return this;
    }
    
    public NotifierBuilder AddRetry(int maxAttempts = 3)
    {
        notifier = new RetryDecorator(notifier, maxAttempts);
        return this;
    }
    
    public INotifier Build() => notifier;
}

// Usage - much more readable and manageable
var notifier = new NotifierBuilder(new EmailNotifier("user@example.com"))
    .AddLogging()
    .AddEncryption()
    .AddRetry()
    .Build();

Best Practice: Limit decorator chains to 3-5 levels maximum and use builder patterns for complex compositions.

Mistake #3: Violating the Single Responsibility Principle

The Problem: Creating decorators that do too many things, making them difficult to test, maintain, and reuse.

Wrong Approach:

				
					// This decorator does too many things - WRONG!
public class MegaDecorator : NotifierDecorator
{
    public MegaDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        // Validation
        if (string.IsNullOrWhiteSpace(message))
            throw new ArgumentException("Message cannot be empty");
        
        // Logging
        Console.WriteLine($"[LOG] Sending at {DateTime.Now}");
        
        // Encryption
        string encrypted = $"[ENCRYPTED: {message}]";
        
        // Compression
        string compressed = $"[COMPRESSED: {encrypted}]";
        
        // Retry logic
        for (int i = 0; i < 3; i++)
        {
            try
            {
                base.Send(compressed);
                break;
            }
            catch
            {
                if (i == 2) throw;
                Thread.Sleep(1000);
            }
        }
        
        Console.WriteLine("[LOG] Sent successfully");
    }
}

Correct Approach:

				
					// Separate decorators for each responsibility
public class ValidationDecorator : NotifierDecorator
{
    public ValidationDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        if (string.IsNullOrWhiteSpace(message))
            throw new ArgumentException("Message cannot be empty");
        
        base.Send(message);
    }
}

public class CompressionDecorator : NotifierDecorator
{
    public CompressionDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        string compressed = $"[COMPRESSED: {message}]";
        base.Send(compressed);
    }
}

public class RetryDecorator : NotifierDecorator
{
    private readonly int maxAttempts;
    
    public RetryDecorator(INotifier notifier, int maxAttempts = 3) : base(notifier)
    {
        this.maxAttempts = maxAttempts;
    }
    
    public override void Send(string message)
    {
        for (int i = 0; i < maxAttempts; i++)
        {
            try
            {
                base.Send(message);
                return;
            }
            catch
            {
                if (i == maxAttempts - 1) throw;
                Thread.Sleep(1000 * (i + 1)); // Exponential backoff
            }
        }
    }
}

Mistake #4: Writing Code Against Concrete Types Instead of Abstractions

The Problem: Testing for specific concrete types breaks the transparency that makes the Decorator Pattern powerful.

Wrong Approach:

				
					public class NotificationService
{
    public void ProcessNotification(INotifier notifier, string message)
    {
        // This breaks if notifier is decorated - WRONG!
        if (notifier is EmailNotifier emailNotifier)
        {
            // Apply email-specific discount or special handling
            message += " [EMAIL DISCOUNT: 10% OFF]";
        }
        
        notifier.Send(message);
    }
}

Correct Approach:

				
					public interface INotifier
{
    void Send(string message);
    NotifierType Type { get; }
}

public enum NotifierType
{
    Email,
    SMS,
    Push
}

public class EmailNotifier : INotifier
{
    public NotifierType Type => NotifierType.Email;
    // Implementation...
}

public abstract class NotifierDecorator : INotifier
{
    protected readonly INotifier notifier;
    
    protected NotifierDecorator(INotifier notifier)
    {
        this.notifier = notifier;
    }
    
    // Properly expose the underlying type
    public virtual NotifierType Type => notifier.Type;
    
    public virtual void Send(string message)
    {
        notifier.Send(message);
    }
}

public class NotificationService
{
    public void ProcessNotification(INotifier notifier, string message)
    {
        // Work with the interface, not concrete types
        if (notifier.Type == NotifierType.Email)
        {
            message += " [EMAIL DISCOUNT: 10% OFF]";
        }
        
        notifier.Send(message);
    }
}

Mistake #5: Ignoring Thread Safety in Stateful Decorators

The Problem: Creating decorators with mutable state that isn’t thread-safe, leading to race conditions and unpredictable behavior in multi-threaded applications.

Problematic Code:

				
					// This decorator has thread safety issues - WRONG!
public class CountingDecorator : NotifierDecorator
{
    private int messageCount = 0; // Shared mutable state
    
    public CountingDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        messageCount++; // Race condition!
        Console.WriteLine($"Message #{messageCount}");
        base.Send(message);
    }
    
    public int GetMessageCount() => messageCount;
}

Thread-Safe Approach:

				
					public class CountingDecorator : NotifierDecorator
{
    private int messageCount = 0;
    private readonly object lockObject = new object();
    
    public CountingDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        int currentCount;
        lock (lockObject)
        {
            currentCount = ++messageCount;
        }
        
        Console.WriteLine($"Message #{currentCount}");
        base.Send(message);
    }
    
    public int GetMessageCount()
    {
        lock (lockObject)
        {
            return messageCount;
        }
    }
}

Even Better – Immutable Approach:

				
					public class CountingDecorator : NotifierDecorator
{
    private readonly IMessageCounter counter;
    
    public CountingDecorator(INotifier notifier, IMessageCounter counter) 
        : base(notifier)
    {
        this.counter = counter;
    }
    
    public override void Send(string message)
    {
        int currentCount = counter.Increment();
        Console.WriteLine($"Message #{currentCount}");
        base.Send(message);
    }
}

public interface IMessageCounter
{
    int Increment();
    int Current { get; }
}

public class ThreadSafeMessageCounter : IMessageCounter
{
    private int _count = 0;
    
    public int Increment() => Interlocked.Increment(ref _count);
    public int Current => _count;
}

Mistake #6: Poor Error Handling in Decorator Chains

The Problem: Not properly handling exceptions that bubble up through decorator chains, making debugging and error recovery extremely difficult.

Wrong Approach:

				
					public class LoggingDecorator : NotifierDecorator
{
    public LoggingDecorator(INotifier notifier) : base(notifier) { }
    
    public override void Send(string message)
    {
        Console.WriteLine($"[LOG] Sending: {message}");
        
        // Exception from inner decorators will bubble up without context
        base.Send(message);
        
        Console.WriteLine("[LOG] Sent successfully");
    }
}

Better Approach:

				
					public class LoggingDecorator : NotifierDecorator
{
    private readonly ILogger logger;
    
    public LoggingDecorator(INotifier notifier, ILogger logger) : base(notifier)
    {
        this.logger = logger;
    }
    
    public override void Send(string message)
    {
        logger.LogInformation("Starting notification send for message: {Message}", message);
        
        try
        {
            base.Send(message);
            logger.LogInformation("Successfully sent notification");
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Failed to send notification for message: {Message}", message);
            
            // Add context to the exception
            throw new NotificationException(
                $"Logging decorator failed to send message: {message}", ex);
        }
    }
}

public class NotificationException : Exception
{
    public NotificationException(string message, Exception innerException) 
        : base(message, innerException) { }
}

Mistake #7: Overusing the Pattern Where Inheritance Would Suffice

The Problem: Applying the Decorator Pattern in situations where simple inheritance or composition would be more appropriate, adding unnecessary complexity.

When NOT to Use Decorators:

				
					// Simple extension that doesn't change at runtime - inheritance is fine
public class UrgentEmailNotifier : EmailNotifier
{
    public UrgentEmailNotifier(string email) : base(email) { }
    
    public override void Send(string message)
    {
        base.Send($"URGENT: {message}");
    }
}

When TO Use Decorators:

				
					// Dynamic behavior that can be combined in various ways
public class UrgencyDecorator : NotifierDecorator
{
    private readonly UrgencyLevel level;
    
    public UrgencyDecorator(INotifier notifier, UrgencyLevel level) : base(notifier)
    {
        this.level = level;
    }
    
    public override void Send(string message)
    {
        string prefix = level switch
        {
            UrgencyLevel.Low => "FYI: ",
            UrgencyLevel.Medium => "IMPORTANT: ",
            UrgencyLevel.High => "URGENT: ",
            UrgencyLevel.Critical => "🚨 CRITICAL: ",
            _ => ""
        };
        
        base.Send($"{prefix}{message}");
    }
}

public enum UrgencyLevel
{
    Low,
    Medium,
    High,
    Critical
}

Best Practices for Implementing the Decorator Pattern in C#

Now that we’ve covered the common mistakes, let’s explore the best practices that will help you implement the Decorator Pattern effectively.

Use Dependency Injection for Decorator Management

Modern C# applications benefit greatly from integrating the Decorator Pattern with dependency injection frameworks:

				
					// Program.cs for .NET 6+
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton<EmailNotifier>();
builder.Services.Decorate<INotifier, LoggingDecorator>();
builder.Services.Decorate<INotifier, RetryDecorator>();
builder.Services.Decorate<INotifier, EncryptionDecorator>();

var app = builder.Build();

Implement Proper Configuration

Create configuration classes for complex decorators:

				
					public class RetryDecoratorConfig
{
    public int MaxAttempts { get; set; } = 3;
    public TimeSpan InitialDelay { get; set; } = TimeSpan.FromSeconds(1);
    public double BackoffMultiplier { get; set; } = 2.0;
}

public class RetryDecorator : NotifierDecorator
{
    private readonly RetryDecoratorConfig config;
    
    public RetryDecorator(INotifier notifier, RetryDecoratorConfig config) 
        : base(notifier)
    {
        this.config = config;
    }
    
    public override void Send(string message)
    {
        var delay = config.InitialDelay;
        
        for (int attempt = 1; attempt <= config.MaxAttempts; attempt++)
        {
            try
            {
                base.Send(message);
                return;
            }
            catch (Exception ex) when (attempt < config.MaxAttempts)
            {
                Thread.Sleep(delay);
                delay = TimeSpan.FromMilliseconds(delay.TotalMilliseconds * config.BackoffMultiplier);
            }
        }
    }
}

Create Comprehensive Unit Tests

Test decorators both independently and in chains:

				
					[Test]
public void LoggingDecorator_Should_Log_Before_And_After_Send()
{
    // Arrange
    var mockNotifier = new Mock<INotifier>();
    var mockLogger = new Mock<ILogger>();
    var decorator = new LoggingDecorator(mockNotifier.Object, mockLogger.Object);
    
    // Act
    decorator.Send("test message");
    
    // Assert
    mockLogger.Verify(x => x.LogInformation(
        It.Is<string>(s => s.Contains("Starting notification send")), 
        "test message"), Times.Once);
    
    mockNotifier.Verify(x => x.Send("test message"), Times.Once);
    
    mockLogger.Verify(x => x.LogInformation(
        It.Is<string>(s => s.Contains("Successfully sent"))), Times.Once);
}

[Test]
public void Decorator_Chain_Should_Process_In_Correct_Order()
{
    // Arrange
    var logs = new List<string>();
    var baseNotifier = new TestNotifier(logs);
    
    var decorated = new LoggingDecorator(
        new EncryptionDecorator(baseNotifier), 
        new TestLogger(logs));
    
    // Act
    decorated.Send("test");
    
    // Assert
    Assert.That(logs, Is.EqualTo(new[]
    {
        "LOG: Starting send",
        "ENCRYPT: test",
        "SEND: [ENCRYPTED: test]",
        "LOG: Sent successfully"
    }));
}

Real-World Application: Building a Flexible Data Processing Pipeline

Let’s put everything together with a comprehensive example that demonstrates the Decorator Pattern in action. We’ll build a data processing pipeline that can be configured dynamically based on requirements.

				
					public interface IDataProcessor
{
    Task<ProcessingResult> ProcessAsync(DataItem item);
}

public class DataItem
{
    public string Id { get; set; }
    public string Content { get; set; }
    public Dictionary<string, object> Metadata { get; set; } = new();
}

public class ProcessingResult
{
    public bool Success { get; set; }
    public string ProcessedContent { get; set; }
    public TimeSpan ProcessingTime { get; set; }
    public List<string> Warnings { get; set; } = new();
}

// Base processor
public class BasicDataProcessor : IDataProcessor
{
    public async Task<ProcessingResult> ProcessAsync(DataItem item)
    {
        var stopwatch = Stopwatch.StartNew();
        
        // Simulate processing
        await Task.Delay(100);
        
        return new ProcessingResult
        {
            Success = true,
            ProcessedContent = item.Content.ToUpperCase(),
            ProcessingTime = stopwatch.Elapsed
        };
    }
}

// Abstract decorator base
public abstract class DataProcessorDecorator : IDataProcessor
{
    protected readonly IDataProcessor processor;
    
    protected DataProcessorDecorator(IDataProcessor processor)
    {
        this.processor = processor ?? throw new ArgumentNullException(nameof(processor));
    }
    
    public virtual async Task<ProcessingResult> ProcessAsync(DataItem item)
    {
        return await processor.ProcessAsync(item);
    }
}

// Validation decorator
public class ValidationDecorator : DataProcessorDecorator
{
    public ValidationDecorator(IDataProcessor processor) : base(processor) { }
    
    public override async Task<ProcessingResult> ProcessAsync(DataItem item)
    {
        if (string.IsNullOrWhiteSpace(item?.Content))
        {
            return new ProcessingResult 
            { 
                Success = false, 
                Warnings = { "Invalid input: Content cannot be empty" } 
            };
        }
        
        return await base.ProcessAsync(item);
    }
}

// Caching decorator
public class CachingDecorator : DataProcessorDecorator
{
    private readonly IMemoryCache cache;
    private readonly TimeSpan cacheDuration;
    
    public CachingDecorator(IDataProcessor processor, IMemoryCache cache, TimeSpan? cacheDuration = null) 
        : base(processor)
    {
        this.cache = cache;
        this.cacheDuration = cacheDuration ?? TimeSpan.FromMinutes(10);
    }
    
    public override async Task<ProcessingResult> ProcessAsync(DataItem item)
    {
        string cacheKey = $"processed_{item.Id}_{item.Content.GetHashCode()}";
        
        if (cache.TryGetValue(cacheKey, out ProcessingResult cachedResult))
        {
            cachedResult.Warnings.Add("Retrieved from cache");
            return cachedResult;
        }
        
        var result = await base.ProcessAsync(item);
        
        if (result.Success)
        {
            cache.Set(cacheKey, result, cacheDuration);
        }
        
        return result;
    }
}

// Metrics decorator
public class MetricsDecorator : DataProcessorDecorator
{
    private readonly IMetricsCollector metricsCollector;
    
    public MetricsDecorator(IDataProcessor processor, IMetricsCollector metricsCollector) 
        : base(processor)
    {
        this.metricsCollector = metricsCollector;
    }
    
    public override async Task<ProcessingResult> ProcessAsync(DataItem item)
    {
        var stopwatch = Stopwatch.StartNew();
        
        try
        {
            var result = await base.ProcessAsync(item);
            
            metricsCollector.RecordProcessingTime(stopwatch.Elapsed);
            metricsCollector.IncrementCounter(result.Success ? "success" : "failure");
            
            return result;
        }
        catch (Exception ex)
        {
            metricsCollector.IncrementCounter("error");
            metricsCollector.RecordException(ex);
            throw;
        }
    }
}

When to Use the Decorator Pattern vs. Alternatives

Understanding when to use the Decorator Pattern is crucial for making good architectural decisions. Here’s a decision framework:

Use Decorator Pattern When:

  • You need to add responsibilities to objects dynamically
  • You want to avoid an explosion of subclasses
  • You need to combine multiple behaviors in various combinations
  • The core object comes from a third-party library you cannot modify
  • You’re following the Open-Closed Principle strictly

Consider Alternatives When:

  • Simple Extension: Use inheritance for straightforward extensions that won’t change
  • Behavioral Changes: Use Strategy Pattern when you need to swap entire algorithms
  • State-Dependent Behavior: Use State Pattern when behavior depends on object state
  • Cross-Cutting Concerns: Use Aspect-Oriented Programming (AOP) for logging, security, etc.

Performance Considerations and Optimization Tips

The Decorator Pattern can introduce performance overhead due to method call chains and object creation. Here are strategies to mitigate these concerns:

Minimize Object Creation:

				
					// Use object pooling for frequently created decorators
public class DecoratorPool<T> where T : class, new()
{
    private readonly ConcurrentQueue<T> pool = new();
    
    public T Rent()
    {
        if (pool.TryDequeue(out T item))
            return item;
        
        return new T();
    }
    
    public void Return(T item)
    {
        // Reset item state
        pool.Enqueue(item);
    }
}

Cache Decorated Objects:

				
					public class DecoratedNotifierFactory
{
    private readonly ConcurrentDictionary<string, INotifier> cache = new();
    
    public INotifier CreateNotifier(NotifierConfig config)
    {
        string key = config.GetCacheKey();
        
        return cache.GetOrAdd(key, _ => BuildNotifier(config));
    }
    
    private INotifier BuildNotifier(NotifierConfig config)
    {
        INotifier notifier = new EmailNotifier(config.Email);
        
        if (config.EnableLogging)
            notifier = new LoggingDecorator(notifier);
            
        if (config.EnableEncryption)
            notifier = new EncryptionDecorator(notifier);
            
        return notifier;
    }
}

Conclusion: Mastering the Decorator Pattern for Better C# Code

The Decorator Pattern is a powerful tool in your software design arsenal, but like any tool, it requires understanding and practice to use effectively. By avoiding the seven common mistakes we’ve covered and following the best practices outlined in this guide, you’ll be able to:

  • Create flexible, extensible systems that adapt to changing requirements
  • Write code that follows SOLID principles, particularly the Open-Closed Principle
  • Build maintainable applications with clear separation of concerns
  • Implement complex behavior combinations without creating class explosions

Remember that the key to success with the Decorator Pattern lies in understanding when to use it and when to choose alternatives. Start with simple implementations, test thoroughly, and gradually build up to more complex decorator chains as your confidence and understanding grow.

The next time you face a situation where you need to add functionality to existing objects dynamically, consider the Decorator Pattern. With the knowledge and examples from this guide, you’ll be well-equipped to implement it correctly and avoid the pitfalls that catch many developers.

Whether you’re building notification systems, data processing pipelines, or any other system that requires flexible behavior composition, the Decorator Pattern can help you create clean, maintainable, and extensible code that stands the test of time.