Command Design Pattern
Start course
3h 59m

In this course, we will learn the concepts of microservice and spring framework with a focus on design patterns.

Learning Objectives

  • Learn about various design patterns

Intended Audience

  • Beginner Java developers
  • Java developers interested in learning how to Build and Deploy RESTful Web Services
  • Java Developers who want to develop web applications using the Spring framework
  • Java Developers who want to develop web applications with microservices
  • Java Developers who wish to develop Spring Boot Microservices with Spring Cloud


  • Basic Java knowledge

Hello, dear friends. In this video, we will examine Command Pattern, so let's begin. Command is a behavioral design pattern that turns a request into a standalone object that contains all information about the request. This transformation lets you pass requests as method arguments, delay our curer request execution, and support undoable operations. Command pattern is a data-driven design pattern. A request is wrapped under an object as command and passed to invoker object. Invoker object looks for the appropriate object which can handle this command and passes the command to the corresponding object which executes the command. It's also known as action or transaction. Let's examine the working structure of this pattern on the UML diagram. The command object knows about the receiver and invokes methods of the receiver by supplying parameters. Values for parameters of the receiver methods are stored in the command object. The receiver objects perform the job  when the execute() method of command gets called. We pass this command object to an invoker object to perform the execute() method. Invoker object executes the method of the command object and passes the required parameters to it.

The invoker can take different command objects, so the client deals only with the invoker to perform operations on different objects. These objects are called receiver objects. The command object collects all the details of requests and performs operations on the receiver. The command design pattern supports undoable operations as well, and we can have an unexecute() method to return the state of the object back to its original state. So, the pattern makes it super easy to perform a variety of jobs/requests in a simple way by using invoker objects. The invoker may also do bookkeeping for the command projects. Different command objects may have different receiver objects to act on. 

The execute() method defines and performs all the operations in a sequence to complete the job. The client application knows when and in which order to execute the commands. The only drawback of this pattern is we end up creating many command classes. With this working structure, we can say the command pattern separates the object that invokes the operation from the object that actually performs the operation. It also simplifies adding new commands because existing classes remain unchanged. So, in which cases would it be more appropriate to choose this structure? It's more useful to choose this structure when you need parameterize objects according to an action to be performed, or when you want to create queue and execute requests at different times. So, I think it's time to create a project to help learn how to implement this pattern, don't you think?

Create a new project and name it Command. The most commonly used example for this pattern is file operations. But there are a lot of examples of code for file operations online, so I want to make it something else. In our example, let's turn on and off the television and the air conditioner. First, we need an interface as a Command interface which will be implemented by the exact commands. Add an execute() method. Now, we need classes for television and air conditioner. Start with Television. We need on and off methods. Okay, done. Add AirConditioner.

Add methods for on and off. Now, for each method, we have to define a new class that implements from Command. TurnOnTelevision. Add television. Add a constructor. In constructor, we have to add a super() class. Now, we have to override the execute() method. Let's add for TurnOffTelevision. This will be the same with TurnOn only,  we will change this text, so if you want you can copy from On() method. Now, for the AirConditioner, we have to define these two classes also.

First start with TurnOn. Add AirConditioner. Create constructor. Add super() class. Override execute() method. Let's add for TurnoffAirConditioner. Done. Now, we need remote control. Add interface. We need a method to set Command. Also, we need a buttonPressed() method. Now, we have finished the structure, let's use it in main.

First, I want to add two televisions and two air conditioners for kitchen and bedroom. Now, create an instance from remote control. Now, we will set commands one by one. First television on bedroom, turn on. Press button, now turn on television on living room. Press button, go on.

Okay, done. Now, when we run the program, we can see the working order of these commands. Run. Look, we can see the commands are working. Great. So, I think that's enough for the command design pattern. In the next video, we will look at the iterator design pattern. So, I'll see you in the next video my friends.


About the Author
Learning Paths

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.