How and Where Decorator Design Pattern

The Decorator Design Pattern is one of the behavior patterns introduced by the GOF. The Decorator Design Pattern is used during development to provide extra functionality to existing types. So the Decorator Design Pattern allows developer to satisfy the SOLID rules:

1. Single Responsibility Principle: A class or function should do only one task and a class or function should have only one reason to change.
   
   
2. Open Close Principle: A class or function is open for extension but closed for modification.
   
   
3. Liskov Substitution type:  If type S is derived from type T then an object of type T can be replaced by an object of type S.

A decorator means a decor of a basic element to provide extra functionality. The following image is one of the presentations of decoration:



The image shows a gift with the basic box and the second image is decorated with gift wrap. Extra functionality is provided here is a good look at the basic gift using wrapping.

Simple Example of Design Pattern

The following image shows the class diagram of the basic Decorator Design Pattern:



IBasicService: Basic contract that needs to be implemented by derived types.

BasicServiceImplementation: Its basic/concrete implementation that is derived from interface, as it basic its provides basic functionality.

Decorator1OnBasic and Decorator2OnBasic: its decorated implementation that is derived from an interface. It's actually providing extra functionality over basic implementation.

Client: use a concrete implementation, it creates an instance of Decorate and used the functionality of it.

The code below is an implementation of the Decorator Design Pattern and the class diagram is discussed above.

namespace BasicDecoratorPattern
{
    public interface IBaseService
    {
        void Print();
    }

    public class BasicServiceImplementaion : IBaseService
    {
        public void Print()
        {
            Console.WriteLine("Basic Item");
        }
    }

    public class Decorator1OnBasic : IBaseService
    {
        private readonly IBaseService BasicRealTimeService;
        public Decorator1OnBasic(IBaseService service)
        {
            BasicRealTimeService = service;
        }

        public void Print()
        {
            BasicRealTimeService.Print();
            Console.WriteLine("Extra functionality from Decorator ONE");
        }
    }

    public class Decorator2OnBasic : IBaseService
    {
        private readonly IBaseService BasicRealTimeService;
        public Decorator2OnBasic(IBaseService service)
        {
            BasicRealTimeService = service;
        }

        public void Print()
        {
            BasicRealTimeService.Print();
            Console.WriteLine("Extra functionality from Decorator SECOND");
        }
    }

    public class Client
    {
        public Client()
        {
            IBaseService realTimeService = new BasicServiceImplementaion();

            IBaseService basicRealTimeServiceDecorator1 = new Decorator1OnBasic(realTimeService);
            IBaseService basicRealTimeServiceDecorator2 = new Decorator2OnBasic(realTimeService);

            basicRealTimeServiceDecorator1.Print();
            basicRealTimeServiceDecorator2.Print();
        }
    }
}

The following are points to remember in the preceding code implementation:

1. DecoratorOnBaisc uses an IBasicService instance as input to create an instance of a decorator class.
2. The client creates an instance of BasicServiceImplementation first and passes that instance to the decorator.
3. The decorator uses a basic implementation instance passed as an argument to it to provide basic functionality and extra functionality by decorating it.

Output



The output shows that the decorator adds extra functionality over the basic functionality. To understand it more, the following is another realistic example of the decorator pattern.

Realistic Example of Design Pattern

The following is a class diagram of a realistic use of the design pattern. The following class diagram represents a different kind of Milkshake (Mango and Chocolate) over a basic Milkshake.



Mapping with Basic Implementation.

IMilkShake is equal to IBasicService.

MilkShake is equeal to BasicImplementation.

MangoMilshake and ChoclateMilkShake is equal to Decorator1OnBasic and Decorator2OnBasic.

Note: In this implementation MilshakeDecorator is an abstract class that is derived from an IMilkShake and the Decorator of a MilkShake is derived from this decorator class. There are some common functionalities so this class is created but it doesn't affect the actual implementation of the Decorator pattern.

namespace RealWorldDecoratorPattern
{
    public interface IMilkShake
    {
        string Serve();
        int Price();
    }

    public class MilkShake : IMilkShake
    {
        public string Serve()
        {
            return "MilkShake";
        }

        public int Price()
        {
            return 30;
        }
    }

    public abstract class MilkshakeDecorator : IMilkShake
    {
        public readonly IMilkShake Milkshake;
        public MilkshakeDecorator(IMilkShake milkShake)
        {
            Milkshake = milkShake;
        }
        public string Flavour { get; set; }
        public int FlavourPrice { get; set; }

        public abstract string Serve();
        public abstract int Price();

    }

    public class MangoMilkShake : MilkshakeDecorator
    {
        public MangoMilkShake(IMilkShake milkShake)
            : base(milkShake)
        {
            this.Flavour = "Mango";
            this.FlavourPrice = 10;
        }

        public override string Serve()
        {
            return  "Serving " + this.Flavour + " " + Milkshake.Serve();
        }

        public override int Price()
        {
            return  this.FlavourPrice  + Milkshake.Price();
        }
    }

    public class ChoclateMilkShake : MilkshakeDecorator
    {
        public ChoclateMilkShake(IMilkShake milkShake)
            : base(milkShake)
        {
            this.Flavour = "Choclate";
            this.FlavourPrice = 20;
        }

        public override string Serve()
        {
            return "Serving "  + this.Flavour + " " + Milkshake.Serve();
        }

        public override int Price()
        {
            return this.FlavourPrice + Milkshake.Price();
        }
    }

    public class Client
    {
        public Client()
        {
            IMilkShake milkShake = new MilkShake();

            IMilkShake mangoMilkshake = new MangoMilkShake(milkShake);
            IMilkShake choclateMilkshake = new ChoclateMilkShake(milkShake);

            Console.WriteLine(mangoMilkshake.Serve());
            Console.WriteLine(mangoMilkshake.Price());

            Console.WriteLine();

            Console.WriteLine(choclateMilkshake.Serve());
            Console.WriteLine(choclateMilkshake.Price());
        }
    }

}

Output



In the preceding code the MilkShake Decorator class (Mango and Chocolate) uses the base Mikshake class. The Decorator class provides decoration on the basic Milkshake class and provides output using the basic implementation and extra functionality.

Use of Design Pattern in Application

The preceding two examples helps to explain the Decorator Design Pattern basics and realistic problems. But this section helps you to understand how to user a design pattern in applications, in other words where the developer can possibly use it in an application.

In the Decorator Design Pattern it is very helpful to provide cross-cutting concerns or aspect-oriented programming concepts like:

1. Authentication
2. Authorization
3. Logging
4. Caching
5. Validation
6. Exception Management

Apart from cross-cutting concerns as explained before, it can be used to decorate a class with extra added functionality, in other words it is not always true that you can use the decorator pattern just to provide cross-cutting concerns.

The following is a class diagram for caching a cross-cutting concern with the CachingDecorator.



IProvides equal to IBasicService: its contract has a GetProviderList.

Provider equal to BasicServiceImplementation: this example is a concrete implementation and is used to get a list of providers.

CacheProvider equal to DecoratorOnBasic: this is a decorator that does the task of caching fetched providers and when requested it provides cache data or if cache data is not available then it requests fresh data from the provider (basic) implementation.

namespace CacheDecoratorPattern
{
    public interface IProviders
    {
        NameValueCollection GetProviderList();
    }

    public class Providers : IProviders
    {
        public NameValueCollection GetProviderList()
        {
            NameValueCollection providerList = new NameValueCollection();
            providerList.Add("SQL", "SQLProvider");
            providerList.Add("Oracle", "OracleProvider");
            providerList.Add("MySQL", "MyProvider");
            return providerList;
        }
    }

    public class CacheProvider : IProviders
    {
        private readonly IProviders provider;

        private NameValueCollection CachedProviderList;

        public CacheProvider(IProviders provider)
        {
            this.provider = provider;
        }

        public NameValueCollection GetProviderList()
        {
            if(CachedProviderList == null)
                CachedProviderList = provider.GetProviderList();

            return CachedProviderList;
        }
    }

    public class Client
    {
        public Client()
        {
            IProviders provider = new Providers();
            CacheProvider cacheProvider = new CacheProvider(provider);

            var providerlist = cacheProvider.GetProviderList();
        }
    }
}

In the code CachProvider is a class that is a decorator over a Provider class and takes an IProvider as input. Since it is just an example, a cache value is stored in a private variable of CacheProvider, but in a real application this can be replaced by a real caching, in other words it can be a web application cache class or Enterprise application library cache block.

Decorator with Dependency injection Container

The following is just an example of code to register a decorator instance with the Microsoft Unity container.

Register Decorator

var container = new UnityContainer();
 container.RegisterType(
     typeof( IProvider ),
     typeof( Provider ),
     "BasicProvider"
 );
 contract.RegisterType(
     typeof( IProvider ),
     typeof( CacheProvider ),
    new InjectionConstructor(
        new ResolvedParameter(
            typeof( IProvider ),
            "BasicProvider"
        )
    )
);

So once it is registered, with the Resolve method of a container one can easily get an instance of the Decorator.

var contract = container.Resolve<IProvider>();

At the end it satisfied the SOLID principle

Single Responsibility Principle: As in the example basic implementation the Provider does the task that it is responsible, for example the fetching of the data in the last example. And the decorator is responsible for doing extra functionality, like CacheProvider does the task of caching the data, not the task of getting the data.

Open Close Principle: As the rule states, here the Basic implementation Provider is closed for the modification but open for extension that is done using CachProvider that extends the functionality of basic implementation.

Liksov Subtitution Principle: As rule sates here, the basic implementation of a Provider object is replaced by the parent type IProvider interface in the Decorator constructor where the Provider object is injected by the client class.

Note:

This is my point of view regarding patterns. I welcome feedback regarding this article and also if you find something wrong in this.