Command mode-"A commander requests (command) three-way attack the enemy"

Document directory

• 1.1 how to boot
• 1.2 What should I do
• 1.3 what's the problem?
• 2.1 command mode to solve
• 2.2 schema structure and description
• 2.3 command mode sample code

1.1 how to boot

It is estimated that some friends may find this title very strange. How can I start the computer after the computer is assembled? Is it okay to press the start button? Isn't there any xuanjicang.
For customers who use computers-that is, it is really easy to boot. Press the start button and wait patiently. But after we press the start button? Who will handle it? What should I do? What kind of process has the computer really started for us to use.
First, let's take a look at the computer startup process.

• When we press the start button, the power supply starts to power the motherboard and other devices.
• System BIOS (Basic Input/Output System) of the motherboard after power-on
• The bios of the motherboard looks for the BIOS of other devices, such as the video card, and asks them to perform self-check or initialization.
• Start to detect CPU, memory, hard disk, optical drive, serial port, parallel port, soft drive, plug-and-play device, etc.
• BIOS updates escd (extended system configuration data). escd is a means for the bios and the operating system to exchange hardware configuration data.
• After all the preceding operations are completed, the BIOS will boot the system according to the user configuration, enter the operating system, and wait until the operating system is loaded and initialized, the familiar system logon interface is displayed.

1.2 What should I do

After talking about the process of starting a computer, some friends may wonder, what should I do?
Yes, it seems that this hardware knowledge has nothing to do with you, but if you make a request: please use the software to show the process above, how do you implement it?
First, let's summarize the above process. The main steps are as follows: First load the power, then check the device, then load the system, and then start the computer properly. But who will complete these processes? How to complete?
We cannot allow customers who use computers to do this work. The main board is the main board. How can customers contact the main board? In reality, the button is connected to the motherboard using a connection line, so when the customer presses the button, it is equivalent to sending a command to the motherboard, let the motherboard to complete the subsequent work.
In addition, from the customer's point of view, starting the system means pressing the button. No matter what kind of motherboard is the same, that is to say, the customer just sends the command, who receives the command, who implements the command, and how to implement it, customers do not care about it.

1.3 what's the problem?

Abstract The above question to describe it: the client only wants to issue a command or request, and does not care who the real receiver of the request is or how to implement it, in addition, the actions of the same request can have different request content. Of course, the specific processing functions are different. How can this problem be solved?

2 solution 2.1 command mode to solve

A reasonable solution for solving the above problems is the command mode. So what is the command mode?
(1) command mode definition

Encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and support auditable operations.

(2) Application Command mode to solve the problem

First, let's look at the actual computer solution.
First, draw a picture to describe how the actual computer handles the problem described above, as shown in 1:

Figure 1 Computer Operations

When the customer presses the button, the button itself does not know how to handle it. Therefore, the customer requests the motherboard through a connection line to allow the motherboard to truly start the machine.
In order to describe the relationship between them, the motherboard is painted out of the chassis. If the connection line is connected to a different motherboard, the motherboard that actually executes the button request will be different, and the customer does not know these changes.
By introducing buttons and connection lines, we can completely decouple the customer who sends the command from the real-time implementer of the command-the main board. The customer always operates the button, and the customer does not care about the things after the button.
A natural solution is to simulate the above solution to solve the problem raised above.
In the command mode, a command interface is defined to constrain all command objects and then provide specific command implementations. Each command implementation object encapsulates a client request, corresponding to the buttons on the chassis, a single chassis can have many buttons, which is equivalent to multiple specific command implementation objects.
In command mode, the command object does not know how to process the command, and the corresponding receiver object will be used to actually execute the command. Like a computer example, the buttons on the chassis do not know how to handle the function, but instead forward the request to the motherboard for the real function, this motherboard is equivalent to the receiver in command mode.
In the command mode, the relationship between the command object and the receiver object is not inherent. An assembly process is required. The client object in the command mode can implement this function. This is equivalent to a computer example where a button on the chassis and a motherboard are available. You also need a connection line to connect the button to the motherboard.

The command mode also provides an invoker object to hold the command object. In the example of a computer, there are multiple buttons in the chassis, which is equivalent to the invoker object in the command mode. Such
The client in the command mode can use invoker to trigger and execute the corresponding command. This is equivalent to the actual customer pressing the button on the chassis to operate the computer.

2.2 schema structure and description

The command mode structure 2 is shown below:

Figure 2 command mode structure
Command:

Define the command interface and declare the execution method.
Concretecommand:

The implementation object of the command interface is a "virtual" implementation. It usually holds the receiver and calls the receiver's function to complete the operation to be executed by the command.
Aggreger:

Recipient, the object that actually executes the command. Any class may become a receiver, as long as it can implement the corresponding functions required by the command.
Invoker:

The command object is required to execute the request. Generally, the command object is held and many command objects can be held. This is the place where the client actually triggers the command and requires the command to execute the corresponding operation, that is, it is equivalent to the entry of the command object.
Client:

Create a specific command object and set the receiver of the command object. Note that this is not a client in the general sense, but an assembly of command objects and recipients. It may be better to call this client an assembler, because the client that actually uses the command triggers the execution from invoker.

2.3 command mode sample code

(1) Let's take a look at the definition of the command interface. The sample code is as follows:

/** * Command interface: Declares the executed operation */ Public interface command { /** * Operations corresponding to commands executed */ Public void execute (); }

(2) Let's take a look at the specific command implementation object. The sample code is as follows:

/** * Specific command implementation object */ Public class concretecommand implements command { /** * Hold the corresponding recipient object */ Private Referer = NULL; /** * Indicates that the command object can have its own State. */ Private string state; /** * Constructor: input the corresponding receiver object * @ Param receiver the corresponding receiver object */ Public concretecommand (extends er extends ER ){ This. Cycler = Cycler; } Public void execute (){ // It usually calls the corresponding method of the recipient object to allow the recipient to truly execute the function. Aggreger. Action (); } }

(3) let's take a look at the implementation of the receiver object. The sample code is as follows:

/** * Recipient object */ Public class extends er { /** * Indicates the method to actually execute the corresponding commands */ Public void action (){ // Functional code that truly executes command operations } }

(4) let's take a look at the invoker object. The sample code is as follows:

/** * Caller */ Public class invoker { /** * Holding command objects */ Private command = NULL; /** * Set the command object held by the caller * @ Param command object */ Public void setcommand (command ){ This. Command = command; } /** * Indicates the method. The command is required to execute the request. */ Public void runcommand (){ // Call the execution method of the command object Command.exe cute (); } }

(5) let's take a look at the implementation of the client,Note that this is not a test client in the general sense. The main function is to create a command object and set its receiver. Therefore, no code is called for execution.
The sample code is as follows:

Public class client { /** * Indicates to create a command object and set its receiver. */ Public void assemble (){ // Create a receiver Worker er worker ER = new worker Er (); // Create a command object and set its Receiver Command command = new concretecommand (aggreger ); // Create an invoker and set the command object Invoker = new invoker (); Invoker. setcommand (command ); } }