This is the 11th day of my participation in Gwen Challenge

Command mode

Command mode is a behavioral design mode, which encapsulates a series of instructions. The user only needs to invoke the interface to complete a series of commands. For example, the “shutdown” command of the computer may be just a shutdown operation for the user, but for the computer, the bottom layer does a lot of things, such as suspending events saved in execution, saving the system configuration, ending the current process, and finally the kernel command actually shuts down the computer.

Definition: requests are encapsulated as objects, user requests are parameterized on the client side, requests are queued or logged, and undoable operations are supported.

In actual combat

At first glance, the following code may seem a bit cumbersome. A function class can do everything by calling Paint. Why wrap a Command layer around it and then call it through Button? It seems to complicate a simple problem. However, it is necessary in the design pattern that changes are not provided externally, only extension functions are provided externally. For the caller, he only cares about the function, not the process. The Command pattern is not a simple example of wrapping code in layers, but it has its own features. Each method in paint is wrapped by each Command for a purpose. When the corresponding instruction is called, it can record the corresponding execution of an instruction. When the history needs to be traced, it can find out which instruction was executed before so as to support the revocable function in the process.

So there’s a good reason why so many classes need to be wrapped to do what at the code level seems to be done by calling Paint. Complexity is designed to make systems more robust and scalable, not for complexity’s sake.

public class Paint{
    public void drawLine(a){}
    public void drawCircle(a){}
    public void drawRectangle(a){}
    public void fillColor(a){}}public interface Command{
    void execute(a);
}

public class DrawLineCommand implements Command{
   Paint  paint;
   public DrawLineCommand(Paint paint){
       this.paint = paint;
   }
   @override
   void execute(a){ paint.drawLine(); }}...public class FillColorCommand implements Command{
   Paint  paint;
   public FillColorCommand(Paint paint){
       this.paint = paint;
   }
   @override
   void execute(a){ paint.fillColor(); }}public class Button{
    privateDrawLineCommand drawLineCommand; .private FillColorCommand fillColorCommand;
    
    public void setDrawLineCommand(DrawLineCommand drawLineCommand){
        this.drawLineCommand = drawLineCommand; }...public void setFillColorCommand(FillColorCommand fillColorCommand){
        this.fillColorCommand = fillColorCommand;
    }  
    public void drawLine(a){ drawLineCommand.drawLine(); }...public void fillColor(a){
        fillColorCommand.fillColor();
    }
}

Button button = new Button();
button.drawLine();
button.fillColor();
Copy the code

conclusion

The downside of command mode is the same as most design patterns: class bloat. Every new feature may result in the creation of a large number of classes, but this is inevitable. However, design patterns are designed for better weak coupling, flexible control, and extensibility. Sacrificing some class bloat is not fatal. It is necessary to adopt design patterns rather than make the code runnable, durable, and readable. In practice, however, you need to think about whether design patterns are necessary.