Deep understanding of the JavaScript series (34): Design Patterns in the command mode detailed _javascript skills

Introduced

Command mode is defined to encapsulate a request into an object so that you can parameterize clients with different requests, queue or log request logs, and perform revocable operations. This means that the change mode is designed to encapsulate the invocation, request, and operation of a function into a single object, and then perform a series of processing on the object. In addition, you can decouple a command object from a receiving object by calling the object that implements the specific function.

Body

We are going to show this model through the vehicle purchase process, first defining the specific operation class of the vehicle purchase:

Copy Code code as follows:

$ (function () {

var Carmanager = {

Request Information
Requestinfo:function (model, id) {
Return ' The information for ' + model +
' with ID ' + ID + ' is foobar ';
},

Buy a car
Buyvehicle:function (model, id) {
Return ' have successfully purchased Item '
+ ID + ', a ' + model;
},

Organization View
Arrangeviewing:function (model, id) {
Return ' to have successfully booked a viewing of '
+ model + ' (' + ID + ') ';
}
};
})();

Take a look at the code above and simply execute the manager's commands by calling a function, but in some cases we do not want to call the methods inside the object directly. This increases the dependencies between objects and objects. Now let's extend this carmanager to allow it to accept any processing requests from Carmanager objects that include the model and car IDs. Based on the definition of the command pattern, we want to implement a call to this function:

Copy Code code as follows:

Carmanager.execute ({commandtype: "Buyvehicle", Operand1: ' Ford Escort ', Operand2: ' 453543 '});

According to this kind of demand, we can implement the Carmanager.execute method:

Copy Code code as follows:

Carmanager.execute = function (command) {
return Carmanager[command.request] (Command.model, Command.carid);
};

After the transformation, the call is much simpler, the following calls can be implemented (of course some of the exception details need to be refined again):

Copy Code code as follows:

Carmanager.execute ({request: "arrangeviewing", Model: ' Ferrari ', Carid: ' 145523 '});
Carmanager.execute ({request: "Requestinfo", Model: ' Ford Mondeo ', Carid: ' 543434 '});
Carmanager.execute ({request: "Requestinfo", Model: ' Ford Escort ', Carid: ' 543434 '});
Carmanager.execute ({request: "Buyvehicle", Model: ' Ford Escort ', Carid: ' 543434 '});

Summarize

Command mode is easier to design a command queue, in the case of requirements it is easier to count the commands into the log and allow the party accepting the request to decide whether the call is required, and can implement the undo and reset of the request, and it is easy to implement because the new concrete class does not affect other classes.

But the agile development principle tells us not to add a guessing-based, actually do not need the function, if it is not clear whether a system needs command mode, generally do not worry to achieve it, in fact, in the need of refactoring to achieve this mode is not difficult, only in real demand such as the undo, restore operation, and other functions, Refactoring the original code into command mode makes sense.