Design patterns are exactly what they sound like: templates or general solutions that can be applied over and over. Patterns generally are designed to be followed in spirit but not to the letter. Patterns generally come in three flavors: creational, structural, and behavioral. In this article, I show you one implementation of a design pattern, the Command pattern.

The Command pattern is a behavioral pattern. It provides a description of a way in which to encapsulate behaviors in classes. Doing so makes the behaviors easy to use and easy to track, and it becomes convenient to implement a symmetric opposite behavior. The canonical example is the generic Do and Undo behavior common in most text editors.

Here, I show you an implementation of the Command Behavior Pattern with the .NET 2.0 MenuStrip control, and the StickMan sample program from my book, Visual Basic .NET Power Coding (published by Addison Wesley).

Implementing the Command Behavior Pattern

The Command pattern typical has a Do method and a symmetric Undo method, and I like to add a CanUndo Boolean property. You can implement the Command pattern using an interface or an abstract class.

In our example, I used an interface for a very specific reason. The benefit of an interface is that we get the same aspect, facet, connection points — or however you like to think of interfaces — but the actual Commands do not have to share anything else in common. If we used an abstract class, then we would be saying that all Commands have a common ancestry and hence common constructors. That doesn't fit for this example. The ExitCommand exits the application, but the MoveCommand classes need an actor: the thing to move. Thus, the thing acted on is different.

Tip: Use abstract classes and inheritance only when you have a common genealogy. Use interfaces when you have common capability but not genealogical ancestry or similarities. Dogs and humans can both run (an interface), but if you were describing mammalian similarities then both could inherit from a class mammal (a class).

It is this subjective nature of design decisions that make it essential that design patterns not be rigidly adhered to. (Plus, there is no pattern Gestapo.)

Defining the ICommand Interface

The classic definition of the Command pattern uses an abstract class for the base Command, and introduces a Receiver, Invoker, Client, and ConcreteCommand. You don't necessarily have to create each of these elements specifically; depending on the context, some of these may exist implicitly. In our example, you will see that the Client, Invoker, and Receiver are all implicitly played by the WinForm.

To begin, let's start with the implementation of the ICommand interface shown in Listing 1.

Listing 1: The ICommand interface will be implemented by every class that plays the role of a Command.

using System;
using System.Collections.Generic;
using System.Text;

namespace CommandPattern
{
  public interface ICommand
  {
    void Do();
    void Undo();
    bool CanUndo{ get; }
  }
}

Every class that represents a Command needs to implement Do, Undo, and CanUndo members. For categories of commands — such as commands that all support undo — we can introduce a common base class and get all of the work in one spot.