Design Patterns: CommandBlog

Introduction

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 Command Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

You can click on the diagram to open it online in Pladitor.

Diagram Sources

Here are the diagram sources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

@startuml

skinparam Ranksep 15
hide empty fields
hide empty methods

class Client
class Invoker
interface Command
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

note left of Client
The Client is responsible for
creating a ConcreteCommand and
setting its Receiver.
end note

note bottom of Receiver
The Receiver knows how to
perform the work needed to
carry out the request. Any class
can act as a Receiver.
end note

note bottom of ConcreteCommand
The ConcreteCommand defines a binding between an action
and a Receiver. The Invoker makes a request by calling
execute() and the ConcreteCommand carries it out by
calling one or more actions on the Receiver.
end note

note left of Invoker
The Invoker holds
a command and at
some point asks the
command to carry
out a request by
calling its execute()
method.
end note

note top of Command
Command declares an interface for all commands. A
command is invoked through its execute() method,
which asks a receiver to perform its action.
end note

note right of ConcreteCommand::execute()
The execute method invokes the action(s)
on the receiver needed to fulfill the
request;

""public void execute() {""
"" receiver.action()""
""}""

end note
@enduml

Open this diagram online with Pladitor.