13. Command mode of design of toolbars in WebGIS¶
13.1. Background¶
Starting with this chapter we will formally enter the design and implementation of related features in the WebGIS toolboard. Using the basic tools in the toolbar in ArcMap as a template, we implement the zoom-in, zoom-out, pan, full-plot, clear, locate, I query, distance measurement, and area measurement in WebGIS.
Here, I will tell you a basic concept. We generally divide the tool into Command and Tool. The so-called command means that the tool is terminated once it takes effect. The Tool, when called, remains in effect until the tool is terminated or the tool is switched.
According to this theory, we can classify the basic tools in the toolbar into classes:
Command: full image, clear, positioning.
Tool: Zoom in, zoom out, pan, I query, distance measurement, area measurement.
13.2. Preliminary inquiry¶
Which tool in the toolbar for internal controls is instantiated and effective, can be done through the Policy Mode plus Factory mode. But for simplicity, the policy pattern is enough.
However, because there are many Tool-type tools in the toolbar, a simple policy pattern cannot meet the need for Tool termination and switching. Here we will use one of 23 design modes: command mode.
13.3. Introduction to command mode¶
13.3.1. Use scenarios¶
The use of command mode is given in the GOF:
A、When there is a call relationship between an application caller and multiple target objects, and the actions between target objects are similar.
B、When a method call inside a target object is too complex, or an internal method requires collaboration to complete a feature of an object (author note: for example, to “record, undo/redo, transaction” for behavior, etc.).
C、After the caller calls the target object, it needs to call back some methods.
Analysis of the use of our Tool is related to mouse events, such as: mouseDown, mouseUp, mouseMove, mouseOut, mouseClick, mouseWheel and so on. It is to satisfy the scene A used by the command mode, and scenes B and C are also likely to be triggered in our use.
To sum up the analysis, it is further proved that we are choosing to use the command mode correctly.
13.3.2. Command mode explanation¶
Here I give a UML diagram of the command mode:
|The above UML diagram involves five roles, which are:
Client role: Create a concrete Command object and determine its recipient.
Command role: Declares an abstract interface for all specific command classes.
Concrete Command role: Defines a weak coupling between a receiver and behavior; The execute() method is often called an execution method.
The Invoker role: Responsible for calling the command object to execute the request, the related method is called the action method.
Receiver role: Responsible for implementing and executing a request.Any class can be the recipient, and the method of implementing and executing the request is called the action method.
13.4. Specific implementation of command patterns in the system¶
In practice , we often make a slight adaptation to the UML in the design pattern given by GOF to simplify or facilitate development. Here, we’ve also made some changes to the UML above.
I will give the changed UML diagram first.
Because all commands are for Map, there is no way to design the Command as an interface, but to make it an abstract class, which has two advantages:
Make Map a property and associate Map directly on Command.
B.You can complete some common code in a class, such as the mouseWheel() method, which involves the functionality that is common to all command classes.
And abandoned the preparation of the receiver such as Receiver, but directly moved the method involved in Receiver to each ConcreteCommand. This can reduce the number of classes.
Command switching is controlled by a setMapCommand in the MapNavigation class similar to the Invoke class.
13.5. Advantages of using command mode¶
Looser coupling:
The command pattern makes the object that initiated the command-the client, and the object that specifically implements the command-completely decouple, that is, the object that initiated the command has no idea who the specific implementation object is or how to implement it.
More dynamic control:
The command mode encapsulates the request and dynamically parameterizes, queues, and logs it, making the system more flexible.
Natural composite commands:
Command objects in command mode can be easily combined into composite commands, i.e. macro commands, making system operation simpler and more powerful.
Better scalability:
Since the object that initiated the command is completely decoupled from the concrete implementation, it is easy to extend the new command, which only needs to implement the new command object, and then set the concrete implementation object to the command object at the time of assembly, and then you can with this command object, the existing implementation does not need to change at all.
13.6. Summary¶
In this chapter, we introduce the design and implementation of command patterns. In the next section, we’ll explain the design and implementation of the basic tools in the toolbar I mentioned: zoom in, zoom out, pan, full graph, clear, locate, I query, distance measurement, area measurement, and design and implementation.Welcome to the continued attention.