Design patterns: Command

Today, the pattern a little more complicated than the previous one, ie the Command pattern, is very similar to the Chain of Responsibility pattern, however, it differs a little, has a very similar purpose as the chain of responsibilities, that is, the transmission of requests, but if necessary can they are still written on the stack in order to eg undo the previously performed operation, more precisely about this pattern further in the article 🙂



The main purpose of this pattern is to encapsulate all data needed to execute the request, usually this data is the object so that the parameters of these requests can be changed depending on the type of recipient, this pattern have also possibility to save the requests on the stack or queue to view the history of these requests or, if necessary, undo these requests.

The most important elements in the implementation of the Command pattern are:

  • The Command interface that has a defined execute() method.
  • The ConcreteCommand class that extends the Command interface by extending the execute() method.
  • The Receiver class, which communicates with the ConcreteCommand class, forwards the client’s requests.
  • The customer who creates the ConcreteCommand class object and sets the Receiver class.

There are many examples where you can use the command pattern 🙂 You can use it as I mentioned earlier in some applications that require viewing history or undoing or adding some action, you can also use it in progress bar, and surely you know to what progress bar is used for 🙂 of course, to review the progress of executing some requests, the command pattern it is also often used to perform actions after clicking on the button, for example. etc etc. 🙂

As you can see, the uses of the Command pattern are many 🤔 , especially in these large projects.



  • Encapsulation the request in the object
  • Changing the parameters of the request depending on the type of recipient.
  • The ability to save requests in the queue.



For example, you must send requests to objects without knowing these requests or objects receiving the request.


Use when:

  • You need to view the history of requests made or as you need, undo them.
  • You must encapsulate all the data you want to send.
  • You must change the parameters of these requests without violating the open-closed principle.



Standard UML diagram of the Command pattern:

I do not have to repeat myself, I have already explained what is more or less the implementation in the discussion section at the top.

The CallbackInterface interface is the Command interface and the rest of the classes that expand this interface is ConcreteCommand.

Let’s finally get to the real code 🙂



Switching the lamp

A simple example of turning the lamp on and off so that you can easily understand this pattern

Let’s start with the ICommand interface.

Has a method defined as method Execute(), nothing extraordinary 🙂

Classes that extend the ICommand interface to CloseSwitchCommand and OpenSwitchCommand.

First CloseSwitchCommand.

And OpenSwitchCommand.

Also, nothing difficult 🙂 these classes call methods depending on whether we want to turn on the lamp or turn it off.

You can also see the defined ISwitchable interface in these classes so as not to create a specific class type. We remember the Dependency inversion principle 🙂

Let’s see what is in the ISwitchable interface.

Also, nothing difficult 🙂 We have defined methods of turning the lamp on and off 🙂

Let’s go further 🙂 to the Receiver class in our case it’s called Switch.

We see that this class communicates with the CloseSwitchCommand and OpenSwitchCommand classes, which we pass to the constructor and in this way we can call their methods.

And the Light class, which displays the appropriate messages and saves the status of the lamp.

Finally, the customer.

In the client, we create objects of these classes and put them in the appropriate constructors of other classes. And we’ll see the appropriate messages depending on what we enter in the console.


Some of you may ask “Why is it so complicated? Is not it better to do it in this way?

Well, the main motivation for using the Command pattern is to encapsulate all the data needed to perform the request, in the previous example everything is encapsulated in requests and we have a nicely separate code for sending requests and a code receiving these requests, which gives us a nicer and more flexible code and of course we can monitor demands, but I think that those who do not do major projects should, for now, have this pattern, so to speak “behind the head”. The Command pattern we should use in this bigger projects. In these smaller and medium-sized projects, we should be guided by the KISS principle.


Real-life example

Restaurant – ordering food

Suppose we have to make a system that records all the activities of ordering food from the order by the customer to the order to the cook and we want to be able to see the orders that are in the queue, it is good to use the command pattern in this example. To illustrate the situation is the picture below 🙂

We start from the Customer customer class.

IOrder interface

We know the client places the order for the waiter, so we go to the Waiter class.

ICommand interface

The waiter saves the order, in our case to the Order class.

ICookAble interface

And he hands it over to the cook, in other words the Cook class.

Naturally, the waiter gave the order card to the cook, so he can read them all. Of course, all orders are saved in a queue, according to which customer first placed the order 🙂

Beautifully simple and pleasant 🙂

And we create all objects in the Main function.



Relations with other design patterns

  • The patterns of Chain of Responsibility, Command, Mediator, and Observer describe how you can separate classes that send requests and receive them, but with different compromises 🙂
  • The Chain of Responsibility pattern can use the Command pattern to represent requests as objects.
  • Sometimes, some of the actions that we want to write to the history we need to copy, this works like the Prototype pattern.
  • The Command pattern can use the Memento pattern to preserve the state needed for the undo operation.
  • You can say that the Memento and Command patterns work like tokens only, that in Command token represents a request and in Memento the token represents the internal state.



That’s all about Command🙂.

Link to github with the whole code from this article:

This content also you can find on my steemit blog:

And on medium:

In the next article, we will talk about the State pattern.

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb: Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

Illustrations, pictures and diagrams are from:

If that post was useful for you share it with your friends :)

Post a comment

Notify about