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:
- 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.
- 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.
- Omitting of relationship between 'Client' and 'Agent' instances is a bug. There must be dependency (dashed line with <> and\or <>) between them.
- 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.
- Previous example depicted
Invoker (Agent) holding
Comamnds (Orders), but there
Command (CallbackTwo) holds some data (
- Also, defining of both association and private field in
CallbackTwo is redundant.