Implementing the Command pattern

[TEK]

Hello

I'm wondering if anyone out there might give some
input/suggestions/viewpoints around the Command pattern.
In my case, the number one priority for using the pattern is undo support.
Some now, a lot more in the future.
I think I have a pretty good understanding about how the command pattern is
tought to work, however during implementation I'm htting a couple of quite
large design considerations that I'm not sure I have the answare to.

There is problably no 100% answares to the issues, but maybe some best
practices?

The main issues I'm looking at is:

1) Should the command class or the receiver implement the code that peforms
the operations the command is for.

2) Should the command class be given all arguments needed to peform the
operations when initialized, or should it be collected during execution.

3) Should the command class be allowed to peform UI operations, as asking
the user for confirmation, or should it be limited to peform pure business
operations.

Any feedback would be appriciated...

Regards, TEK

 

[Immo Landwerth]

I'm wondering if anyone out there might give some
input/suggestions/viewpoints around the Command pattern.
In my case, the number one priority for using the pattern is undo
support. Some now, a lot more in the future.
I think I have a pretty good understanding about how the command
pattern is tought to work, however during implementation I'm htting a
couple of quite large design considerations that I'm not sure I have
the answare to.

There is problably no 100% answares to the issues, but maybe some best
practices?

The main issues I'm looking at is:

1) Should the command class or the receiver implement the code that
peforms the operations the command is for.

If your implemenatation of the command pattern is straightforward the
answer is: The command class itself.

On the other hand you might have encountered the same problems as I
have so the answer could be: The command processor. See

http://www.vico.org/pages/PatronsDisseny/Pattern Command Processor/

for details of this pattern.

2) Should the command class be given all arguments needed to peform
the operations when initialized, or should it be collected during
execution.

When you hand the arguments to the constructor of the command class
this implies that you cannot store references to commands since they
are created every time they are executed. This complicates the binding
of commands to toolbar or menu items.

To simplify the binding I would suggest to collect the arguments during
execution.

Normally these arguments would be something one could express as some
kind of selection. To get the current selection one could implement a
method like GetCurrentSelection() within the command processor class.
The more sophisticated solution would be to use an interface for this
task (e.g. IHostSelectionService) which is handed to the constructor of
the CommandProcessor class.

To allow undo and redo of commands the commands must be enabled to
return appropriate data structures. These data structures should be
handled as opaque; only the command who created it can process it. The
pattern to implement that kind of data structures is called "Memento".
See

http://www.vico.org/pages/PatronsDisseny/Pattern Memento/

for details.

For redo and undo support the command class could have two methods,
Undo() and Redo() which accept a reference to this data structure.

The command processor is responsible for storing the undo/redo stack
and therfore to call the undo/redo methods of the commands.

3) Should the command class be allowed to peform UI operations, as
asking the user for confirmation, or should it be limited to peform
pure business operations.

That depends on the complexity of you software

To allow UI operations within the commands itself you greatly simplify
the process of writing commands but you make your commands more
dependant on your UI (which makes refatoring of the UI more
complicated).

If you are using something like the above mentioned
IHostSelectioService you should extremly reduce the need of UI
interaction. So the only UI interaction I can think of are more generic
like confimations or file open dialogs.

All in all I would recommend to allow MessageBox() and the standard
Windows Forms dialogs but nothing else.