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).
Important Topics for the Command Design Pattern
What is the Command Design Pattern?
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.
- 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.
.png)
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
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
public class TurnOnCommand implements Command {
private Device device;
public TurnOnCommand(Device device) {
this.device = device;
}
@Override
public void execute() {
device.turnOn();
}
}
public class TurnOffCommand implements Command {
private Device device;
public TurnOffCommand(Device device) {
this.device = device;
}
@Override
public void execute() {
device.turnOff();
}
}
public class AdjustVolumeCommand implements Command {
private Stereo stereo;
public AdjustVolumeCommand(Stereo stereo) {
this.stereo = stereo;
}
@Override
public void execute() {
stereo.adjustVolume();
}
}
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
public interface Device {
void turnOn();
void turnOff();
}
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");
}
}
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
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
interface Command {
void execute();
}
class TurnOnCommand implements Command {
private Device device;
public TurnOnCommand(Device device) {
this.device = device;
}
@Override
public void execute() {
device.turnOn();
}
}
class TurnOffCommand implements Command {
private Device device;
public TurnOffCommand(Device device) {
this.device = device;
}
@Override
public void execute() {
device.turnOff();
}
}
class AdjustVolumeCommand implements Command {
private Stereo stereo;
public AdjustVolumeCommand(Stereo stereo) {
this.stereo = stereo;
}
@Override
public void execute() {
stereo.adjustVolume();
}
}
class ChangeChannelCommand implements Command {
private TV tv;
public ChangeChannelCommand(TV tv) {
this.tv = tv;
}
@Override
public void execute() {
tv.changeChannel();
}
}
interface Device {
void turnOn();
void turnOff();
}
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");
}
}
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");
}
}
class RemoteControl {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void pressButton() {
command.execute();
}
}
public class CommandPatternExample {
public static void main(String[] args) {
TV tv = new TV();
Stereo stereo = new Stereo();
Command turnOnTVCommand = new TurnOnCommand(tv);
Command turnOffTVCommand = new TurnOffCommand(tv);
Command adjustVolumeStereoCommand = new AdjustVolumeCommand(stereo);
Command changeChannelTVCommand = new ChangeChannelCommand(tv);
RemoteControl remote = new RemoteControl();
remote.setCommand(turnOnTVCommand);
remote.pressButton();
remote.setCommand(adjustVolumeStereoCommand);
remote.pressButton();
remote.setCommand(changeChannelTVCommand);
remote.pressButton();
remote.setCommand(turnOffTVCommand);
remote.pressButton();
}
}
|
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.
Like Article
Suggest improvement
Share your thoughts in the comments
Please Login to comment...