One: the definition of the command pattern
---> Command mode is a high-cohesion mode
---> Encapsulates a request into an object, allowing you to parameterize the client with different requests, queue requests, or log request logs to provide undo and redo functions for the command.
Role of---> Command mode
Receive receiver role ==> this role is the role of the job, the command is delivered here should be executed
command commands the role ==> all the commands that need to be executed are declared here
The Invoker caller role ==> receives the command and executes the command.
---> Command mode is simple, but very frequent in the project, because it is very good encapsulation, the requester (Invoker) and the executor (receiver) separated, scalability is also very good protection, general code is relatively simple
Second: The Application of command mode
Advantages of the "1" Command mode
Decoupling between classes
--there is no dependency between the caller role and the receiver role, and the caller implements the function simply by invoking the command abstract class's Execute method, without needing to know which receiver is executing.
Scalability
-->command subclasses can be extended very easily, while caller invoker and high-level module client do not produce serious code coupling.
Command mode combined with other modes will be more excellent
---Command mode can combine the responsibility chain mode to implement the command Family resolution task, and with the template method pattern, the expansion of the command subclass can be reduced.
Disadvantages of the "2" command mode
--and the command mode is also flawed, see command sub-class: If there are n commands, the problem is out, the command of the subclass can be not a few, but N, this class expands very large, this needs the reader in the project carefully consider the use.
Three: Usage Scenarios for Command mode
-As long as you think the command is where you can use the command mode, for example, in the GUI development, a button click is a command, you can use command mode, while the simulation DOS command, of course, the use of command mode, trigger-feedback mechanism processing, etc.
IV: Best Practices
---> This does simplify a lot, and each command accomplishes a single duty, rather than fulfilling different responsibilities depending on the recipient.
V.: case
"1" Command abstract class
1 PackageCom.yeepay.sxf.template10;2 /**3 * Abstract Command class4 * @authorSXF5 *6 */7 Public Abstract classCommand {8 //each command class must have a method to execute the command9 Public Abstract voidexecute ();Ten}
View Code
"2" Specific command Class 1
1 PackageCom.yeepay.sxf.template10;2 /**3 * Defines two specific command classes that the reader can extend in a real-world application. 4 * In each command class, the pass constructor defines which recipient the command is issued for, and defines a subject that the command receives. 5 * The caller is very simple and only implements the command delivery,6 * @authorSXF7 *8 */9 Public classConcreteComand1extendscommand{Ten //Recipient One Privatereceiver receiver; A - //Constructors - PublicCONCRETECOMAND1 (receiver receiver) { the This. receiver=receiver; - } - //a command must be implemented - @Override + Public voidExecute () { - This. receiver.dosomething (); + } A at}
View Code
"3" Specific command Class 2
1 PackageCom.yeepay.sxf.template10;2 3 4 /**5 * Receive Commands6 * @authorSXF7 *8 */9 Public classConcreteComand2extendsCommand {Ten //Recipient One Privatereceiver receiver; A //Constructors - PublicConcreteComand2 (receiver receiver) { - This. receiver=receiver; the } - //a command must be implemented - @Override - Public voidExecute () { + This. receiver.dosomething (); - } + A at}
View Code
"4" Receive class (real performer) abstract class
1 PackageCom.yeepay.sxf.template10;2 /**3 * Abstract Recipient4 * @authorSXF5 * Very strange, why is receiver an abstract class?6 * That's because the receiver can have more than one, and there are multiple abstract sets of all the attributes that need to be defined--abstract recipients,7 *8 */9 Public Abstract classReceiver {Ten //Abstract recipient that defines the business that each recipient must complete One Public Abstract voiddosomething (); A}
View Code
"5" (True performer 1
1 PackageCom.yeepay.sxf.template10;2 /**3 * Recipient 14 * @authorSXF5 *6 */7 Public classConcreteReciver1extendsreceiver{8 9 @OverrideTen Public voiddosomething () { OneSystem.out.println ("concretereciver1.dosomething () I want to go to earth"); A } - - the}
View Code
"6" true performer 2
1 PackageCom.yeepay.sxf.template10;2 /**3 * Recipient 24 * @authorSXF5 *6 */7 Public classConcreteReciver2extendsReceiver {8 9 @OverrideTen Public voiddosomething () { OneSystem.out.println ("concretereciver2.dosomething (I want to go to Mars)"); A } - -}
View Code
"7" Caller
1 PackageCom.yeepay.sxf.template10;2 /**3 * Caller4 * Caller is like a doormat, no matter what the command, to receive, execute!5 * @authorSXF6 *7 */8 Public classInvoker {9 /**Ten * Command Class One */ A Privatecommand command; - /** - * doormat, receive command the * @paramCommand - */ - Public voidsetcommand (Command command) { - This. command=command; + } - /** + * Execute Command A */ at Public voidaction () { - This. Command.Execute (); - } -}
View Code
"6" Client
1 PackageCom.yeepay.sxf.template10;2 /**3 * Client Class4 * @authorSXF5 *6 */7 Public classClient {8 9 Public Static voidMain (string[] args) {Ten //first declare the caller Invoker OneInvoker Invoker =NewInvoker (); A //define a recipient -Receiver receiver=NewConcreteReciver1 (); - //defines a command sent to the recipient. theCommand command=NewConcreteComand1 (receiver); - //Give the command to the caller to execute - invoker.setcommand (command); - //Execute Command + invoker.action (); - + } A}
View Code
Design pattern of Zen design mode-command mode