Connect With Us

Command Design Pattern in Ruby

By Nelson Suwal on Nov, 30, 2016 in command-design-pattern, design-pattern, ruby, programming

What is Command Design Pattern ?

Command design pattern is a behavioural pattern in which obtect are use to encapsulate all the information that need to perform action or trigger an event at later time. This information includes the method name, the object that owns the method and values for the method parameters.


  • Encapsulate a request in an object
  • Allows the parameterization of clients with different requests
  • Allows saving the requests in a queue

There are four terms associate with the command pattern. They are:

  1. Command
    This element contains information about the necessary action to be taken. It calls the required method from receiver.
  2. Receiver
    This element contains the actual implementation (knows how to carry out requested command) of any commands. This also maintains the history of executed commands.
  3. Invoker
    This element initiates the whole process. It takes arguments from the client and invokes the process to call the required command.
  4. Client
    This element really behaves like a client (deciding what to do). Its job is to determine which command to execute, without knowing who will execute it and how it will be executed.

# Invoker
class Switch
  attr_reader :history

  def execute(cmd)
      @history ||= []
    @history << cmd.execute

# Command Interface
class Command
  attr_reader :light

  def initialize(light)
    @light = light
  def execute
    raise NotImplementedError

# Command for turning on
class TurnOnCommand < Command
  def execute

# Command for turning off
class TurnOffCommand < Command
  def execute

# Receiver
class Light
  def turn_on
    'the light is on'

  def turn_off
    'the light is off'

# Client
class LightSwitchClient
  attr_reader :switch

  def initialize
    @lamp =
    @switch =

  def switch_for(cmd)
    case cmd
    when 'on'  then @switch.execute(
    when 'off' then @switch.execute(
    else puts 'Sorry, I so sorry'

client =
puts client.switch_for('on')   
puts client.switch_for('off')    
puts client.switch.history

'the light is on'
'the light is off'
['the light is on',the light is off']

In above Example:

Switch class executing the commands and keeping the log of the commands. Command interface accepting the parameter is light in this case. We have two concrete command classes ( TurnOnCommand and TurnOffCommand ). These command classes invokes the methods of the receiver. Receiver does the actual works.Receiver's job is to turn on the light or turn off the light. Client makes the decision which command should created and when to execute the commands.

Specific problems and implementation

Now that we have understood how the pattern works, it's time to take a look at its advantages and flaws, too.

The intelligence of a command

There are two extremes that a programmer must avoid when using this pattern:

  1. The command is just a link between the receiver and the actions that carry out the request
  2. The command implements everything itself, without sending anything to the receiver.

We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.

Undo and redo actions

As mentioned above, some implementations of the Command design pattern include parts for supporting undo and redo of actions. In order to do that a mechanism to obtain past states of the Receiver object is needed; in order to achieve this there are two options:

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 asynchronously in background of an application. The invoker runs in the main thread and sends the requests to the receiver which runs 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.

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.

Hot spot

The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it. And this advantage must be kept. There are implementations of this design pattern in which the invoker is aware of the concrete commands classes. This is wrong making the implementation more tightly coupled. The invoker should be aware only about the abstract command class.

Progress bars

Suppose a program has a sequence of commands that it executes in order. If each command object has a get_estimated_duration() method, the program can easily estimate the total duration. It can show a progress bar that meaningfully reflects how close the program is to completing all the tasks.

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 to_script() method, and user actions can then be easily recorded as scripts.



Share This:


Add a new comment

Latest Posts

Design Sprint By Neha Suwal on Aug, 14, 2017

3 years of helping startups and entrepreneurs with technology By Neha Suwal on Aug, 04, 2017

Digital Marketing for Startups By Neha Suwal on Jun, 30, 2017

Jyaasa in Prestige Talks By Neha Suwal on Jun, 16, 2017

Helping digital era entrepreneurs: How Jyaasa helped create a tech startup success story in Sydney. By Kapil Raj Nakhwa on May, 29, 2017