Total votes: 2
Category: Design Patterns
Print: Print Article
Please login to rate or to leave a comment.
Published: 06 Oct 2008
Download Sample Code
In this part of the design patterns series we investigate the command pattern and its uses.
The command pattern is interesting in that it’s the first pattern that we will have investigated that is concerned with actions. Specifically, the encapsulation of actions. This pattern provides the blueprint for us to encapsulate actions for both simple and advanced design scenarios.
Design Patterns Series
Part 1 Learn how to design more robust and maintainable code by incorporating design patterns into your software projects.
Part 2 This part shows the observer design pattern.
Part 3 In this part you will learn about the factory pattern.
Part 4 This part of the design patterns covers the singleton pattern.
Part 5 In this part of the design patterns series we investigate the command pattern and its uses.
Part 6 In this part of the design patterns series we will look at the adapter pattern.
Part 7 In this part of the design patterns series we will take a look at the template pattern.
The Command Pattern
If there is one thing that you take out of this article it’s that the command pattern is concerned with encapsulating invocation. The invocation referring to a method which contains the necessary to perform one or more actions.
Before we proceed any further we will take a little time to look at some key roles within the command pattern and discuss them. These key roles namely consist of an invoker, command, and receiver. In some descriptions of the command pattern you will also come across a client. We will return to the client and its role later on.
Let us assume that you have just come home from work and within your household there are several people who all want you to do something. Now let us further assume that you are a pretty primitive person in that you can only remember one of the requested commands at any one time.
To continue our analogy as you walk through the front door one of the members in the household requests that you turn on the hot water. The request requires you to go to the boiler and flip the switch so that everyone tonight can have a nice hot shower. If we pause for a slight moment here we can observe a few things about the scenario. We know that people can indeed perform various different tasks; we could further say that each task could be represented as a command. Just as we received a request to turn the hot water on, we may also have received a request from another member in the household to fix their computer.
Turning the hot water on and fixing another members computer are commands that we have been assigned. As a person we know how to execute several commands each of which vary to some degree.
Keep this scenario loaded in your mind for a few minutes.
As the name implies one would expect the invoker to invoke, or trigger something. Our assumptions are indeed correct. The invoker has the responsibility of triggering the execution of a command, or possibly a number of commands.
Using the scenario we described before, we, the
Person are the invoker. We have the knowhow to perform various actions. Flipping the switch on the boiler to turn the hot water on is an action that we are fully capable of performing. Our skills don’t just stop there, we can perform many other actions, e.g. we can bring the washing in, or perhaps go do the shopping. The bounds of our capabilities are indeed limitless (well, nearly).
In our example scenario the command is clear – switch the hot water on. The command requires us to perform an action. As we will see in the implementation the command not only encapsulates an action but also the receiver in which the action is to be performed upon (discussed later).
A command typically contains the required within a method called
Execute. This method will perform its actions upon the receiver provided.
What is the thing that we have been requested to perform the action upon? In our example scenario the
Boiler is the receiver. The command given to us therefore requires us to walk up to the
Boiler and flip the hot water switch to its on state.
It is the client who is in charge of setting the command and the receiver that the command should be performed upon. In our example scenario the member of the household who gave us our task could be the client. Of course we could have multiple clients.
Putting it all together
The following UML diagram shows our design. The client in the following diagram should be thought of in our example to be a pseudoname for the work done within the
Main entry point method. That is we assign the command and its associated receiver to the
Figure 1: Our design thus far
Before we look at the code let’s just walk through this diagram quickly just to further clarify things. The client (
Client being pseudeoname for the work done in the
Main method in our example) defines a command (
TurnOnHotWaterCommand) and also provides a receiver (
Boiler) for that command. The invoker (
Person) contains a command which is anything that implements
ICommand. The command assigned to the
Person via its
Command property is fulfilled upon the invocation of the
The multiplicities in the UML diagram only apply to our example. As we alluded to in passing earlier the invoker may be composed of many commands. Similarly the client may also assign several commands and associated receivers to the invoker.
Listing 1: ICommand.cs
Listing 2: Boiler.cs
Listing 3: TurnHotWaterOnCommand.cs
Listing 4: Person.cs
Listing 5: Program.cs
If you run the project then you will see the following (predicted) output:
Figure 2: Output of the example
Why would I use this?
Notice that the commands associated to the invoker are encapsulated; all the
Person cares about is that the command associated to it implements the interface
ICommand and thereby exposes an
Execute method. Of course in this article we have covered a very simple example to accustom the reader with the design pattern, but what about having a queue of commands? If the invoker contained a queue (doesn’t have to be a queue) of commands to execute this would be pretty handy, after all, the invoker doesn’t know what its executing just that the commands implement
A common example raised when discussing the command pattern is the one of rehydrating queues of work items. As an example consider a queue that contains various commands to perform. There may arise a time when we want to temporarily cease to perform the remaining commands in the queue and persist them to a data store or to disk. When the appropriate time comes we can rehydrate the stored commands and continue performing them. This idea can be applied to many varying scenarios and is a nice application of the command pattern.
The command pattern and delegates
In .NET we can use delegates to achieve the behavior exhibited in the command pattern. Using delegates has certain advantages:
- They get rid of boilerplate code
- You can use succinct language features like lambda expressions to form commands
- You can invoke delegates asynchronously out of the box
- By using delegates you define the signature of the command. The following delegate for example will allow us to specify rudimentary commands.
Using the above command prototype we can do things like assign arbitrary commands to a
Listing 6: Person.cs
Listing 7: Program.cs
You don’t have to go far to find a good example of such an approach, e.g. the
QueueUserWorkItem method allows you to assign multiple units of work that will be carried out on threads available in the thread pool.
In this article we have looked at the command pattern, a pattern concerned with the encapsulation of invocation. We have discussed the roles of the command, receiver, invoker, and client. Moreover, we have also looked at the relationship between each of the respective roles in the command pattern culminating in the implementation of a simple example scenario. Finally we deviated and looked at how delegates in .NET can be used to achieve a similar result that doesn’t rely on interfaces.
I would like to thank Jon Skeet  for reviewing this article and providing some more insight on the command pattern in relation to .NET.
Sorry, no bio is available
This author has published 32 articles on DotNetSlackers. View other articles or the complete profile here.
Other articles in this category
Introduction to StructureMap
Have you heard of StructureMap, generally know what it’s for, and want to know how to get started qu...
DI Patterns: Constructor Injection
In this article, an excerpt from the book "Dependency Injection in .NET", we will take a detailed lo...
The Command Pattern
In this article I will provide a quick refresher on what the command pattern is used for, how it wor...
Brian Mains discusses how to implement the Arrange-Act-Assert pattern in TypeMock.
Key Process Patterns
This article, based on chapter 2 of Specification by Example, presents effective patterns for softwa...
You might also be interested in the following related blog posts
Learn design patterns from real projects: JBoss case study (Part 1).
Designing a Windows 8 Metro style app starting from an existing Windows Phone app Design Case Study Part 1
Introducing SharePoint 2010 Training at U2U
The Underground at PDC
12 ASP.NET MVC Best Practices
Screencast Whats new in the Entity Data Model Designer in VS2010
What needed to be monitored to get better Governance
SharePoint 2010 Workflow
Formatting Text in RadControls for WinForms Q3 2009
Please login to rate or to leave a comment.