Design Pattern _ Command pattern

Design Pattern _ Command pattern
Define Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. (encapsulate a request into an object so that you can use different requests to parameterize the client, queue requests or record request logs, and provide command revocation and recovery functions)
Unrecognized word Encapsulate Encapsulation
Thereby and
Parameterize is represented by parameters. parameterization
Undoable can be undone

Class Diagram

 

Receiver Recevier: defines the task to be completed by each receiver (similar to a tool class). The Command abstract class has an execute method (similar to a machine graph assembly) ConcreteCommand subclass, and the member is an abstract class, when the execute method is used, the method of the receiver is called (similar to an assembly machine). Invoker has a Command member, and the action method is to execute the execute method (in my opinion, this is a bit redundant) in short, the Command encapsulates the consumer er, And the Invoker encapsulates the Command

 

 

public abstract class Group { public abstract void find(); public abstract void add(); public abstract void delete(); public abstract void change(); public abstract void plan();}

public abstract class Command {  protected RequirementGroup rg=new RequirementGroup(); protected PageGroup pg=new PageGroup(); protected CodeGroup cg=new CodeGroup();  public abstract void execute();}

public class Invoker { private Command command;  public void setCommand(Command command){  this.command=command; }  public void action(){  this.command.execute(); }}

 

 

Three subclasses

 

public class CodeGroup extends Group { @Override public void add() {  System.out.println(add code); } @Override public void change() {  System.out.println(change code); } @Override public void delete() {  System.out.println(delete code); } @Override public void find() {  System.out.println(find code); } @Override public void plan() {  System.out.println(plan code); }}

public class PageGroup extends Group { @Override public void add() {  System.out.println(add page); } @Override public void change() {  System.out.println(change page); } @Override public void delete() {  System.out.println(delete page); } @Override public void find() {  System.out.println(find page); } @Override public void plan() {  System.out.println(plan page); }}

public class RequirementGroup extends Group { @Override public void add() {  System.out.println(add requirement); } @Override public void change() {  System.out.println(change requirement); } @Override public void delete() {  System.out.println(delete requirement); } @Override public void find() {  System.out.println(find requirement); } @Override public void plan() {  System.out.println(plan requirement); }}

Write commands one by one as needed, which is very scalable

 

 

Public class AddRequirementCommand extends Command {/*** run the Add Command */@ Override public void execute () {super. rg. find (); super. rg. add (); super. rg. plan ();}}

Public class DeletePageCommand extends Command {/*** Command for deleting a page */@ Override public void execute () {super. pg. find (); super. rg. delete (); super. rg. plan ();}}

Okay, the command has been written.

 

How to call it? Is it okay to directly call the execute method of this class? To better reflect the dependency and system design characteristics (accept and execute whatever commands are accepted), callers and recipients have no dependency. The caller only needs to call the execute method of the Command abstract class.

 

Public class Client {public static void main (String [] args) {Invoker invoker = new Invoker (); System. out. println (-------- the customer requested to add a requirement -------------); Command command = new AddRequirementCommand (); // use command.exe cute (); invoker. setCommand (command); invoker. action () ;}}/* High Cohesion * The caller Invoker and the receiver Group are not dependent, and Command is easy to expand * the disadvantage is that if there are many sub-classes of Command, requires N sub-classes to be implemented one by one */

 

Wu: In my opinion, this scalability is good, but there is no technical content to write, because every multiple items require a combined command for the customer to call, similarly, the existence of Invoker is just for good looking. The essence is assembly and processing. Different from the intermediary, the sub-classes of the business here are the same, while the intermediary is different.