Decorator In C#

Decorator design pattern falls under Structural Pattern of Gang of Four (GoF) Design Patterns in .NET. Decorator pattern is used to add new functionality to an existing object without changing its structure. Hence Decorator pattern provides an alternative way to inheritance for modifying the behavior of an object. In this lesson, we will learn,

• Decorator Design Pattern
• Implementation Guidelines
• Sample Implementation

Decorator Design Pattern

 

Gang of Four (GoF) at Dofactory states

 

“Attach additional responsibilities to an object dynamically. Decorator provides a flexible alternative to sub classing for extending functionality”.

• Decorator falls under the category of Structural Design pattern and is also knows as Wrapper.
• Decorator design pattern follows the Open Closed Principle, one of the SOLID principles.
• In other words, it helps to add new responsibilities to an individual instance of an object, without adding those responsibilities to the class of objects. Decorator can be thought of as an alternative to inheritance.

Implementation Guidelines

• Need to add responsibilities to individual objects dynamically and transparently.
• The extension by subclassing is impractical.
• Class definition may be hidden
• Classes are unavailable for subclassing

Decorator Pattern representation

 

The participants in a typical implementation of the Decorator design pattern include,

1. Component
   This represents the base type of the actual or the concrete type
   
   
2. Concrete Component
   This represents the concrete type that extends the base component. Note that the additional responsibilities or functionalities are added in this type.
   
   
3. Decorator
   This represents a reference to a component. The dynamic functionalities are added in this type.
   
   
4. ConcreteDecorator
   Objects are the classes which actually add responsibilities to the ConcreteComponent classes.

Sample Implementation

 

The classes, interfaces, and objects which we are going to use in sample implementation are identified as follows:

1. Employee: Component class
2. EmployeeConcrete: Concrete Component 
3. EmployeeDecorator: Decorator Class 
4. PermanentEmployeeDecorator: Concrete Decorate Class 
5. ContractEmployeeDecorator: Concrete Decorate class

Employee Class

public abstract class Employee {
    public abstract string Display();
}

Note

1. It doesn’t necessarily mean that you have to use abstract type.- the type may or may not be abstract.
2. You can also implement a decorator design pattern using interface. 
3. You can use methods that are virtual in your concrete classes. 

We are using abstract type here for the sake of simplicity.

 

EmployeeConcrete Class extends Employee class and adds additional properties

public class EmployeeConcrete: Employee {
    public string FirstName {
        set;
        get;
    }
    public string LastName {
        set;
        get;
    }
    public string Address {
        set;
        get;
    }
    public override string Display() {
        StringBuilder data = new StringBuilder();
        data.Append("First name: " + FirstName);
        data.Append("\nLast name: " + LastName);
        data.Append("\nAddress: " + Address);
        return data.ToString();
    }
}

The EmployeeDecorator class extends the Employee class, accepts an instance of the component class named Employee, and overrides the Display() method.

public class EmployeeDecorator: Employee {
    Employee _employee = null;
    public EmployeeDecorator(Employee employee) {
        this._employee = employee;
    }
    public override string Display() {
        return _employee.Display();
    }
}

Now the Component, Concrete Component and the decorator classes are ready. Now, we can extend the EmployeeDecorator class to create concrete decorator classes.

 

PermanentEmployeeDecorator class

public class PermanentEmployeeDecorator: EmployeeDecorator {
    //Add properties relevant to a permanent employee
    private double PF {
        get;
        set;
    }
    public PermanentEmployeeDecorator(Employee employee): base(employee) {}
    public override string Display() {
        return base.Display() + "\nEmployee type: Permanent";
    }
}

Assume that you can also have another type of employee -- a contractual employee. To represent it, you would need to create another class named ContractEmployeeDecorator that extends the EmployeeDecorator class.

public class ContractEmployeeDecorator: EmployeeDecorator {
    //Add properties relevant to a contract employee
    private double RatePerHour {
        get;
        set;
    }
    public ContractEmployeeDecorator(Employee employee): base(employee) {}
    public override string Display() {
        return base.Display() + "\nEmployee type: Contractual";
    }
}

Now, you can now create an instance of PermanentEmployeeDecorator and ContractEmployeeDecorator and use it as shown below.

class Program {
    static void Main(string[] args) {
        var permanentemployeeConcrete = new EmployeeConcrete {
            FirstName = "Prasad",
                LastName = "Raveendran",
                Address = "Isline, US"
        };
        var employeeDecorator = new PermanentEmployeeDecorator(permanentemployeeConcrete);
        Console.WriteLine(employeeDecorator.Display());
        var contractemployeeConcrete = new EmployeeConcrete {
            FirstName = "Praveen",
                LastName = "Raveendran",
                Address = "Houston, US"
        };
        var conemployeeDecorator = new ContractEmployeeDecorator(contractemployeeConcrete);
        Console.WriteLine(conemployeeDecorator.Display());
        Console.Read();
    }
}

We saw a brief formal introduction of the Decorator Pattern and then we had a look at a concrete problem that this construct is a natural fit for. Another example could have been a pizza shop or a car or bike configurator. Anything that deals with objects whose behaviors should be extendable dynamically would do.

 

I haven't personally used it outside of demos, but I can see it being useful in many circumstances. I'm also wondering if maybe ASP.NET MVC's “attributes” consider as the usage of the Decorator pattern, but I'm not sure (so if anyone can clear this up for me, it would be much appreciated).

 

Summary

 

The Decorator pattern seeks to dynamically add functionality to instances of objects at runtime, without needing to change the definition of the instance's class. This is especially useful in scenarios where different instances of the same object might behave differently

I hope you will enjoy the decorator Pattern while designing your software. Your valuable feedback or comments about this article are always welcome.