Command mode _c language for C + + design Patterns

Objective

Again the new year, but also a ticket season; from college onwards, to work now, has been in the field, thousands of miles away from home, before the ticket, once also went to the railway station all night queuing to buy tickets, until 12306 of the vacated, in front of the computer does not stop the mouse to brush the ticket, that time 12306 is very fragile, rob a ticket is even more ; Well, now. Slowly strong 12306, buy tickets when a queuing system, the first ticket, into the 12306 queuing system; Then, the system one by one processing everyone's request, once your purchase ticket request enters the queuing system, you cannot carry on the ticket again, unless you exit the queuing system This reduces the number of ticket buyers and reduces the processing pressure of the 12306 backend servers. So, have you ever wondered how 12306 of your ticket requests were added to the queuing system? How is this queueing system implemented? And the command pattern I've summarized today will be a simple analysis of this.

What is command mode?

In Gof's design pattern: The basics of reusable object-oriented software: Encapsulate a request with an object so that you can parameterize clients with different requests, queue or log request logs for requests, and support revocable operations, and you can use the following instructions. In Oop, everything is an object, encapsulate the request into an object that conforms to OOP's design idea, and when a single request is encapsulated into an object, we can store more information on the request, making the request more capable; Command mode can also decouple the sender and receiver of the request, So that the sender of the command does not have to care about how the request will be processed.

We are on the 12306, click Buy tickets, this is a request, 12306 the request is encapsulated as an object, in 12306 is not online queuing system, you buy a ticket is this: You constantly click on the mouse 12306 of the purchase button on the website, until you buy the ticket; For every click you make, The server has to process, respond, and tell you that there are no tickets available; This may cause many invalid clicks, but these invalid clicks add to the burden on the server. After the queuing system is added, your purchase request is entered into the corresponding ticket queue. Once you enter the ticket queue, when you click on the ticket again, 12306 will refuse your ticket request, it will tell you that you have entered the ticket queue; You can opt out of the ticket queue to purchase tickets for other trips and enter other ticket queues. This effectively reduces the number of ticket buyers to send a lot of invalid purchase ticket requests.

This is like the votes are shared resources, everyone wants, but the number of votes is certain; in the absence of queuing system, everyone's request to buy tickets is to compete for this ticket, the server for everyone to share resources-the competition of the votes mutually exclusive, who grabbed the ticket on the less one; and now there is a ticket queue, we do not have to compete, Line up in chronological order, 12306 tickets to enter the queue of ticket buyers.

UML Class Diagram

Command: Declares an interface to perform an operation;
Concretecommand: Binds a Recipient object to an action, and then invokes the corresponding action of the receiver to implement execute to complete the corresponding command;
Client: Creates a specific command object, but does not set its recipient;
Invoker: Request the order to execute this request;
Receiver: Knowing how to implement an action related to executing a request, any class can be a recipient.

These objects are coordinated in the following ways:

1.Client creates a Concretecommand command object and specifies its receiver object;
The 2.Invoker object stores the Concretecommand object;
3. The invoker submits a request by calling the command object's execute operation. If the command request is revocable, Concretecommand stores the current state prior to executing the Execute operation to cancel the command request;
The 4.ConcreteCommand object invokes some actions of the receiver to execute the request.

Use occasion

Using command mode to implement 12306 (engineering download):
Chomepage class, representing the 12306 official website booking page;
C12306processor class, is the background to really deal with the user's request class, dedicated to the ticket;
Command class, which represents the user's request to purchase a ticket;
The customer class that represents the user who buys the ticket.
Because of the large number of code, this only provides engineering downloads.

This provides a general implementation of the command pattern:

Copy Code code as follows:

#include <iostream>
using namespace Std;

#define SAFE_DELETE (P) if (p) {DELETE p; p = NULL;}

Class Receiver
{
Public
void Action ()
{
cout<< "Receiver->action" <<endl;
}
};

Class Command
{
Public
virtual void Execute () = 0;
};

Class Concretecommand:public Command
{
Public
Concretecommand (Receiver *preceiver): M_preceiver (preceiver) {}
void Execute ()
{
M_preceiver->action ();
}
Private
Receiver *m_preceiver;
};

Class Invoker
{
Public
Invoker (Command *pcommand): M_pcommand (pcommand) {}
void Invoke ()
{
M_pcommand->execute ();
}
Private
Command *m_pcommand;
};

int main ()
{
Receiver *preceiver = new Receiver ();
Command *pcommand = new Concretecommand (preceiver);
Invoker *pinvoker = new Invoker (pcommand);
Pinvoker->invoke ();
Safe_delete (Pinvoker);
Safe_delete (Pcommand);
Safe_delete (Preceiver);
return 0;
}

Summarize

Command mode is a very Classic mode, my understanding will not be very in place; in our side, there are many examples of using command mode, the transaction in the database is to use the command mode to implement, in C # Delegates are also using the command mode to implement. I am here to share what I have learned in the course of my study. There may be some places my understanding is also wrong, I hope you and I share your understanding of the command mode.