Command Design Pattern

The Command Design Pattern is a behavioral design pattern that turns a request into a stand-alone object called a command. With the help of this pattern, you can capture each component of a request, including the object that owns the method, the parameters for the method, and the method itself. By doing this, you can easily pass, queue, or log requests and support operations like undo/redo.

What is the Command Design Pattern?

The Command Design Pattern is a behavioral design pattern that turns a request into a stand-alone object called a command. With the help of this pattern, you can capture each component of a request, including the object that owns the method, the parameters for the method, and the method itself.

• The Command Pattern encapsulates a request as an object, allowing for the separation of sender and receiver.
• Commands can be parameterized, meaning you can create different commands with different parameters without changing the invoker.
• It decouples the sender from the receiver, providing flexibility and extensibility.
• The pattern supports undoable operations by storing the state or reverse commands.

Components of the Command Design Pattern

1. Command Interface

The Command Interface is like a rulebook that all command classes follow. It declares a common method, execute(), ensuring that every concrete command knows how to perform its specific action. It sets the standard for all commands, making it easier for the remote control to manage and execute diverse operations.

2. Concrete Command Classes

Concrete Command Classes are the specific commands, like turning on a TV or adjusting the stereo volume. Each class encapsulates the details of a particular action. These classes act as executable instructions that the remote control can trigger without worrying about the small details.

3. Invoker (Remote Control)

The Invoker, often a remote control, is the one responsible for initiating command execution. It holds a reference to a command but doesn't delve into the specifics of how each command works. It's like a button that, when pressed, makes things happen.

4. Receiver (Devices)

The Receiver is the device that knows how to perform the actual operation associated with a command. It could be a TV, stereo, or any other device. Receivers understand the specific tasks mentioned in commands.

• If a command says, "turn on," the Receiver (device) knows precisely how to execute that action.
• The Receiver-Command relationship separates responsibilities, making it easy to add new devices or commands without messing with existing functionality.

How to implement Command Design Pattern?

Below are the simple steps to implement the Command Design Pattern:

1. Create the Command Interface: Define an interface or abstract class that declares the execute() method. This method will be called to carry out the action.
2. Create Concrete Command Classes: Implement the command interface in multiple classes. Each class will represent a different command and will call the appropriate method on the receiver to perform the specific action.
3. Define the Receiver Class: This class contains the actual logic that needs to be executed. The command objects will call methods on this receiver to perform actions.
4. Create the Invoker Class: The invoker triggers the command’s execute() method but doesn’t know the details of the operation. It simply knows that it needs to call the command.
5. Client Uses the Command: The client creates the concrete command objects and associates them with the receiver. It then assigns commands to the invoker, which will call them when needed.

Command Design Pattern example

Problem Statement:

Imagine you are tasked with designing a remote control system for various electronic devices in a smart home. The devices include a TV, a stereo, and potentially other appliances. The goal is to create a flexible remote control that can handle different types of commands for each device, such as turning devices on/off, adjusting settings, or changing channels.

What can be the challenges while implementing this system?

• Devices can have different functionalities, so designing a remote control that can easily handle different device types with varying functionalities without becoming highly complex.
• Implementing a remote control that supports various commands without tightly coupling ensuring the remote control can execute commands for different devices without needing extensive modifications for each new command.
• Designing a system that allows users to customize the behavior of the remote control dynamically.

How Command Pattern help to solve above challenges?

The Command Pattern can be employed to address these challenges. It introduces a level of abstraction between the sender of a command (remote control) and the receiver of the command (electronic devices).

• The Command Pattern decouples the sender (Invoker) from the receiver (Devices).
• The remote control doesn't need to know the specific details of how each device operates; it only triggers commands.
• New devices or commands can be added without modifying existing code.
• The remote control can work with any device that implements the common command interface.

Below is the code of above problem statement using Command Pattern:

1. Command Interface

The Command interface declares a method, often named execute(). This method is meant to encapsulate a specific operation. The interface sets a contract for concrete command classes, defining the execute() method that encapsulates the operation to be performed.

// Command interface
public interface Command {
    void execute();
}

2. Concrete Command Classes

Concrete command classes implement the Command interface. Each class encapsulates a specific operation related to devices. Each concrete command class provides a specific implementation of the execute() method, defining how a particular device operation (turning on, turning off, adjusting volume, changing channel) is executed.

// Concrete command for turning a device on
public class TurnOnCommand implements Command {
    private Device device;

    public TurnOnCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOn();
    }
}

// Concrete command for turning a device off
public class TurnOffCommand implements Command {
    private Device device;

    public TurnOffCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOff();
    }
}

// Concrete command for adjusting the volume of a stereo
public class AdjustVolumeCommand implements Command {
    private Stereo stereo;

    public AdjustVolumeCommand(Stereo stereo) {
        this.stereo = stereo;
    }

    @Override
    public void execute() {
        stereo.adjustVolume();
    }
}

// Concrete command for changing the channel of a TV
public class ChangeChannelCommand implements Command {
    private TV tv;

    public ChangeChannelCommand(TV tv) {
        this.tv = tv;
    }

    @Override
    public void execute() {
        tv.changeChannel();
    }
}

3. Receiver Classes (Devices)

The Device interface declares methods related to device functionality, such as turnOn() and turnOff(). This interface sets a contract for device classes, defining common operations that concrete devices should support.

// Receiver interface
public interface Device {
    void turnOn();
    void turnOff();
}

// Concrete receiver for a TV
public class TV implements Device {
    @Override
    public void turnOn() {
        System.out.println("TV is now on");
    }

    @Override
    public void turnOff() {
        System.out.println("TV is now off");
    }

    public void changeChannel() {
        System.out.println("Channel changed");
    }
}

// Concrete receiver for a stereo
public class Stereo implements Device {
    @Override
    public void turnOn() {
        System.out.println("Stereo is now on");
    }

    @Override
    public void turnOff() {
        System.out.println("Stereo is now off");
    }

    public void adjustVolume() {
        System.out.println("Volume adjusted");
    }
}

4. Invoker Class (Remote Control):

The invoker class holds a reference to a Command object and triggers its execution through the execute() method. The invoker doesn't know the specific details of the command or the devices. It simply calls the execute() method on the current command, allowing for flexible and dynamic control over different devices.

// Invoker
public class RemoteControl {
    private Command command;

    public void setCommand(Command command) {
        this.command = command;
    }

    public void pressButton() {
        command.execute();
    }
}

Complete code for the above example

Below is the complete code for the above example:

// Command interface
interface Command {
    void execute();
}

// Concrete command for turning a device on
class TurnOnCommand implements Command {
    private Device device;

    public TurnOnCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOn();
    }
}

// Concrete command for turning a device off
class TurnOffCommand implements Command {
    private Device device;

    public TurnOffCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOff();
    }
}

// Concrete command for adjusting the volume of a stereo
class AdjustVolumeCommand implements Command {
    private Stereo stereo;

    public AdjustVolumeCommand(Stereo stereo) {
        this.stereo = stereo;
    }

    @Override
    public void execute() {
        stereo.adjustVolume();
    }
}

// Concrete command for changing the channel of a TV
class ChangeChannelCommand implements Command {
    private TV tv;

    public ChangeChannelCommand(TV tv) {
        this.tv = tv;
    }

    @Override
    public void execute() {
        tv.changeChannel();
    }
}

// Receiver interface
interface Device {
    void turnOn();
    void turnOff();
}

// Concrete receiver for a TV
class TV implements Device {
    @Override
    public void turnOn() {
        System.out.println("TV is now on");
    }

    @Override
    public void turnOff() {
        System.out.println("TV is now off");
    }

    public void changeChannel() {
        System.out.println("Channel changed");
    }
}

// Concrete receiver for a stereo
class Stereo implements Device {
    @Override
    public void turnOn() {
        System.out.println("Stereo is now on");
    }

    @Override
    public void turnOff() {
        System.out.println("Stereo is now off");
    }

    public void adjustVolume() {
        System.out.println("Volume adjusted");
    }
}

// Invoker
class RemoteControl {
    private Command command;

    public void setCommand(Command command) {
        this.command = command;
    }

    public void pressButton() {
        command.execute();
    }
}

// Example usage
public class CommandPatternExample {
    public static void main(String[] args) {
        // Create devices
        TV tv = new TV();
        Stereo stereo = new Stereo();

        // Create command objects
        Command turnOnTVCommand = new TurnOnCommand(tv);
        Command turnOffTVCommand = new TurnOffCommand(tv);
        Command adjustVolumeStereoCommand = new AdjustVolumeCommand(stereo);
        Command changeChannelTVCommand = new ChangeChannelCommand(tv);

        // Create remote control
        RemoteControl remote = new RemoteControl();

        // Set and execute commands
        remote.setCommand(turnOnTVCommand);
        remote.pressButton(); // Outputs: TV is now on

        remote.setCommand(adjustVolumeStereoCommand);
        remote.pressButton(); // Outputs: Volume adjusted

        remote.setCommand(changeChannelTVCommand);
        remote.pressButton(); // Outputs: Channel changed

        remote.setCommand(turnOffTVCommand);
        remote.pressButton(); // Outputs: TV is now off
    }
}

TV is now on
Volume adjusted
Channel changed
TV is now off

When to use the Command Design Pattern 

• Decoupling is Needed:
  • In order to separate the requester making the request (the sender) from the object executing it, use the Command Pattern.
  • Your code will become more expandable and adaptable as a result.
• Undo/Redo Functionality is Required:
  • If you need to support undo and redo operations in your application, the Command Pattern is a good fit.
  • Each command can encapsulate an operation and its inverse, making it easy to undo or redo actions.
• Support for Queues and Logging:
  • If you want to maintain a history of commands, log them, or even put them in a queue for execution, the Command Pattern provides a structured way to achieve this.
• Dynamic Configuration:
  • When you need the ability to dynamically configure and assemble commands at runtime, the Command Pattern allows for flexible composition of commands.

When not to use the Command Design Pattern

• Simple Operations:
  • For very simple operations or one-off tasks, introducing the Command Pattern might be overkill.
  • It's beneficial when you expect your operations to become more complex or when you need to support undo/redo.
• Tight Coupling is Acceptable:
  • If the sender and receiver of a request are tightly coupled and changes in one do not affect the other, using the Command Pattern might introduce unnecessary complexity.
• Overhead is a Concern:
  • In scenarios where performance and low overhead are critical factors, introducing the Command Pattern might add some level of indirection and, in turn, impact performance.
• Limited Use of Undo/Redo:
  • If your application does not require undo/redo functionality and you do not anticipate needing to support such features in the future, the Command Pattern might be unnecessary complexity.

Command Design Pattern

Visit Course