2

http://www.oodesign.com/command-pattern.html In reading through a tutorial about the command pattern, I came across a UML diagram that seems to omit some relationships. For the following diagram, the client instantiates a stock trade, an agent, and buy and sell stock orders. Why is it that the author omits the relationship arrow to the agent class? Why is the dashed line for <> used in place of a solid arrow like the one from Client to StockTrade?

enter image description here

I also compared the above diagram with the one below, which leaves out the Invoker/Agent class entirely and also uses the class CallbackTwo to aggregate Receivers. The C# implementation has an invoker class, although the implementations in other languages don't. Does this mean the invoker relationship is implicit?

http://sourcemaking.com/design_patterns/command

http://sourcemaking.com/design_patterns/command/c-sharp-dot-net

enter image description here

  • the dashed arrow means "usage dependency", there are not arrows all over probably to make the diagram readable and not over-crowded. My understanding of the command pattern is such that the core concepts are abstract command and virtual execute(). The rest is an implementation detail – xmojmr Sep 12 '14 at 18:02
1

I recommend you don't take depicted diagrams too close. Depicted ones in GoF book should be referencing examples. Also, there are variations of patterns caused by environment where it is used.

The only thing we can do is formally validate it for UML and logic compliance.

At first diagram I see that designer wanted to show orders accumulation in agent instance, thus it uses "<>", but:

  1. Inside big yellow box with code sample Client doesn't call agent.sell() and thus all holded in 'Agent' instance 'Order's (bsc, ssc) will never be processed.
  2. Use of "<>" emphasizes that orders are holded inside 'Agent' and its relation is strong. Using of aggregation (<>) instead of simple association means more strong semantic, but I think in this certain case aggregation is not necessary. Hence, you're right, simple association (solid arrow) is good enough.
  3. Omitting of relationship between 'Client' and 'Agent' instances is a bug. There must be dependency (dashed line with <> and\or <>) between them.
  4. Moreover, designer was inconsistent in his decision. He redundantly placed field '+stock:StockTrace' in both 'BuyStockOrder' and 'SellStockOrder' and also added accociation between both 'BuyStockOrder' and 'SellStockOrder' and 'StockTrace'. But for similar case with 'Client' and 'StockTrace', 'Client' class doesn't contain '+stock:StockTrace' field.

At second diagram there are no invokers, thus it is assumed to be implicit :). The only thing I want to add that "also uses the class CallbackTwo to aggregate Receivers" is wrong. Word "also" is wrong.

  1. Previous example depicted Invoker (Agent) holding Comamnds (Orders), but there Command (CallbackTwo) holds some data (Receiver).
  2. Also, defining of both association and private field in CallbackTwo is redundant.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.