uml diagram of command pattern

Question

I need help to understand the command pattern. In the UML diagram, the client should have an associate arrow with the Invoker, why is this not shown? Who is calling the Invoker? If it is the Client, is it supposed to associate the Invoker?

Answer 1

Preliminary remarks

The illustration and explanations that you have inserted in your question are directly extracted from "Design Patterns, elements of reusable OO software" from Gamma et al., aka the GoF.

As a preliminary remark, this book was written in 1995 and uses James Rumbaugh's OMT (the details of the notation are presented p.14 of the book and in its annex B). In this diagramming, the class diagram shows with an arrow the associations for which the original object keeps a reference to the object on the arrow side.

(By the way, UML, even if a preversion was already published end of 1995, was only officialised in version 1.0 in 1997)

There is no direct structural relation between Client and Invoker

I think that Thomas Kilian already answered this before.

The class diagram (under the heading "Structure") clearly shows that Client does not have to be related to the Invoker.

But there are more arguments: In the explanations about participants and collaborations, nothing is said about a relation between Client and Invoker. Nor does the sample C++ code, which goes into pretty much details on Invoker, Command and Receiver.

The only suggested relation between the Client and Invoker is found in the interaction diagram which "illustrates how Command decouples the Invoker from the Receiver". By the way, on page 347 of the book there's a discussion about how behavioral patterns can decouple objects. An interaction diagram of the Command pattern is again presented, this time without any client.

Based on all these elements I'd state that the interaction between the Client and the Invoker in the diagram is only illustrative and was made to avoid introducing further objects.

Still have a doubt ?

I'd then suggest to go to the heading "Motivation" that explains the intent of the pattern with a practical example before abstracting the pattern.

The class diagram p.233 is the proof of my previous statement. In this diagram you have the Client (which is called Application). There is a relation between the Client and the Receiver (which is called Document). There's a relation between Command and Invoker (which is called MenuItem). There is no relation between the Client/Application and the Invoker/MenuItem. However Application has a relation to Menu, and Menu is the agregation of several MenuItem. So in this example there is an indirect relation.

So in the pattern, the direct relation between Client and Invoker is not necessary. There are certainly plenty of example where such a relation makes sense (it doesn't say that it is prohibited either!). There are also some examples where the relation is indirect. But it's not required for the pattern. You could certainly think of valid architectures where there is no relation, not even indirect between the Client and the Invoker.