Applying the Decorator Pattern to a DataGridView

Article Index:

After a bit of thought, I surmised that one possible solution to my problem was the Decorator design pattern…or at least a variation of it, as you will soon see.

From my past design experience, I knew that the Decorator pattern was useful for adding behavior without sub-classing but I had never seen an example of applying it to visual controls. Therefore, for inspiration, I did a bit of googling to see what other designers were doing. One of the closest matches I found was a series of short but excellent articles written by Zijian on The Code Project:

• Why Develop Custom Controls? Just Customize Generic Controls. Part 1: Flashing
• Why Develop Custom Controls? Just Customize Generic Controls.
  Part 2: InTextboxLabel
• Why Develop Custom Controls? Just Customize Generic Controls. Part 3: ColorComboBox

In Zijian’s articles, he initially had some uncertainty with naming his pattern, calling it the Agent pattern, the Parasite pattern and the Builder pattern before eventually concluding that it was probably an example of the Decorator pattern. I think the uncertainty probably arose from the fact that his solution did not follow the classic example of the Decorator pattern.

In the classic example of the Decorator pattern, the Decorator class not only wraps the object to be decorated (i.e. a “has-a” relationship) but it also extends the wrapped object’s class (i.e. an “is-a” relationship), as shown in this code snippet:

class Decorator : ThingToBeDecorated
{
  private ThingToBeDecorated thingToBeDecorated;

  public Decorator(ThingToBeDecorated thingToBeDecorated)
  {
    this.thingToBeDecorated = thingToBeDecorated;
  }

  // Code for adding additional behaviour to wrapped object
  public override void DoSomething()
  {
    thingToBeDecorated.DoSomething();
    this.doSomethingElse();
  }

  private void doSomethingElse()
  {
    // do something else...
  }
}

In Zijian’s design pattern, the Decorator class does NOT extend the wrapped object’s class. In other words, there is no “is-a” relationship. Therefore, his pattern is not a 100% pure example of the classic Decorator pattern.

James Cooper provides an alternative example of decorating a visual control in his book C# Design Patterns: A Tutorial. In Cooper’s example, he decorates a Button with a class that (indirectly anyway) has both an “is-a” and a “has-a” relationship to the Button being decorated. Specifically, Cooper’s decorator class extends (i.e. is-a) Panel and contains (i.e. has-a) Control. Again, this is not a 100% pure example of the classic Decorator pattern. If it were a pure example, the decorator would probably extend the Button class and contain a Button (instead of extending Panel and containing Control).

Nevertheless, as Cooper points out, and as I learned in developing my pattern, it is not always practical to follow the classic example of the Decorator pattern when decorating a visual control. For example, consider what would happen if we were visually designing a form with a DataGridView that we decorated three times with a decorator that extended DataGridView. Would the form show four visual representations of a DataGridView? Surely that is not our intention. We want one visual representation of a DataGridView that we dynamically add three new behaviors to.

Despite not completely following the classic Decorator pattern, I would argue that Cooper’s and Zijian’s examples, as well as mine, are similar enough to the Decorator pattern that we can say that they are indeed examples of the Decorator pattern. If you have another opinion, I welcome your comments.

Article Index: