Command Pattern

Command Pattern

With the Command Pattern, we can decouple objects that execute a certain task from the object that calls the method.

Let's say we have an online food delivery platform. Users can place, track, and cancel orders.

When to Use

• Use this when you need to decouple the object invoking an operation from the object performing it
• This is helpful when commands need a certain lifespan or should be queued and executed at specific times

When NOT to Use

• For simple one-off operations that don't need undo/redo, queuing, or logging
• When direct function calls are clear enough and the extra abstraction adds complexity without benefit
• When the system has few operations and the command infrastructure would be over-engineering

Instructions

• Create a Command class with an execute method that encapsulates the action
• Replace direct method calls with command objects passed to a single execute method on the manager
• Use this pattern sparingly as it can add unnecessary boilerplate in simpler JavaScript applications

Details

class OrderManager {  constructor() {    this.orders = []  }
  placeOrder(order, id) {    this.orders.push(id)    return `You have successfully ordered ${order} (${id})`;  }
  trackOrder(id) {    return `Your order ${id} will arrive in 20 minutes.`  }
  cancelOrder(id) {    this.orders = this.orders.filter(order => order !== id)    return `You have canceled your order ${id}`  }}

On the OrderManager class, we have access to the placeOrder, trackOrder and cancelOrder methods. It would be totally valid JavaScript to just use these methods directly!

const manager = new OrderManager();
manager.placeOrder("Pad Thai", "1234");manager.trackOrder("1234");manager.cancelOrder("1234");

However, there are downsides to invoking the methods directly on the manager instance. It could happen that we decide to rename certain methods later on, or the functionality of the methods change.

Say that instead of calling it placeOrder, we now rename it to addOrder! This would mean that we would have to make sure that we don't call the placeOrder method anywhere in our codebase, which could be very tricky in larger applications. Instead, we want to decouple the methods from the manager object, and create separate command functions for each command!

Let's refactor the OrderManager class: instead of having the placeOrder, cancelOrder and trackOrder methods, it will have one single method: execute. This method will execute any command it's given.

Each command should have access to the orders of the manager, which we'll pass as its first argument.

class OrderManager {  constructor() {    this.orders = [];  }
  execute(command, ...args) {    return command.execute(this.orders, ...args);  }}

We need to create three Commands for the order manager:

• PlaceOrderCommand
• CancelOrderCommand
• TrackOrderCommand

class Command {  constructor(execute) {    this.execute = execute;  }}
function PlaceOrderCommand(order, id) {  return new Command((orders) => {    orders.push(id);    return `You have successfully ordered ${order} (${id})`;  });}
function CancelOrderCommand(id) {  return new Command((orders) => {    const index = orders.indexOf(id);    if (index > -1) orders.splice(index, 1);    return `You have canceled your order ${id}`;  });}
function TrackOrderCommand(id) {  return new Command(() => `Your order ${id} will arrive in 20 minutes.`);}

Perfect! Instead of having the methods directly coupled to the OrderManager instance, they're now separate, decoupled functions that we can invoke through the execute method that's available on the OrderManager.

Pros

The command pattern allows us to decouple methods from the object that executes the operation. It gives you more control if you're dealing with commands that have a certain lifespan, or commands that should be queued and executed at specific times.

Cons

The use cases for the command pattern are quite limited, and often adds unnecessary boilerplate to an application.

Source

• patterns.dev/vanilla/command-pattern

References

• Command Design Pattern - SourceMaking
• Command Pattern - Refactoring Guru
• Command Pattern - Carlos Caballero