The principle and use of Google Protocol buffer (iv)

There is an e-commerce system (assuming that it is implemented in C + +), where module a needs to send a large amount of order information to module B, using the socket in the way of communication.
Suppose the order includes the following attributes:
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Duration: Time (expressed in integers)
Customer Id:userid (expressed in integers)
Transaction amount: Price (indicated by floating-point number)
Description of the transaction: Desc (denoted by string)
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
If you use PROTOBUF implementation, first write a proto file (perhaps called Order.proto), and add a message structure called "Order" in the file to describe the structured data in the communication protocol. The contents of the document are as follows:

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Message Order
{
Required Int32 time = 1;
Required Int32 userid = 2;
Required float price = 3;
Optional String desc = 4;
}

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Then, compile the proto using the PROTOBUF built-in compiler. Since the module in this example is C + +, you can generate the "Order wrapper class" in the C + + language by protobuf the compiler's command-line arguments (see "Here"). (In general, a message structure generates a wrapper class)
Then you use code like the following to serialize/parse the Order wrapper class:

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Sending party

Order order;
Order.set_time (XXXX);
Order.set_userid (123);
Order.set_price (100.0f);
Order.set_desc ("A Test order");

String SOrder;
Order. Serailzetostring (&sorder);

Then call the communication Library of some kind of socket to send the serialized string out.
// ......

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Receiving party

String SOrder;
First, the data is received through the network communication library and stored to a string sorder
// ......

order Order;
if (order. Parsefromstring (SOrder))  //parse the string
{
  cout << "userid:" << order.userid () << endl
          <<" desc: "<< order.desc () << Endl
}
else
{
  cerr << "Parse error!" << endl;
}

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

With this code generation mechanism, developers no longer have to Chi Chi to write code for protocol parsing (this is a typical thankless job).
In the event of a future change in demand, the requirement to add a "status" attribute to the order requires only one line of code to be added to the Order.proto file. For the sender (module a), just add a line of code to set the state, and for the receiver (module B) Just add a line of read state code. Wow, this is so easy!
In addition, if both sides of the communication are implemented using different programming languages, using this mechanism can effectively ensure that the modules on both sides are consistent with the protocol processing.
By the way, digress.
In a sense, the proto file can be viewed as a specification (or interface specification) describing a communication protocol. This kind of trick is actually old already, has engaged in Microsoft's COM programming or has contacted the CORBA schoolmate, should all can see IDL (detailed explanation see "here") shadow. Their thoughts are interlinked.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

The principle and use of Google Protocol buffer (iv)