{"id":6,"date":"2009-09-30T06:01:29","date_gmt":"2009-09-30T05:01:29","guid":{"rendered":"http:\/\/www.michaelokarimia.com\/blog\/?p=6"},"modified":"2012-06-04T13:23:32","modified_gmt":"2012-06-04T12:23:32","slug":"tutorial-part-one","status":"publish","type":"post","link":"https:\/\/www.michaelokarimia.com\/blog\/2009\/09\/30\/tutorial-part-one\/","title":{"rendered":"Command Pattern Tutorial: Part One"},"content":{"rendered":"

When designing software, effective use of design patterns can simplify your design, save you time and produce results more quickly.<\/p>\n

In the following posts I will be demonstrating the implementation of one the Gang of Four’s frequently used patterns, The Command Pattern.<\/p>\n

The final result will be a web application which the user will be able to experiment with, written in C# .NET 3.5<\/p>\n

To start,\u00c2\u00a0 let’s look at the Wikipedia’s definition<\/a> of the Command Pattern:<\/p>\n

an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.<\/p>\n

Three terms always associated with the command pattern are client<\/em>, invoker<\/em> and receiver<\/em>. The client<\/em> instantiates the command object and provides the information required to call the method at a later time. The invoker<\/em> decides when the method should be called. The receiver<\/em> is an instance of the class that contains the method’s code.<\/p><\/blockquote>\n

As I’ve based this project on an\u00c2\u00a0 example in the excellent book Head First Design Patterns<\/a>\"\", I’ve included its definition of this pattern below:<\/p>\n

Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests and support undo-able operations.<\/p><\/blockquote>\n

In UML this pattern is defined as:<\/p>\n

\n

\"Command

Command Design Pattern Class Diagram<\/p><\/div>\n

\n

Now we have a definition of the pattern, I will explain the project brief.<\/p>\n

The idea is to code an API for a Home Automation system, operated by a hand-held remote control. The Remote Control will be able to control any household appliance through a simple interface; seven pairs of on\/off buttons, plus an undo button. Each pair of on\/off buttons will allow one particular command to be activated and deactivated. As the pair of on\/off buttons have to correspond with the same command, I will from now on refer to them as a “command slot”. The Remote Control has seven command slots. The appliances will be likely to change in the future with new features added to them.\u00c2\u00a0 Additionally,\u00c2\u00a0 new appliances may be added to the house. The changes in the appliances should not cause us to change code in the remote control.<\/p>\n

The user will be able to add and remove the command in each command slot during run time.<\/p>\n

The undo button will undo the last action performed.<\/p>\n

The Remote Control Object is the Invoker<\/em> in this pattern. When a button on the Remote Control is pushed a command object execute()<\/em> method is invoked.<\/p>\n

The appliances are instances of the Receiver<\/em> in this pattern. Calls to a receivers methods are made by instances of the command objects.<\/p>\n

The House class <\/em>is the Client<\/em> in this pattern, which instantiates and holds references to both the Remote Control and the Appliance objects. There is only one Remote Control per house.<\/p>\n

At this stage of the project the receiver <\/em>classes all must have parameterless constructors, as well as an on and off method along with a publicly accessible boolean property\u00c2\u00a0 representing the state of the object (either on or off).<\/p>\n

\n

By using this design pattern, the Remote Control is decoupled from the Command Objects and the Appliances.\u00c2\u00a0 The first four classes are CeilingFan, GarageDoor, Ligh<\/em>t, and Stereo.<\/em><\/p>\n

\n

\n

The Light Class is one of our Appliances and is a Receiver<\/em> in this pattern. Source code for this class and the other receiver classes can be found in my Subversion repository<\/a><\/p>\n

\n

\"Light

Light Class<\/p><\/div>\n

Boolean _isOn holds the state of the Light, which is accessed through the read only Property isLightOn<\/p>\n

\n

The on() <\/em>and off()<\/em> methods when called, do what their names suggest and update the boolean field _isOn accordingly.<\/p>\n

\n

\n

\n

\n

\n

\n

\n

ICommand Object Interface (source code here<\/a>)<\/p>\n

\n

\"Command

Command Object Interface<\/p><\/div>\n

All Command Objects implement this interface, and are responsible for executing methods in the receiver <\/em>classes.<\/p>\n

execute() <\/em>invokes a method or methods in the receiver<\/em> class.<\/p>\n

undo()<\/em> invokes a method or methods in the receiver<\/em> class that does the logical opposite of whatever the execute method does.<\/p>\n

The LightOnCommand Class is concrete Command object. See Source Code for all Command Objects<\/a><\/p>\n

\n

\"Light

Light On Command<\/p><\/div>\n

It’s constructor must be passed a Light object as a parameter, which is stored in the _light field.<\/p>\n

When the execute()<\/em> method is invoked, it calls the on() <\/em>method of the _light object, and the undo()<\/em> method when invoked calls the off() <\/em>method on the _light object.<\/p>\n

\n

public class LightOnCommand : ICommand\r\n{\r\nprivate Light _light;\r\n\r\n public LightOnCommand(Light light)\r\n{\r\n_light = light;\r\n}\r\npublic void execute()\r\n{\r\n_light.on();\r\n}\r\npublic void undo()\r\n{\r\n_light.off();\r\n}\r\n}<\/pre>\n
Because the Receiver<\/em> object being called has only a binary state which is toggled with the on() <\/em>and off() <\/em>methods, this command is very straightforward.\u00c2\u00a0 In a latter we will introduce a more advanced use of state in Receiver <\/em>classes.<\/p>\n
\n
The LightOffCommand Class is another implementation of the ICommand interface<\/p>\n
\"LightOffCommand\"
LightOffCommand<\/p><\/div>\n
\n
As you have probably guessed, this class is the corresponding \"Off\" command for the previous Command Class.<\/p>\n
This time, execute(<\/em>) turns _light object off, and undo()<\/em> turns the _light object on.<\/p>\n
\n
\n
\n
\n
\n
Another Concrete Command Class used in the application is NoCommand, which acts as a Null Object. Its execute()<\/em> and undo()<\/em> methods don't do anything. Null Objects are useful because we want to keep the Remote Control class simple and loosely coupled to the Command Objects; by using  NoCommand as a Null Object, the Remote Control class does not have to handle a null value. For instance, when a Command Slot has not been set to a specific Command Object, a NoCommand object can sit in the slot. This saves the Remote Control needing to check if each Command Object is null before it attempts to calls its execute()<\/em> method.<\/p>\n
\n
RemoteControl class: Responsible for invoking commands objects (source code<\/a>)<\/p>\n
\"RemoteControl<\/p>\n
\n
Fields: _undoCommand holds an ICommand object. _offCommands and _OnCommands can hold an array of ICommandObjects<\/p>\n
The Remote Control is created with each command array populated with NoCommand objects, the House object uses the setCommand()<\/em> method to add them.<\/p>\n
Available_Slots and CommandCount properties are used by the House class to determine how many slots are unassigned in order to assign new commands.<\/p>\n
When the onButtonWasPushed(int) <\/em>and offButtonWasPushed(int)<\/em> methods are called, they look up the command object stored in the respective _onCommands or _offCommands\u00c2\u00a0 arrays\u00c2\u00a0 at the index passed in as the parameter. The execute()<\/em> method of the command object is called. The Remote Control does not need to know what the command does or how it works; it just needs there to be an execute method to call. It is decoupled from the Command Object.<\/p>\n
Additionally when either onButtonWasPushed(int) <\/em>or offButtonWasPushed(int)<\/em> methods are invoked the\u00c2\u00a0 _undoCommand field is set to whatever command object was executed. This field will always hold a reference to the last command object executed. When the undoButtonWasPushed()<\/em> method is called it in turn calls the undo()<\/em> method of that command object. This is how the global undo feature is implemented<\/p>\n
\n
The Command Pair struct represents a Command Slot, a pair of commands objects which turn on or off a single appliance.<\/p>\n
Defined as:<\/p>\n
\r\npublic struct command_pair\r\n{\r\npublic string Name;\r\npublic ICommand onCmd;\r\npublic ICommand offCmd;\r\n}\r\n<\/pre>\n
The House Class: Responsible for Appliances, Command Objects, and the Remote Control (Source Code<\/a>)<\/p>\n
\"House
House Class<\/p><\/div>\n
Fields:<\/p>\n