The Decorator! Detailed Look at Design Pattern

Key takeaways

• The decorator is a structural design pattern that uses composition instead of inheritance
• It provides a flexible alternative to sub-classing for extending functionality at runtime
• By enforcing open-close principle it promotes code extension

Introduction

Decorator design pattern is a structural pattern that enables us to add/change object behavior at runtime. If we refer to SOLID principles, more precisely open-closed responsibility principle, classes should be open for extension but closed for modification. In other words, we should be able to add new behavior to existing classes but we should prevent any modification of existing code. This is exactly what decorator pattern does so let’s take a look at pattern UML diagram:

If you take a look at the diagram you’ll see that decorator has:

• Component - This is basically an interface that describers behavior of concrete component as well as decorator. Depending on existing project structure, this could be an interface or abstract class.
• ConcreteComponent - The actual object in which the new functionalities can be added dynamically. We can also wrap up decorators with other decorators.
• Decorator - Defines the interface for all the dynamic functionalities that can be added to the concrete component. The decorator IS a component and also HAS a component. This way components and decorators are interchangeable.
• ConcreteDecorator - Describes all the functionalities that can be added to the concrete components.

Basically, the decorator is a wrapper around concrete components or another decorator. This way we can use composition instead of inheritance to share behavior between different components.

POC

We have already mentioned that decorator is an alternative to sub-classing, so why we are not using sub-classing? Well, let’s say we need 5 different functionalities (A; B; C; D; E) for our application. This means we need 5 sub-classes. But what if we also we need to support all possible combinations for two functionalities? If we follow formula for calculating all possible combinations, we’ll get that there are 10 combinations! In other words, we need to create ten more sub-classes for each combination…

List of all possible functionalities (every decorator represents the unique functionality):

• ConcreteDecoratorA ConcreteDecoratorB
• ConcreteDecoratorA ConcreteDecoratorC
• ConcreteDecoratorA ConcreteDecoratorD
• ConcreteDecoratorA ConcreteDecoratorE
• ConcreteDecoratorB ConcreteDecoratorC
• ConcreteDecoratorB ConcreteDecoratorD
• ConcreteDecoratorB ConcreteDecoratorE
• ConcreteDecoratorC ConcreteDecoratorD
• ConcreteDecoratorC ConcreteDecoratorE
• ConcreteDecoratorD ConcreteDecoratorE

You can see that we are going to end up with a lot of classes, so this is where our pattern kicks in! Let’s take a look at code:

Component

public interface IComponent
{
   void Operation();
}

Concrete component

public class ConcreteComponent : Interface.IComponent
{
   public void Operation(){
      Console.WriteLine("ConcreteComponent.Operation()");
   }
}

Decorator

public abstract class Decorator : Interface.IComponent
{
   protected Interface.IComponent component;

   public void SetComponent(Interface.IComponent component){
      this.component = component;
   }

   public virtual void Operation(){
      if (component != null)
      {
         component.Operation();
      }
    }
}

Concrete decorator

Example of concrete decorator (A):

public class ConcreteDecoratorA : Decorator.Decorator
{
   public override void Operation(){
      base.Operation();
      Console.WriteLine("ConcreteDecoratorA.Operation()");
    }
}

Main method

static void Main(string[] args)
{
   Console.WriteLine("<<< Concreate component >>>");
   // Concreate componentvar concreateComponent = new
                            ConcreteComponent.ConcreteComponent();
   concreateComponent.Operation();
   Console.WriteLine("\n<<< Concrete decorator A >>>");
   // Concrete decorator Avar concreteDecoratorA = new    
                            ConcreteDecorators.ConcreteDecoratorA();
   concreteDecoratorA.Operation();
   
   Console.WriteLine("\n<<< Concrete decorator B >>>");
   
   // Concrete decorator Bvar concreteDecoratorB = new  
                            ConcreteDecorators.ConcreteDecoratorB();
   
   concreteDecoratorB.Operation();
   
   Console.WriteLine("\n<<< Concrete decorator C >>>");
   
   // Concrete decorator Cvar concreteDecoratorC = new 
                            ConcreteDecorators.ConcreteDecoratorC();
   concreteDecoratorC.Operation();
   
   Console.WriteLine("\n<<< Concrete decorator D >>>");
   
   // Concrete decorator Dvar concreteDecoratorD = new 
                            ConcreteDecorators.ConcreteDecoratorD();
   concreteDecoratorD.Operation();
   Console.WriteLine("\n<<< Concrete decorator E >>>");
   
   // Concrete decorator Evar concreteDecoratorE = new 
                            ConcreteDecorators.ConcreteDecoratorE();
   concreteDecoratorE.Operation();
   
   Console.WriteLine("\n<<< Decorated Component with decorators: 
                            A, B >>>");
   
   // Decorated Component
   concreteDecoratorA.SetComponent(concreateComponent);
   concreteDecoratorB.SetComponent(concreteDecoratorA);
   concreteDecoratorB.Operation();
   Console.WriteLine("\n<<< Decorated Component with decorators: 
                            A, C >>>");
   
   // Concreate component
   concreateComponent = new ConcreteComponent.ConcreteComponent();
   // Decorated Component
   concreteDecoratorA.SetComponent(concreateComponent);
   concreteDecoratorC.SetComponent(concreteDecoratorA);
   concreteDecoratorC.Operation();
   Console.WriteLine("\n<<< Decorated Component with decorators: 
                            C, D, E >>>");
  
   // Concreate component
   concreateComponent = new ConcreteComponent.ConcreteComponent();
   
   // Decorated Component
   concreteDecoratorC.SetComponent(concreateComponent);
   concreteDecoratorD.SetComponent(concreteDecoratorC);
   concreteDecoratorE.SetComponent(concreteDecoratorD);
   concreteDecoratorE.Operation();
   Console.ReadKey();
}

Result

Here is how result looks like:

In the given example we can see the main advantage of decorator pattern is the ability to attach additional functionality at run-time and also it enables us to decorate our component with different functionalities in a clean and reusable way.

Real world example

We already saw how decorator works and what are main advantages so now let’s apply everything to a real world scenario. To better understand everything, check blog I wrote earlier:

• Designing Flexible And Cross-Platform API Using Asp.Net Core

because we’ll be using existing code base to demonstrate usage of design pattern. We are going to decorate existing repository in .Net Core API and add caching and logging functionality. Let’s start!

Component

In our example we’ll use IBookRepository as a starting point. This is our Component.

public interface IBookRepository
{
   Task<IEnumerable<Book>> GetAllAsync();
   Task<Book> GetByIdAsync(int id);
   Task CreateAsync(Book value);
   Task UpdateAsync(Book value);
   Task DeleteAsync(int value);
}

Concrete component

BooksRepository represent the concrete component.

public class BooksRepository : GenericRepository<Book>, IBookRepository
{
   public BooksRepository(DataContext context) : base(context) { }

   public async Task<IEnumerable<Book>> GetAllAsync()
   {
      return await FindAllAsync();
   }

   public async Task<Book> GetByIdAsync(int id)
   {
      var books = await FindByConditionAync(o => o.Id == id);
      if (books == null)
          return null;
     
      return books.SingleOrDefault();
    }

    public async Task UpdateAsync(Book book)
    {
       Update(book);
       await SaveAsync();
    }

    public async Task DeleteAsync(int id)
    {
       var book = await this.GetByIdAsync(id);
       Delete(book);
       await SaveAsync();
    }

    public async Task CreateAsync(Book book)
    {
      Create(book);
      await SaveAsync();
    }
}

The decorator

Now, let’s create the decorator class:

public abstract class BaseDecorator : IBookRepository
{
   protected IBookRepository libraryItem;

   public BaseDecorator(IBookRepository libraryItem)
   {
      this.libraryItem = libraryItem;
   }
   
   public async Task CreateAsync(Book value)
   {
      await libraryItem.CreateAsync(value);
   }

   public async Task DeleteAsync(int value)
   {
      await libraryItem.DeleteAsync(value);
   }

   public virtual async Task<IEnumerable<Book>> GetAllAsync()
   {
      return await libraryItem.GetAllAsync();
   }

   public async Task<Book> GetByIdAsync(int id)
   {
      return await libraryItem.GetByIdAsync(id);
   }

   public async Task UpdateAsync(Book value)
   {
      await libraryItem.UpdateAsync(value);
   }
}

Concrete decorators

We have created component, concrete component and decorator so now let’s create concrete decorators. As I already mentioned, we are going to add two new functionalities to our repository (caching - caching decorator and logging - logging decorator).

Caching

Here is an example of caching decorator for GET method:

public class CachingDecorator : BaseDecorator
{
   IMemoryCache _cache;
   
   public CachingDecorator(IBookRepository libraryItem, 
                           IMemoryCache cache) : 
                           base(libraryItem)
   {
      _cache = cache;
   }

   public override async Task<IEnumerable<Book>> GetAllAsync()
   {
      IEnumerable<Book> cacheEntry;
      
      // Look for cache key.if (!_cache.TryGetValue(CacheKeys.Entry, out cacheEntry))
      {
         // Key not in cache, so get data.
         cacheEntry = await libraryItem.GetAllAsync();
         // Set cache options.var cacheEntryOptions = new MemoryCacheEntryOptions()// Keep in cache for this time, reset time if accessed.
         .SetSlidingExpiration(TimeSpan.FromSeconds(10));
         // Save data in cache.
         _cache.Set(CacheKeys.Entry, cacheEntry, cacheEntryOptions);
         
         return cacheEntry;
      }
    
      return (IEnumerable<Book>)_cache.Get(CacheKeys.Entry);
   }
}

Logging

Here is example of logging decorator for GET method:

public class LogingDecorator : BaseDecorator
{
   public LogingDecorator(IBookRepository libraryItem) : 
                          base(libraryItem) { }
   public override async Task<IEnumerable<Book>> GetAllAsync()
   {
      // Log data ...return await libraryItem.GetAllAsync();
   }
}

Register decorator

The dependency injection framework in .NET Core is pretty good but out-of-the-box it doesn’t support this pattern very well. We have to write extra some code in order to make everything working. Here is an article which explains different approaches as well as their pros and cons: Decorators in .NET Core with Dependency Injection.

Let’s create helper class:

public static class ServiceCollectionExtensions
{
    public static void Decorate<TInterface, TDecorator>(this ?    
    IServiceCollection services)
      where TInterface : class
      where TDecorator : class, TInterface
    {
        // grab the existing registration
        var wrappedDescriptor = services.FirstOrDefault(
          s => s.ServiceType == typeof(TInterface));


        // check it's valid
        if (wrappedDescriptor == null)
            throw new InvalidOperationException($"  
        {typeof(TInterface).Name} is not registered");


        // create the object factory for our decorator type,
        // specifying that we will supply TInterface explicitly
        var objectFactory = ActivatorUtilities.CreateFactory(
          typeof(TDecorator),
          new[] { typeof(TInterface) });


        // replace the existing registration with one
        // that passes an instance of the existing registration
        // to the object factory for the decorator
        services.Replace(ServiceDescriptor.Describe(
          typeof(TInterface),
          s => (TInterface)objectFactory(s, new[] { 
          s.CreateInstance(wrappedDescriptor) }),
          wrappedDescriptor.Lifetime)
        );
    }

    private static object CreateInstance(this IServiceProvider 
    services, ServiceDescriptor descriptor)
    {
        if (descriptor.ImplementationInstance != null)
            return descriptor.ImplementationInstance;


        if (descriptor.ImplementationFactory != null)
            return descriptor.ImplementationFactory(services);


        return 
        ActivatorUtilities.GetServiceOrCreateInstance(services, 
        descriptor.ImplementationType);
    }
}

Inject decorators

Now we should be able to register our decorators with a few lines of code:

services.Decorate<IBookRepository, CachingDecorator>();
services.Decorate<IBookRepository, LogingDecorator>();

That’s it!

We explained the basic concepts behind decorator pattern and also how to apply it to the real world scenarios. We have decorated repository with caching and logging features in a clean and reusable way.