Package org.fishbolt.common.command

The Command pattern In the "Design Patterns: Elements of Reusable Object-Oriented Software" book the description of the command pattern is provided mainly in the aspect of its usage in the user interface (undo for an operation, command history).

See:
Description

Interface Summary

ICommand<V>	In the case if some command delegates the execution to the other command you should not explicitly invoke the call() method.
ICommandProcessor	Responsible for the command execution.

Package org.fishbolt.common.command Description

The Command pattern

In the "Design Patterns: Elements of Reusable Object-Oriented Software" book the description of the command pattern is provided mainly in the aspect of its usage in the user interface (undo for an operation, command history).

Here we want to clarify how the command pattern supports the internal implementation of a command. The main goal of the proposed pattern version is to hide the resources used by a command (database connections, database transactions, files with data, etc.) from the user.

The main advantage of using this pattern version is flexibility in managing resources and their configuration.

The interface part consists of three interfaces: java.util.concurrent.Callable, ICommand, and ICommandProcessor

As well-known, only one method call(), which returns the result of the command execution, is declared in the Callable interface. In our case an implementation of the method should not solve the problems connected with providing an access to some resource.

In the ICommandProcessor interface the ICommandProcessor.processCommand(Callable) method is declared. This method gets an instance of a command as an argument and invokes its call() method. All operations responsible for management of resources are encapsulated exactly in the ICommandProcessor.processCommand(Callable) method.

In the case if some command delegates the execution to the other command you should not explicitly invoke the call() method. It will be more correct to execute the command using the processor, because it is responsible for managing recourses. The ICommand interface extends Callable. The ICommand.setCommandProcessor(ICommandProcessor) method has to be called by the processor just before the call of the command (the call() method). Thus, the command "knows" about an instance of the processor that is executing it and is able to correctly delegate the call to the other command.