Actions Using the Command Pattern

It is a common practice to represent an UI operation that a user can perform as an Action. For example, to open a file in Notepad is an operation that can be represented by an action, say OpenFileAction.

Actions are implemented using the Command pattern. I’ll provide a short explanation of the Command pattern below.

The Command pattern has the following two major players.

• IAction Interface – This interface declares the Execute() method.
  

  public interface IAction
  {
  void Execute();
  }

• Action Class – The concrete action class like the OpenFileAction implements the IAction interface and provides it’s own Execute() method. Either the constructor or the Execute() method itself can receive an argument that acts as the input on which the action will be performed.
  

  public class OpenFileAction: IAction
  {
  public void Execute()
  {
  // The code for opening a file goes here…
  }

  }

Thus, the Command pattern allows to encapsulate an operation as an object.

Answers to a few questions need to be explored before going ahead.

1. Where can the actions be used?
   • In a modern software application, any operation can be performed from a number of places. For example, a new file can be created from the menu or the toolbar or a right click context menu. Having an action like CreateFileAction allows to call it’s Execute() method from all the three places.
2. Why should I use actions?
   • The biggest advantage of this concept is that the UI and the Business Logic are separated which creates a system with lower coupling. Duplication of code is also avoided as the same action can be used form any place.
3. Can an action be called from another action?
   • Yes. I’ll give a practical scenario where the calling code must know whether the action was executed successfully. Suppose you are working on a text file in a text editor, say MS Word. To close the application, you click on the Close menu under File. This fires the CloseApplicationAction. But the file has to be saved before closing the application. It’s the SaveFileAction that takes care of saving the file (in case it is unsaved) . Instead of putting the code for checking if the file is unsaved and asking the user if he wants to save the file in both the actions, the CloseApplicationAction simply calls the SaveFileAction internally. Thus, once an operation has been abstracted as an action, it can be called from anywhere given one can pass it the right input.
4. What if the action needs to inform about it’s success or failure? How can this be done?
   • In the above-mentioned example, the CloseApplicationAction in turn calls the SaveFileAction. The SaveFileAction first checks if the file has been modified. If it has been, the SaveFileAction asks the user if he wants to save the file – Yes, No and Cancel options are provided. Now the CloseApplicationAction depends upon the outcome of the SaveFileAction. In case the user says Yes or No , the SaveFileAction does accordingly, the control comes back to the CloseApplicationAction and it must closes the application. However, if the user chooses Cancel during the SaveFileAction then the CloseApplicationAction must terminate without closing the application. The simplest way to give the success or failure feedback is to return a boolean from the Execute() method.

public interface IAction
{
bool Execute();
}

Thus, the Command pattern allows to encapsulate an operation as an object. The Java framework provides a built-in support for Actions. In one of my next posts, I’ll write about how Java is more “Action friendly” as compared to .NET.