Wednesday, October 31, 2012

Command Design Pattern

Although they are lots of books and articles about Design Patterns, yet I like to share my point of view about common design patterns with you, and would be happy to have your thoughts or questions on comments. This post introduces GoF Command design pattern.

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. (doFactory) 

  • Command declares an interface for executing an operation
  • ConcretedCommand defines a binding between a Receiver object and an action and also implements Execute by invoking the corresponding operation(s) on Receiver
  • Client creates a ConcreteCommand object and sets its receiver
  • Invoker asks the command to carry out the request
  • Receiver knows how to perform the operations associated with carrying out the request.

  • GUI buttons and menu items: a Command may have an associated icon, keyboard shortcut, tooltip text, and so on. A toolbar button or menu item component may be completely initialized using only the Command object. 
  • Macro recording: If all user actions are represented by command objects, a program can record a sequence of actions simply by keeping a list of the command objects as they are executed. It can then "play back" the same actions by executing the same command objects again in sequence. If the program embeds a scripting engine, each command object can implement a toScript() method, and user actions can then be easily recorded as scripts.
  • Multi-level undo: If all user actions in a program are implemented as command objects, the program can keep a stack of the most recently executed commands. When the user wants to undo a command, the program simply pops the most recent command object and executes its undo() method.
  • Networking: It is possible to send whole command objects across the network to be executed on the other machines, for example player actions in computer games.
  • Parallel Processing: Where the commands are written as tasks to a shared resource and executed by many threads in parallel (possibly on remote machines -this variant is often referred to as the Master/Worker pattern)
  • Thread pools: A typical, general-purpose thread pool class might have a public addTask() method that adds a work item to an internal queue of tasks waiting to be done. It maintains a pool of threads that execute commands from the queue. The items in the queue are command objects. Typically these objects implement a common interface that allows the thread pool to execute the command even though the thread pool class itself was written without any knowledge of the specific tasks for which it would be used.
  • Transactional behavior: Similar to undo, a database engine or software installer may keep a list of operations that have been or will be performed. Should one of them fail, all others can be reverted or discarded (usually called rollback). For example, 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.
  • Wizards: Often a wizard presents several pages of configuration for a single action that happens only when the user clicks the "Finish" button on the last page. In these cases, a natural way to separate user interface code from application code is to implement the wizard using a command object. The command object is created when the wizard is first displayed. Each wizard page stores its GUI changes in the command object, so the object is populated as the user progresses. "Finish" simply triggers a call to execute(). This way, the command class contains no user interface code.

  • Command decouples the object that invokes the operation from the one that knows how to perform it. Due to this usage it is also known as Producer - Consumer design pattern.
  • Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Command pattern issues requests to objects without knowing anything about the operation being requested or the receiver of the request.
  • Promote “invocation of a method on an object” to full object status
  • An object-oriented callback
  • Sequences of Command objects can be assembled into composite (or macro) commands.
  • Command objects can be thought of as “tokens” that are created by one client that knows what need to be done, and passed to another client that has the resources for doing it.
  • Two important aspects of the Command pattern are interface separation (the invoker is isolated from the receiver) and time separation (stores a ready-to-go processing request that’s to be stated later).
  • Command pattern allows saving the requests in a queue
  • Offers support for undoable actions (the Execute method can memorize the state and allow going back to that state)
  • One 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.
  • Command Pattern tends to lead to a proliferation of small classes; however, it does lead to simpler clients for supporting modern user interfaces. So,  It is important to have a good naming convention and to do your best to factor common classes.

Sample Code
Classic Command Pattern Sample

Command Pattern using delegate  Sample

Command Dispatcher Sample
Note: Command Dispatcher is a Pipeline pattern that can use Command pattern as well.

Related Patterns
  • 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.


Futher readings

No comments :

Post a Comment