The Decorator Pattern & Extension Methods

People can get very ‘religious’ about design patterns. Folks in this category might think a software application is complete junk unless the code base has n number of patterns baked within. On the other hand, newcomers often think the entire topic is something mysterious or intrinsically difficult. In reality, design patterns are nothing more than a slick, formal way to solve common coding difficulties. The nice thing about classic design patterns in general, is that they are language-agnostic. Once the overall nature of the pattern is understood, developers can add meat to the bones using their language (and platform) of choice.

Numerous design patterns exist in the software world today, and ultimately nothing is preventing you from making your own (if people buy into it or not is another question). Furthermore, there is no ‘master list’ of patterns that all developers agree upon. While this is true, if you pick up any book on the subject, you will find a set of very common patterns most programmers agree are very useful. Many of these patterns were first formalized in the seminal book on the subject, Design Patterns: Elements of Reusable Object-Oriented Software (aka, the Gang of Four [GOF] book; not to be confused with the UK punk band of the same name).

In this post I thought I’d look at one GOF pattern, the decorator pattern, through the eyes of C#. As you will see, C# 2008 and higher provides a very useful shortcut to achieve the same end result (more or less) with minimal fuss and bother.

Breaking Down the Decorator Pattern

The decorator pattern provides a formal way to add new functionality to an existing type, without sub-classing. First question: What is wrong with classical inheritance? In and of itself, nothing is wrong with the good old Is-A relationship. It is very common to derive a new class from an existing base class in order to override a few virtual members, and add a pinch of new functionality.

However, what if the type in question is a sealed class? What if the type is a structure (which is always sealed in the first place)? What if the method you wish to modify was not defined as virtual? In these cases, classical inheritance offers no help. These are just a few simple examples of where the decorator pattern might be useful. The short answer is, when you apply the decorator pattern, you are able to add new functionality to non-extendible types.

Anyway, applying the design pattern often involves the following steps:

1. Identify the type you wish to decorate.
2. Identify the member (or members) of this type you wish to ‘decorate’ with new functionality.
3. Model these members in a .NET interface type, and implement it on the original class.
4. Create a brand new class which is responsible for ‘decorating’ the original type, and implement the same shared interface.
5. Define a member variable of the original class within the decorator (and provide a constructor to set it).
6. Decorate the type with new functionality!

This might sound complicated, but it is really not bad at all. However, one of the annoying aspects of design patterns is that they can often be implemented in numerous manners. For example, the decorator pattern does not require the use of strongly typed interfaces in some situations (you could fallback on classical inheritance to build a intermediate class).

Nevertheless, Let’s see some code.

Applying the Classic Decorator Pattern in C#

Assume the following sealed class, which represents a component you want to tweak:

// This is the existing class
// that we want to modify, without sub-classing.
public sealed class SimpleTextControl
{
  public string MyMessage { get; set; }
  public void Display()
  {
    Console.WriteLine(MyMessage);
  }
}

Now, lets say you want to spice up the way this class displays the internal text message (maybe with some color, borders, time stamps, etc). Because the class is sealed, you cannot simply create a subclass which overrides the Display() method (and the Display() method is not virtual to begin with!). To continue applying the decorator pattern, you could extract a new interface from SimpleTextControl named ITextDisplay:

public interface ITextDisplay
{
  void Display();
}

public sealed class SimpleTextControl : ITextDisplay
{
  ...
}

Now onto step four. Here is a decorator class which maintains a reference to a SimpleTextControl object, and injects the new text formatting logic within it’s own implementation of ITextDisplay. The important point to focus on here is that the original object has no idea it is being decorated with surrounding code:

class BoxedMyTextMessage : ITextDisplay
{
  // This is basically a hook to the unaltered object.
  ITextDisplay itfTextMsg = null;

  public BoxedMyTextMessage(ITextDisplay oldMsg)
  {
    itfTextMsg = oldMsg;
  }

  public void Display()
  {
    // Add customization and use ref to object.
    Console.WriteLine("****************************");
    itfTextMsg.Display();
    Console.WriteLine("****************************");
  }
}

Here is another decorator class, which adds a time stamp to the message data:

class TimeStamppedMyTextMessage : ITextDisplay
{
  ITextDisplay itfTextMsg = null;

  public TimeStamppedMyTextMessage(ITextDisplay oldMsg)
  {
    itfTextMsg = oldMsg;
  }

  public void Display()
  {
    itfTextMsg.Display();
    Console.WriteLine("-> Message sent at {0}", DateTime.Now);
  }
} 

At this point, we can use our decorator classes as so:

static void Main(string[] args)
{
  // Create an instance of the original type
  // and print the unaltered message.
  SimpleTextControl tm = new SimpleTextControl();
  tm.MyMessage = "Testing....1, 2, 3.";
  tm.Display();
  Console.WriteLine();

  // Now show the message decorated with a 'box'.
  BoxedMyTextMessage btm = new BoxedMyTextMessage(tm);
  btm.Display();
  Console.WriteLine();

  // Now with a time stamp!
  TimeStamppedMyTextMessage tstm = new TimeStamppedMyTextMessage(tm);
  tstm.Display();
  Console.WriteLine();
}

Here is the output of the previous example:

Cool! We have successfully added new functionality (the ability to change how the text is displayed) to an existing class, without subclasses and without method overriding. While the decorator pattern is certainly useful, there are a few problems. First of all, when you use this pattern, you end up with a number of ‘micro’ classes (such BoxedMyTextMessage and TimeStamppedMyTextMessage) which are used in limited circumstances. Second, this classic pattern requires that the original class ( SimpleTextControl in our example) implements the shared interface.

However, if the original class was packaged in a compiled .NET *.dll, the only way to implement this interface would be to dive deep into some gnarly reflection code, create dynamic assemblies, and possibly tinker with some low-level CIL code. As you might agree, most programmer’s would rather *not* bother with this.

Thankfully, .NET 3.5 introduced a new C# language features which allows you to decorate precompiled types. Even better, the amount of required code is far less than what we have seen so far.

Decorating Types using C# Extension Methods

Essentially, extension methods provide a very simple implementation of the formal decorator pattern. The type being extended is not modified in any way, however, via a spoonful of syntactic sugar, this appears to be the case.

Consider the following C# code, which re-creates the previous SimpleTextControl example using extension methods:

// This is the initial class.
class SimpleTextControl
{
  public string MyMessage { get; set; }

  public void Display()
  {
    Console.WriteLine(MyMessage);
  }
}

// This extension class adds new functionality
// to SimpleTextControl.
static class TextMessageExtensions
{
  public static void DisplayWithBorder(this SimpleTextControl tm)
  {
    Console.WriteLine("****************************");
    tm.Display();
    Console.WriteLine("****************************");
  }
  public static void DisplayWithTimeStamp(this SimpleTextControl tm)
  {
    tm.Display();
    Console.WriteLine("-> Message sent at {0}", DateTime.Now);
  }
}

Notice that the ‘extension class’ now takes the role of the previous ‘decorator classes’. Also notice that we no longer need to define a custom interface, as each extension method marks which type it is extending via the first parameter argument. Finally, notice that we have lost a bit of polymorphism, in that each extension method is uniquely named (we could recover this via method overloading provided each extension method offers additional arguments).

Here is some test code with the resulting output:

static void Main(string[] args)
{
  // VB: Dim tm as New MyTextMessage()
  SimpleTextControl tm = new SimpleTextControl();
  tm.MyMessage = "Hello?";
  tm.Display();
  Console.WriteLine();

  tm.DisplayWithBorder();
  Console.WriteLine();

  tm.DisplayWithTimeStamp();
  Console.WriteLine();
}

So there you have it. While extension methods certainly have a syntax which is quite different from the traditional decorator pattern, they can be used for the same end result. Beyond a reduction in typing time, C# extension methods are also very keen in that the original type is truly unmodified, unlike the classic decorator pattern, which typically requires the use of interface implementation.

That wraps up this introductory look at a simple design pattern, and a related C# simplification. If you would like more information on C# patterns, check out the MSDN Patterns and Practices Developer Center.

Happy coding!