Command Design Pattern

Last Updated : 06 Feb, 2024

The Command Design Pattern is a behavioral design pattern that turns a request into a stand-alone object, allowing parameterization of clients with different requests, queuing of requests, and support for undoable operations(action or a series of actions that can be reversed or undone in a system).

command-design-pattern-new-

Important Topics for the Command Design Pattern

What is the Command Design Pattern?

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(responsible for initiating command execution).
It decouples the sender (client or invoker) from the receiver (object performing the operation), providing flexibility and extensibility.
The pattern supports undoable(action or a series of actions that can be reversed or undone in a system) 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 without needing to know the details of each command.

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 nitty-gritty details of how each command accomplishes its task.

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. The remote control’s role is to coordinate and execute commands without getting involved in the complexities of individual actions.

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.

Command Design Pattern example

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?

First challenges is that devices can have different functionalities, so designing a remote control that can seamlessly handle different device types with varying functionalities without becoming overly complex or device-specific.
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 or device type.
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.
The remote control can dynamically change its behavior by associating different commands.

CommandPatternExampledrawio-(3)

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.

Java

// 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.

Java

// 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.

Java

// 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.

Java

// 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:

Java

// 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
    }
}

Output

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

When to use the Command Design Pattern

Decoupling is Needed:
- Use the Command Pattern when you want to decouple the sender (requester) of a request from the object that performs the request.
- This helps in making your code more flexible and extensible.
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.

Sulabh Kumar

Improve

Chain of Responsibility Design Pattern

Interpreter Design Pattern

Aug	SEP	Oct
	26
2023	2024	2025

Command Design Pattern

What is the Command Design Pattern?

Components of the Command Design Pattern

1. Command Interface

2. Concrete Command Classes

3. Invoker (Remote Control)

4. Receiver (Devices)

Command Design Pattern example

What can be the challenges while implementing this system?

How Command Pattern help to solve above challenges?

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

1. Command Interface

Java

2. Concrete Command Classes

Java

3. Receiver Classes (Devices)

Java

4. Invoker Class (Remote Control):

Java

Complete code for the above example

Java

Output

When to use the Command Design Pattern

When not to use the Command Design Pattern

Similar Reads

Please Login to comment...

What kind of Experience do you want to share?