Home » Blog » Software Development » Software Design Patterns in PlantUML » Design Patterns with PlantUML: Command Pattern

Design Patterns with PlantUML: Command Pattern

This post gives a brief overview about the Command Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Command Pattern?

According to Wikipedia, the Command Pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The Command Pattern solves problems like:

  • Coupling the invoker of a request to a particular request should be avoided. That is, hard-wired requests should be avoided.
  • It should be possible to configure an object (that invokes a request) with a request.

Implementing (hard-wiring) a request directly into a class is inflexible because it couples the class to a particular request at compile-time, which makes it impossible to specify a request at run-time.

What solution does the Command design pattern describe?

  • Define separate (command) objects that encapsulate a request.
  • A class delegates a request to a command object instead of implementing a particular request directly.

This enables one to configure a class with a command object that is used to perform a request. The class is no longer coupled to a particular request and has no knowledge (is independent) of how the request is carried out.

UML Diagram

The following diagram shows the Factory Method Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Client<br />
class Invoker<br />
class Command <<interface>><br />
class Receiver<br />
class ConcreteCommand</p>
<p>Invoker : setCommand()<br />
Command : execute()<br />
Command : undo()<br />
Receiver : action()<br />
ConcreteCommand : execute()<br />
ConcreteCommand : undo()</p>
<p>Client -> Receiver<br />
Client -> ConcreteCommand<br />
Receiver <- ConcreteCommand<br />
Invoker -> Command<br />
Command <|.. ConcreteCommand</p>
<p>note left of Client<br />
The Client is responsible for<br />
creating a ConcreteCommand and<br />
setting its Receiver.<br />
end note</p>
<p>note bottom of Receiver<br />
The Receiver knows how to<br />
perform the work needed to<br />
carry out the request. Any class<br />
can act as a Receiver.<br />
end note</p>
<p>note bottom of ConcreteCommand<br />
The ConcreteCommand defines a binding between an action<br />
and a Receiver. The Invoker makes a request by calling<br />
execute() and the ConcreteCommand carries it out by<br />
calling one or more actions on the Receiver.<br />
end note</p>
<p>note left of Invoker<br />
The Invoker holds<br />
a command and at<br />
some point asks the<br />
command to carry<br />
out a request by<br />
calling its execute()<br />
method.<br />
end note</p>
<p>note top of Command<br />
Command declares an interface for all commands. A<br />
command is invoked through its execute() method,<br />
which asks a receiver to perform its action.<br />
end note</p>
<p>note right of ConcreteCommand::execute()<br />
The execute method invokes the action(s)<br />
on the receiver needed to fulfill the<br />
request;</p>
<p>“”public void execute() {“”<br />
“” receiver.action()””<br />
“”}””</p>
<p>end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@startuml
class Client
class Invoker
class Command <<interface>>
class Receiver
class ConcreteCommand

Invoker : setCommand()
Command : execute()
Command : undo()
Receiver : action()
ConcreteCommand : execute()
ConcreteCommand : undo()

Client -> Receiver
Client -> ConcreteCommand
Receiver <- ConcreteCommand

Invoker -> Command
Command <|.. ConcreteCommand

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Factory Method Pattern - This post gives a brief overview about the Factory Method Pattern. The post is part of a series about software ... Read More
Decorator Pattern Design Patterns with PlantUML: Decorator Pattern - This post gives a brief overview about the Decorator Pattern. The post is part of a series about software design ... Read More
Observer Pattern Design Patterns with PlantUML: Observer Pattern - This post gives a brief overview about the Observer Pattern. The post is part of a series about software design ... Read More

Check Also

Adapter Pattern

Design Patterns with PlantUML: Adapter Pattern

This post gives a brief overview about the Adapter Pattern. The post is part of …

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

We use Cookies and similar technology to collect and analyse information about the users of this website. We use this information to enhance the content, advertising and other services available on the site. Please click ‘Accept cookies’ to consent to the use of this technology by petrockblock. You can manage your preferences at any time by visiting our Cookies Policy page.