23 design patterns (17) java command patterns, 23 Design Patterns

23 design patterns (17) java command patterns, 23 Design Patterns

23 design patterns Article 17th: java command patterns

Definition: encapsulate a request into an object so that you can parameterize the client using different requests, queue requests or record request logs, and provide command revocation and recovery functions.

Type: behavior mode

Class diagram:

Command mode structure

As the name implies, the command mode is the encapsulation of the command. First, let's look at the basic structure in the command mode class diagram:

Command class: it is an abstract class that declares the commands to be executed. Generally, an execute method should be published to execute commands.
ConcreteCommand class: The Implementation class of the Command class, which implements the methods declared in the abstract class.
Client class: The final Client call class.

The functions of the above three classes should be better understood. Next we will focus on the Invoker class and Recevier class.

Invoker class: caller, responsible for calling commands.

Receiver class: Receiver, responsible for receiving and executing commands.

The so-called command encapsulation is nothing more than writing a series of operations to a method, which can be called by the client and reflected on the class diagram, you only need one ConcreteCommand class and Client class to encapsulate the Command. even further, to increase flexibility, you can add another Command class for proper abstraction, what is the role of this caller and receiver?

In fact, you can think from another perspective: how can we simply encapsulate some operations as a command for others to call? As a behavior mode, the command mode requires low coupling and low coupling to improve flexibility. Therefore, the purpose of adding the caller and receiver roles is exactly the same. The common code for the command mode is as follows:

Class Invoker {private Command command; public void setCommand (Command command Command) {this. command = command;} public void action () {this.command.exe cute ();} abstract class Command {public abstract void execute ();} class ConcreteCommand extends Command {private extends er; public ConcreteCommand (extends er extends ER) {this. extends ER = extends er;} public void execute () {this. aggreger. doSomething () ;}} class uploer {public void doSomething () {System. out. println ("Receiver-business logic processing") ;}} public class Client {public static void main (String [] args) {receiver er extends ER = new Receiver Er (); command command = new ConcreteCommand (cmder); // The client directly executes the specific Command method (this method is consistent with the class diagram) command.exe cute (); // The client uses the caller to execute the command Invoker invoker = new Invoker (); invoker. setCommand (command); invoker. action ();}}

Through the code, we can see that when we call, the sequence of execution is first the caller class, then the command class, and finally the receiver class. That is to say, the execution of a command is divided into three steps, and its coupling is much lower than encapsulating all operations into a class, this is also the essence of the command mode: The caller and executor of the command are separated, so that the two sides do not have to worry about how the other side operates.

Advantages and disadvantages of command mode

First, the command mode is well encapsulated: every command is encapsulated. for the client, the corresponding command is called for any function, without the need to know how the command is executed. For example, there is a set of file operation commands: create a file, copy a file, delete a file. If You encapsulate these three operations into a command class, the client only needs to know that there are these three command classes. As for the logic encapsulated in the Command class, the client does not need to know.
Secondly, the scalability of the command mode is good. In the command mode, operations are typically encapsulated in the receiver class, and the command class performs secondary encapsulation on these basic operations, when a new command is added, the compilation of the command class is generally not from scratch. There are a large number of receiver classes available for calling, and a large number of command classes available for calling, code reuse is good. For example, in the file operation, we need to add a command to cut the file, you just need to combine the copy and delete files commands, It is very convenient.
Finally, let's talk about the disadvantages of the command mode. If there are many commands, it will be a headache for development. In particular, many simple commands are implemented with just a few lines of code. If you use the command mode, you don't need to worry about how simple the commands are, and you need to write a command class to encapsulate them.

Applicable scenarios of command mode

Most of the request-response modes are suitable for the command mode. As defined in the command mode, the command mode is more convenient for logging and Withdrawing operations.

Summary

It is a very tangled problem for all developers to use the no-use mode for an application. Sometimes, some design patterns are used for the flexibility and scalability of the system because we anticipate some changes in the demand, but this foreseeable demand is not. On the contrary, there were a lot of unexpected requirements, which led to the opposite effect of the design pattern used when modifying the Code, so that the entire project team complained. In this example, I believe every program designer has met each other. Therefore, based on the agile development principle, when designing a program, we should not introduce it if we can solve the problem well without a certain mode according to the current needs, it is not difficult to introduce a design mode. We can introduce this design mode to the system when it is actually needed.
Take the command mode for example. In our development, the request-response mode is very common. In general, we encapsulate the response operations on the request into a method, this encapsulated method can be called a command, but it is not a command mode. Whether or not to upgrade this design to the pattern level requires further consideration, because if you use the command mode, you need to introduce the caller and receiver roles, the logic originally put in one place is dispersed into three classes. during design, you must consider whether such a price is worthwhile.

The above is all the content of this article. I hope it will be helpful for your learning and support for helping customers.