CSC/ECE 517 Fall 2012/ch1b 1w52 an
Command Pattern
Command Pattern is a design pattern in object-oriented programming in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information comprises of, the method name, the object that is the owner of the method and values for the method parameters. It encapsulates a request as an object and gives it a known public interface. It ensures that every object receives its own commands and provides a decoupling between sender and receiver. In this case a sender is an object that invokes an operation, and a receiver is an object that receives the request and acts on it.
There are three main components of a Command pattern: the Invoker, the Command, and the Receiver. The invoker component acts as a link between the commands and the receiver, and houses the receiver and the individual commands as they are sent. The command is an object that encapsulates a request to the receiver. The receiver is the component that is acted upon by each request.
The intent of using command objects is to easily construct the general components that need to sequence, delegate or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
Developers might use a switch statement with a case for each command. Usage of Switch statements during coding is a sign of bad design during the design phase of an object-oriented project. Commands represent an object-oriented way to support transactions<ref>Oodesign. (2005-2006)- command-pattern - http://www.oodesign.com/command-pattern.html</ref> and can be used to solve this design problem.
Why and When do we use a Command Pattern?
Command Pattern comes into picture when there is a need to store objects behaviour as a command and its state. The Command pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command pattern provides the options to queue commands, undo/redo actions and other manipulations.
There are several benefits<ref>Javaworld - Command Design Pattern - http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-designpatterns.html</ref> of using the Command pattern:
- It provides encapsulation of application logic so that it can be executed at a different point of time.
- It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.
- The separation between application logic and context allows to easier exchange the application logic.
Command Patterns can be used for the following:
Undo and redo actions
There is support for undo and redo of actions in certain implementations of the Command design pattern. In order to do that, a mechanism to obtain past states of the Receiver object is needed; there are two options to achieve this:
- Before running each command a snapshot of the receiver state is stored in memory. This does not require much programming effort but can not be always applied. For example doing this in an image processing application would require storing images in memory after each step, which is practically impossible.
- Instead of storing receiver objects states, the set of performed operations are stored in memory. In this case the command and receiver classes should implement the inverse algorithms to undo each action. This will require additional programming effort, but less memory will be required. Sometimes for undo/redo actions the command should store more information about the state of the receiver objects. A good idea in such cases is to use the Memento Pattern.
Asynchronous Method Invocation
Another usage for the command design pattern is to run commands asynchronous in background of an application. In this case the invoker is running in the main thread and sends the requests to the receiver which is running in a separate thread. The invoker will keep a queue of commands to be run and will send them to the receiver while it finishes running them.
Instead of using one thread in which the receiver is running more threads can be created for this. But for performance issues (thread creation is consuming) the number of threads should be limited. In this case the invoker will use a pool of receiver threads to run command asynchronously.
Adding new commands
The command object decouples the object that invokes the action from the object that performs the action. There are implementations of the pattern in which the invoker instantiates the concrete command objects. In this case if we need to add a new command type we need to change the invoker as well. And this would violate the Open Close Principle (OCP). In order to have the ability to add new commands with minimum of effort we have to make sure that the invoker is aware only about the abstract command class or interface.
Using composite commands
When adding new commands to the application we can use the composite pattern to group existing commands in another new command. This way, macros can be created from existing commands.
Applications
There are many applications<ref>Wikipedia. (2010, October) Wikipedia - Command_Pattern - http://en.wikipedia.org/wiki/Command_pattern</ref> that make use of command pattern.Command objects are useful for implementing:
- In Networking
- In case of computer games,player actions can to send whole command objects across the network to be executed on the other machines.
- In parallel processing
- In parallel processing, tasks may be referred as the commands to a shared resource. These tasks will be executed by many threads in parallel.This can be considered as a Client/Server model.
- Graphical User Interface buttons
- An Action is a command object in case of Swings. A submit button, menu button or checkbox button component may be completely initialized using only the
Actionobject. In a given scenario,an Action may have an icon bound to it ,mouse click,a keyboard shortcut in addition to the ability to perform the desired command. - Multi-level undo
- The program can keep a stack of the most recently executed commands if all user actions in a program are implemented as command objects. The program simply pops the most recent command object and executes its undo() method when the user wants to undo a command.
- Transactional behavior of Databases
- A database engine or software installer may keep a list of operations that have been or will be performed similar to undo.All others can be reverted or discarded if one of them fail. For instance, if two database tables that refer to each other must be updated, and the second update fails, the transaction can be rolled back, so that the first table does not now contain an invalid reference.
Components of a command pattern
The various components<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> of a command pattern are given as follows:
Client: Invokes a particular module using a command and passes a request which gets propagated as a command.
Command: It is an object that encapsulates a request to the receiver. Command request maps to particular modules. According to the command, a module is invoked.
Receiver: It is the component that is acted upon by each request. It knows how to perform the operations associated with carrying out a certain request.
Invoker: It is the class that is invoked by the client. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
Concrete Command: It defines a link between the receiver and the action. It basically implements the execute method and invokes the corresponding operations on the receiver.
Throughout this page, we will discuss the example of an operation of converting a string into either upper case or lower case.
The components corresponding to the example are given in the figure above. From the figure we can identify the components as follows:
Client: Menu Class is used to set the ConcreteCommand and then sets the convert class
Command: Command Class in this case is declaring the interface which is used to execute the operation.
Receiver: Convert Class is the one which knows how to perform the operations.
Invoker: TextOperation Class asks the command to carry out the action which in this case is to either convert toUpper or toLower.
ConcreteCommand: ConvertUpper, ConvertLower classes are the ones that implement the execute command.
Terminology
The terminology used to describe command pattern implementations can be confusing sometimes.
- Command Object, Routed Command Object and Action Object: In this, we can refer a singleton object which knows about mouse click , button images, shortcut keys and so on related to the command. A invoker object calls the Action object's performAction method.When the availability of a command/action has changed, the Command/Action object notifies the appropriate source/invoker objects.When a command/action cannot be executed/performed, this allows buttons and menu items to become inactive.
- Client, Source and Invoker: It refers to a button, toolbar button, or radio button clicked, or the shortcut key pressed by the user.
- Receiver, Target Object: This is the object that is about will be copied, pasted or perform some other function . The receiver object owns the method that is called by the command's execute method. The receiver is also the target object. For instance, if the receiver object is a cursor and the method is called moveDown, then one would expect that the cursor is the target of the moveDown action.
- Handler, method, : This is the actual code that does the copying, pasting etc.There are many variants of the handler. This is the handler code of the action object in some implementations. In other implementations the code is part of the Receiver/Target Object.Finally in some other implementations the handler code is kept separate from the other objects.
Check list for Command Pattern Implementation
- Define a Command interface with a method signature like
execute(). - Create one or more derived classes that encapsulate some subset of the following: a “receiver” object, the method to invoke, the arguments to pass.
- Instantiate a Command object for each deferred execution request.
- Pass the Command object from the creator (aka sender) to the invoker (aka receiver).
- The invoker decides when to
execute().
Rules of thumb<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref>
- Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. *Command normally specifies a sender-receiver connection with a subclass.
- Chain of Responsibility can use Command to represent requests as objects.
- Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in *Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
- Command can use Memento to maintain the state required for an undo operation.
- MacroCommands can be implemented with Composite.
- A Command that must be copied before being placed on a history list acts as a Prototype.
- Two important aspects of the Command pattern: interface separation (the invoker is isolated from the receiver), time separation (stores a ready-to-go processing request that’s to be stated later).
Example of Command pattern
Consider the case of converting a string to upper and lower case.The Client is the Menu where we see the options. The menu sends the request to the receiver(convert class) through the Invoker(TextOperations class). The textOperation encapsulates the command and then forwards it, creating the ConcreteCommand object which is the command itself. The Receiver will be the Convert class that, after completing all the commands that were sent to it before the command in question(to Upper case or to lower case ), starts to work on it.
Implementation in static and dynamic languages
Implementation in Static languages
We initially define a Command interface with a method named execute() and then we create command classes that implement this interface. The execute() method of each object will contain the logic specific to the action you are encapsulating. (For instance, you might create a convertUpper and a converLower command in a text editor application.)
In case of the static implementation, code snippets to implement the command pattern in languages like Java and C# are given as follows:
Java Example
//This is the command interface.
public interface Command{
void execute();
}
//The invoker class
public class TextOperations{
private ArrayList<Command> Command_List= new ArrayList<Command>;
private TextOperations(){
}
public void commandExecute(Command cmd){
this.Command_List.add(cmd); // optional
cmd.execute();
}
}
// The Receiver class
public class Convert{
public Convert(){
}
public final void toUpper(){
System.out.print("Turning all lower case elements to upper case");//The actual action that is being performed.
}
public final void toLower(){
System.out.print("Converting all upper case elements to lower case");//The actual action that is being performed.
}
}
//A command to convert to lower case.
public class convertLower implements Command{
private Convert convert;
private convertLower(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper implements Command{
private Convert convert;
private convertUpper(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toUpper();
}
}
//This is the client class
public class Menu{
public static void main(String[] args){
Convert c = new Convert();
Command conToUpper = new convertUpper(c);
Command conToLower = new convertLower(c);
TextOperations converter = new TextOperations();
if (args[0].equalsIgnoreCase("ToUpper")) {
converter.commandExecute(conToUpper);
System.exit(0);
}
if (args[0].equalsIgnoreCase("ToLower")) {
converter.commandExecute(conToLower);
System.exit(0);
}
}
}
C# Example
//This is the command interface.
public interface Command
{
void execute(); //The execute method that is going to call the action
}
//A command to convert to lower case.
public class convertLower : Command
{
private Convert convert;
private convertLower(Convert conv)
{
this.convert = conv;
}
public void execute()
{
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper : Command
{
private Convert convert;
private convertUpper(Convert conv)
{
this.convert = conv;
}
public void execute()
{
convert.toUpper();
}
}
//This is the reciever class.
public class Convert
{
public Convert()
{
}
public final void toUpper()
{
Console.WriteLine("Turning all lower case elements to upper case");// These are the actual actions that are performed
}
public final void toLower()
{
Console.WriteLine("Converting all upper case elements to lower case"); //These is the actual action that is performed
}
}
// The invoker class
public class TextOperations
{
private Command convertUp;
private Command convertLow;
private TextOperations(Command toup, Command todwn)
{
this.convertUp = toup;
this.convertLow = todwn;
}
public virtual void convToUp()
{
convertUp.execute();
}
public virtual void convToLow()
{
convertLow.execute();
}
}
// This is the client class.
public class Menu
{
Static void Main(string[] args)
{
Convert c = new Convert();
Command cou = new convertUpper(c);
Command col = new convertLower(c);
TextOperations converter = new TextOperations(cou,col); /*Client calls the invoker and gives the commands to execute*/
converter.convToLow();
converter.convToUp();
}
}
Implementation in Dynamic Languages
In dynamic languages we will have a controller class that constructs each of the Command objects.Each of these command objects is passed to an invoker class. The invoker class calls the execute() method of a Command object at the appropriate time. (For instance this may happen when a user selects a menu item or presses a button)
In case of the dynamic languages, the code snippets to implement command pattern for ruby and python are given as follows.
Ruby Example
#This is the command interface.
class Command
def execute()
end
end
#A command to convert to lower case.
class convertLower < Command
def initialize(conv)
self.@convert = conv
end
def execute()
@convert.toLower()
end
end
#A command to convert to upper case
class convertUpper < Command
def initialize(conv)
self.@convert = conv
end
def execute()
@convert.toUpper()
end
end
#This is the reciever class.
class Convert
def initialize()
end
def toUpper()
Console.WriteLine("Turning all lower case elements to upper case")
end
def toLower()
Console.WriteLine("Converting all upper case elements to lower case")
end
end
# The invoker class
class TextOperations
def initialize(toup, todwn)
self.@convertUp = toup
self.@convertLow = todwn
end
def convToUp()
@convertUp.execute()
end
def convToLow()
@convertLow.execute()
end
end
# This is the client class.
class Menu
def Main(args)
c = Convert.new()
cou = convertUpper.new(c)
col = convertLower.new(c)
converter = TextOperations.new(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
end
end
Python Example
#This is the command interface.
class Command(object):
def execute(self):
pass
#A command to convert to lower case.
class convertLower(Command):
def __init__(self, conv):
self._convert = conv
def execute(self):
self._convert.toLower()
#A command to convert to upper case
class convertUpper(Command):
def __init__(self, conv):
self._convert = conv
def execute(self):
self._convert.toUpper()
#This is the reciever class.
class Convert(object):
def __init__(self):
pass
def toUpper(self):
Console.WriteLine("Turning all lower case elements to upper case")
def toLower(self):
Console.WriteLine("Converting all upper case elements to lower case")
# The invoker class
class TextOperations(object):
def __init__(self, toup, todwn):
self._convertUp = toup
self._convertLow = todwn
def convToUp(self):
self._convertUp.execute()
def convToLow(self):
self._convertLow.execute()
# This is the client class.
class Menu(object):
def Main(self, args):
c = Convert()
cou = convertUpper(c)
col = convertLower(c)
converter = TextOperations(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
Static vs Dynamic implementations
In case of the implementations ruby has better implementation of the command patterns than the languages like Java. Some of the advantages of Ruby over Java can be given as follows.
- To implement the command pattern in static languages like Java, we have to define a common interface which has to be extended by all the other classes. In case of ruby we can use procs which makes it easier to implement.
- Ruby implements something called mixins in order to implement the command pattern which is efficient compared to Java.
- The lines of code for static language like Java is more than that taken by the dynamic language like Ruby. This is more because of the proc objects that are present in ruby which are concisely defined than that present in Java.
- Since Ruby is a dynamic language, one can add the commands to the command array during runtime. Java is a static language and hence does not support this feature.
Conclusion
Hence it can be summarized that the dynamically typed languages keep the code straight and narrow as it does not need to depend on static type-checking. Also due to the flexibility of the dynamic languages, writing code is significantly easier.
See Also
- Design Pattern
- Software Design Pattern
- Chain of Responsibility Pattern
- Mediator Pattern
- Observer Pattern
- Composite Pattern
- Memento Pattern
References
<references/>
Additional Reading
- Design Pattern: Command Pattern at codeproject.com
- Command Pattern in Java at java.dzone.com
- Basics of Command Pattern
- Command Pattern in C# at dofactory.com
- Behavorial Design Pattern - Command Pattern at sourcemaking.com
- McDonald,J. 2008. Design Patterns