In-depth analysis of the use of command patterns in Ruby design pattern programming _ruby Special Topics

Command mode is a design pattern with a higher rate of object behavior usage, alias: Action (Action), Transaction (transaction)

Intent: To encapsulate a request into an object so that you can parameterize different requests, queue or log request logs for requests, and support actions that can be canceled
This so-called "different request" also means that the request may change, is a possible extension of the function point.

Motivation: Easy to expand

Structure:

Collaboration Description:
Participating roles:
Command declares an interface to be used to implement an operation.
Concretecommand binds the action to the Reciver and implements the command method by invoking the corresponding method of the Reciver object.
The Client creates the Concretecommand object and sets its Reciver object.
Invoker requires the command to implement the request.
Reciver know how to implement a specific request for a class.
The client creates a specific command object and assigns its recipients.
The caller object stores this specific command object.
The caller object implements the current request by executing the Execute method of the Command object.
If the command is revocable, the specific object stores the state to command the request before it is invoked to execute the method.
The specific command object invokes the method of its receiver to implement the corresponding request.

Applicability:
Similar to MenuItem, abstract an action to be performed to parameterize an object
Specify, arrange, and execute requests at different times
Support Undo
Support for modifying logs
Construct a system (in fact, a transaction) in a high-level operation built on a primitive operation

Dynamic aspect: As in Ruby, block is the command mode.

Effect:
The command mode decoupling the caller object from the receiving object (calling and implementing decoupling). The caller implements the function by simply invoking the Execute method of the command interface.
Specific commands objects are first-level objects that can be extended or manipulated like other objects.
You can aggregate multiple commands objects into a single group command. A combination command is also an instance of a composite object pattern, and it is a special case to queue the command.
You can easily add new commands because you don't need to modify existing code. This also conforms to the opening and closing principles, to the modification of the closure, to the extended open.

The implementation should take into account what kind of Smart Program the Command object should reach and support undo and redo.

Misuse:
Don't be obsessed with what's easy?
Command mode is not to say "do this" and "remember how to do it", and later on "Do this in the way I just wanted you to remember."
Careful undo, many operations are destructive, such as deleting file operations

Class Diagram:

 class Button attr_accessor:name: Command def Initialize name, command @name = Name @command = Command End def do_something @command. Execute End Class Command def execute ' root exe Cute ' End ' class Paintcommand < Command def execute ' Draw Something ' End Class Vocalcommand < Co  Mmand def execute "talk Something" end end paintcommand = paintcommand.new Vocalcommand = vocalcommand.new button = Button.new ("button", Paintcommand) p button.do_something button.command = Vocalcommand p button.do_something 

/div>

The principal class Button,button is defined to aggregate a command object, declaring the Command,paintcommand,vocalcommand three inherited command classes, where there may be multiple button in the system. What each button has to do is different, that is, the part is changed, that is, the code in method do_something is also indeterminate, separating this part of the code into a separate object for management, and this object is called the Command object, The Command object is responsible only for the task that needs to be done or is the instruction, and the principal object can execute it at any time according to its needs. It is also very clear in the code at the call that the command to switch the current button is very convenient and flexible, and can be done simply by calling the set method. If you adopt the relationship of button inheritance, the first principal object can cause class explosion, and the second is difficult to compare this way when switching the command implementation.

Use Ruby proc to complete the command mode:

Class Button
 
 attr_accessor:name
 
 def initialize name, &command
  @name = name
 end
 
 def do_ Something &command
  command.call
 end

paint_command = lambda do
 p "paint Something"
End

Vocal_command = lambda does
  p "talk something"
end

button = button.new ("name")
Button.do_ Something &vocal_command
button.do_something &paint_command

You can see that using block instead of the command class is simpler, understandable, in the actual project environment using proc and commands can be the case, if the command object is very complex, need to have their own state and methods, the use of the command class to complete, if simply to deal with some small things, you can use proc

If you need to execute too many commands, you can define a command queue, which is a command that manages multiple commands, which, when invoked, executes each command, from which it is very much like a combination pattern.

In a sense, the observer pattern and the command pattern are similar in that they aggregate some objects with common characteristics into their own classes, and then invoke them according to the circumstances. But there is one obvious difference between the 2 models, which is the use. The observer pattern is used by the observer to inform the different observers of the change, the command mode does not care whether it is notification to other commands, the command object is only responsible for performing its own task or instruction, and the command mode can remember the previous operation, so many text editor's undo/ Redo will be used in command mode.