Upload
shahriar-hyder
View
1.843
Download
0
Embed Size (px)
DESCRIPTION
Command Design Pattern - Behavioral Pattern
Citation preview
Command PatternCommand Pattern
When Actions Speak Louder Than Words
When Actions Speak Louder Than Words
Shahriar HyderKaz Software Ltd.
17th October, 2011
IntentIntent
Encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations
Encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations
Command PatternCommand Pattern An object is used to represent and encapsulate all
the information needed to call a method at a later time
This information includes the method name, the object that owns the method, and the values for the method parameters
Three fundamental Command pattern terms: Client: instantiates command object and provides information to call the method at a later time
Invoker: decides which method should be called (Executes the Commands Possibly at a later time)
Receiver: an instance of the class that contains the method's code (The object the command should affect)
An object is used to represent and encapsulate all the information needed to call a method at a later time
This information includes the method name, the object that owns the method, and the values for the method parameters
Three fundamental Command pattern terms: Client: instantiates command object and provides information to call the method at a later time
Invoker: decides which method should be called (Executes the Commands Possibly at a later time)
Receiver: an instance of the class that contains the method's code (The object the command should affect)
Class DiagramClass Diagram
Client Invoker
setCommand()
<<interface>>Command
execute()undo()
Receiver
action()
ConcreteCommand
execute()undo()
public void execute() { receiver.action()}
CollaborationsCollaborations
The Client creates a ConcreteCommand object and specifies its receiver.
An Invoker object stores the ConcreteCommand object.
The invoker issues a request by calling execute( ) on the command.
The ConcreteCommand object invokes operations on its receiver to carry out the request.
The Client creates a ConcreteCommand object and specifies its receiver.
An Invoker object stores the ConcreteCommand object.
The invoker issues a request by calling execute( ) on the command.
The ConcreteCommand object invokes operations on its receiver to carry out the request.
aReceiver anInvokeraCommandaClient
new Command (Rx)
StoreCommand(Command)
Execute( )
Action( )
Sequence Diagram
More usesMore uses Queuing requests
Can allocate commands to various threads for processing to load balance between threads/processors
Logging requests (audit trail) Just have to save the command objects as they execute.
If something goes wrong, we can read the log and re-create the sequence of commands (so no data is lost).
Can also back out changes that cause troubles
Command Pattern can model transaction systems
Queuing requests Can allocate commands to various threads for processing to load balance between threads/processors
Logging requests (audit trail) Just have to save the command objects as they execute.
If something goes wrong, we can read the log and re-create the sequence of commands (so no data is lost).
Can also back out changes that cause troubles
Command Pattern can model transaction systems
Main ConceptsMain Concepts It decouples an object making a request, from the one that knows how to
perform it the command requester only needs to know how to issue it; it doesn't
need to know how to perform it Command object is at the center of this decoupling and encapsulates a
receiver with an action An invoker makes a request of a Command object by calling its execute()
method, which invokes those actions on the receiver Invokers can be parameterized with Commands, even at runtime Macro Commands: an extension of Command that allow multiple commands
(Composite) to be invoked Two user interfaces may share an instance of the same concrete Command
subclass. Commands are first-class objects. They can be manipulated and extended
like any other object. Two important aspects of the Command pattern:
1. interface separation (the invoker is isolated from the receiver),
2. time separation (stores a ready-to-go processing request that’s to be stated later).
It decouples an object making a request, from the one that knows how to perform it the command requester only needs to know how to issue it; it doesn't
need to know how to perform it Command object is at the center of this decoupling and encapsulates a
receiver with an action An invoker makes a request of a Command object by calling its execute()
method, which invokes those actions on the receiver Invokers can be parameterized with Commands, even at runtime Macro Commands: an extension of Command that allow multiple commands
(Composite) to be invoked Two user interfaces may share an instance of the same concrete Command
subclass. Commands are first-class objects. They can be manipulated and extended
like any other object. Two important aspects of the Command pattern:
1. interface separation (the invoker is isolated from the receiver),
2. time separation (stores a ready-to-go processing request that’s to be stated later).
Related Patterns!Related Patterns!
Chain of Responsibility can use Command to represent requests as objects.
Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
Memento can hold the state a command requires to undo its effect!
Composite can be used to implement macro commands! Commands that are copied before being placed on a
history list act as Prototypes!
Chain of Responsibility can use Command to represent requests as objects.
Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
Memento can hold the state a command requires to undo its effect!
Composite can be used to implement macro commands! Commands that are copied before being placed on a
history list act as Prototypes!