Published: 10 Feb 2010
By: Andrew Siemer
Download Sample Code

In this article I will provide a quick refresher on what the command pattern is used for, how it works, and where it fits in the web development world.

Contents [hide]

Introduction

I have been spending some time refreshing my mind on distributed system design. I have had a specific interest in working with MSMQ for an upcoming project which eventually led me back to "The Command Pattern". In day to day line of business web development I don't run across the need for this pattern too often. I figured you probably didn't either! In this article I will provide a quick refresher on what the command pattern is used for, how it works, and where it fits in the web development world.

Why the command pattern?

Put simply, the command pattern encapsulates a request as an object and gives it a known public interface. This allows the packaged object to receive its commands from any processor and effectively decouples the sender (or invoker) and the receiver who ultimately processes the command.

This pattern is often used in distributed computing where high availability is required. In the case where you have a client that is performing a specific bit of functionality on one of many web servers and that functionality doesn't need to happen either in real time (while the client waits) and doesn't need to happen on the server where the request originated – offloading the processing of a set of commands to a lesser taxed system is a great way to split and share your load.

Example application: Home automation

I don't consider myself to be a home automation enthusiast but the scenario translates well to the problem space. You have one remote that controls all sorts of aspects of your home. The remote can turn your lights on and off. It can turn your ceiling fan on and off as well as dim the lights. It might be able to interface with your alarm system to configure it, arm it, disarm it, or activate an alarm. You could turn on your yard lights. And you could open your garage. How does one device interoperate with so many non-related systems?

Creating a ceiling fan and remote

Before we go to deep into commands let's first create a couple of quick objects to work with that we can issue commands to and from. We will create a representation of a ceiling fan. The ceiling fan should know if its power is on or off, whether its fan is spinning or not, and how much light it is emitting. We will also need a remote that has buttons that we can manipulate to send appropriate commands with.

Listing 1: Fan.cs

We will define the shell of the remote as the remote is responsible for executing the commands in the purist form of this pattern. The pattern doesn't specify that the invoker of the commands is also the creator. The commands could be created by a service elsewhere, shuttled over the wire or through a queue, and then ultimately invoked by our remote. In this example we will show the creation and invocation in one class.

Listing 2: Remote.cs

Unified contract for remote to device communication

Now that we have some objects to play with we can look at the guts of the Command pattern. The first step to getting the command pattern off the ground is the creation of an interface that defines how the invoker of the commands can interpret the commands sent to them by the creator of the commands. There is really nothing special about this interface. It has one method that must be implemented which requires a Fan object to perform its operations on.

Defining commands

Creating a command object is very straight forward. All it has to do is implement our ICommand interface by exposing a public Execute method. In our case, let us take a look at how to manipulate a ceiling fan. We will create commands to turn the power on and off. And we will create commands to manipulate the light level that the ceiling fan emits and commands to manipulate the fan's speed. All of these commands will in turn call methods on the fan object that is passed into the command.

Listing 3: ToggleFanPowerCommand.cs

Listing 4: DecreaseFanLightCommand.cs

Listing 5: IncreaseFanLightCommand.cs

Listing 6: DecreaseFanSpeed.cs

Listing 7: IncreaseFanSpeed.cs

Adding implementation to our Remote

Now that we have all the commands defined, we have our skeleton remote, and we have a working fan, we can tie it all together by implementing the command execution in the remote.

Listing 8: Fan.cs

The output so far

Now that we have everything wired we can execute some commands. Here is the program and its output.

Listing 9: Program.cs

As you can see the remote is executing commands and the fan is reacting accordingly. When the power is on, the fan light can be increased to the specified amount. The light can be increased appropriately. When the maximum levels are reached they don't go beyond their limits. And when the power is off nothing can be done to the fan.

How is this any different from calling a method directly?

Ok. Now it's magic time. You might be wondering how executing commands like this is any different from just calling a method on the fan directly from the remote. Consider another home automation scenario. You log into a web site and turn on your fan and adjust the light settings and fan speed from your car on the other side of the country. The way that this would work is that the website would trigger the command objects to be sent to a command processor. To do this the website might insert the command to a database or a queue of some form. Then a command processor would pick up those commands and execute them in the same order that they were submitted. Let's see how that might work.

Creating a command invoker

We already have everything we need to add this additional layer of functionality to our already existing Remote and Fan set up. No changes are required to the Remote or the Fan! We do need to create a CommandInvoker object. Its job will be to read from a queue and execute the commands that it finds there.

Our CommandInvoker will simply be another class that accepts a collection of Commands and iterates over them to execute their command. This is obviously a simple demonstration...but it should be effective enough to prove the flexibility of this pattern.

Listing 10: CommandInvoker.cs

How about a real world scenario for the CommandInvoker?

In the real world we would probably submit our commands through MSMQ or through a database. The commands would sit there until they were picked up and processed by the CommandInvoker. We will create our CommandInvoker as another class that will simply iterate through an array of commands. But in reality the CommandInvoker would probably operate best as a Service running in the background on a server always pinging the queue for new commands!

Now that we have our CommandInvoker created we just need to change our program around a bit to demonstrate the two ways of manipulating our fan. You will now see a method for using the remote. And another method for using the CommandInvoker.

Listing 11: Program.cs

The UseInvoker method simply creates a collection of commands (which could be done on the web server or anywhere else) and then sends that collection to the invoker. A real world implementation of this would probably consist of a website that creates the commands for storage in a central database. Then the home automation system would query this database for new commands or receive the commands through some form of push notification like Jabber/XMPP.

Summary

In this article we took a quick look at the Command Pattern. This is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

<<  Previous Article Continue reading and see our next or previous articles Next Article >>

About Andrew Siemer

I am a 33 year old, ex-Army Ranger, father of 6, geeky software engineer that loves to code, teach, and write. In my spare time (ha!) I like playing with my 6 kids, horses, and various other animals.

This author has published 29 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...
To mock or not to mock, that is the question – Part 1
This article gives a quick introduction in the usage of two of the most known mocking frameworks: Rh...
DI Patterns: Constructor Injection
In this article, an excerpt from the book "Dependency Injection in .NET", we will take a detailed lo...
TypeMock’s Arrange-Act-Assert
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


Mobile Design Pattern Gallery: UI Patterns for Mobile Applications read more
Pattern focus: Decorator pattern read more
Oredev Wrap-Up read more
Data-binding Telerik CoverFlow for Silverlight + some Routed Commands goodness read more
Eschewing Date Types in our Database read more
12 ASP.NET MVC Best Practices read more
SharePoint Conference 2009 read more
SOLUTION: JSLint.VS Add-In Always Reports "No Errors" Even For Invalid JavaScript Files read more
The Telerik CAB Enabling Kit and SCSF - Tutorial 5: The RadPanelBar UIExtensionSite read more
Dont Repeat Yourself read more
Top
 
 
 

Please login to rate or to leave a comment.