Navigator pattern: navigator mode

Mode name

• Navigator/navigator, a communication software packet processing mode

Intention

• Encapsulate the complex internal structure of message data. It provides addressing operations with service meanings to avoid risky pointer operations, reduce the possibility of duplication and errors, and provide clearer business meaning.

Motivation

In the development of network communication software, for the sake of transmission efficiency or integrity, the net load data of multiple units can be sent at a time in the definition of the application layer protocol, the specific quantity can be described by a field in the packet header. in addition, the length of the message style is not fixed. A field in the packet header is usually used to indicate the actual length of the message.

Such software is usually developed in C language. the classic solution is to define the following data structure for a message and Use Pointer operations to address specific data. when the data structure is nested, its pointer operation becomes very complex and prone to errors:

Typedef struct values {int field_1, char field_2, float field_3} secondlevelpayload; typedef struct toplevelpayload {int values, int values, secondlevelpayload * payload/payload nesting} toplevelpayload; typedef struct message {int count, toplevelpayload * payload} message; void print_datasync (Message * message) {toplevelpayload * Current = message-> payload; For (INT I = 0; I <message-> count; I ++) {printtoplevelpayload (current ++); // or printtoplevelpayload (Message-> payload [I]);}

The last function above tries to print all toplevelpayload cyclically, but the addressing method is wrong, because the address of the second toplevelpayload is not the first address plus the length of its own struct. the crux of this problem is that the C language lacks the facilities to describe dynamic sets. Only the pointer pointing to the first address is different from the size of the pointer pointing to the data. because the data stream is continuous, the size of the struct defined based on this is inconsistent with the actual data size. the initial correction is as follows:

void print_datagram(Message* message) {    TopLevelPayload* current = message->payload;    for(int i = 0; i < message->count; i++) {        PrintTopLevelPayload(current);        current = (TopLevelPayload*)((char*)current + sizeof(TopLevelPayload) + current->second_level_payload_count * sizeof(SecondLevelPayload));    }}    

In this way, the Code becomes obscure and the intent is invisible. pointer operations are prone to errors. When other code needs to be addressed inside the message, the code needs to be repeated to calculate the code again. When the definition of the packet protocol/structure changes, check all existing pointer operations to see if they are appropriate. we need better design.

Solution

The problem here is addressing. in real life, when we need to go to an address, we use navigation. it can be an instrument or a passer-by familiar with the local environment. but the interfaces are the same: we only need to tell him where we are going, and we do not need to know the terrain in advance. in the C language, it can be a set of interface functions with business meanings provided around the first packet address pointer:

TopLevelPayload* goto_nth_toplevel_payload(Message* message, int nth_toplevel_payload) {    TopLevelPayload* addr = message->payload;    for(int i = 0; i < nth_toplevel_payload; i++) {        addr = (TopLevelPayload*)((char*)addr + sizeof_toplevel_payload(addr));    }    return addr;}SecondLevelPayload* goto_nth_secondlevel_payload(TopLevelPayload* top, int nth_secondlevel_payload) {    return top->payload + nth_secondlevel_payload;}static int sizeof_toplevel_payload(TopLevelPayload* payload) {    return sizeof(TopLevelPayload) + payload->second_level_payload_count * sizeof(SecondLevelPayload);}

In this way, through the first packet address and goto_nth_toplevel_payload (), goto_nth_secondlevel_payload () functions, the customer code can cruise freely in the newspaper style without paying attention to its internal representation, no error-prone or obscure pointer operations are required. when the Message Protocol changes, we only need to modify the navigator without modifying the customer code.

Related Mode

The Page Object Mode describes how to encapsulate the changeable web pages in the Web application testing field. It also involves navigation to different page elements. the main problem solved is to reduce the impact of relatively frequent page changes on the stability of the test code and describe the test intent more clearly.