Objective:
I'm studying UNIX programming art recently. The previous rough flip, thought to be introduced UNIX tools. Now seriously looked at the next, originally is the introduction design principle. Its core is the first chapter of the UNIX philosophy and 17 design principles, and the following content is around it to expand. Previously said, to learn the appropriate information, and to determine whether the appropriate way is to see if you can read it. I have a encounter feeling about the book. A friend who has 4-6 years of working experience can read it.
Business:
When the author introduces Unix design principles, there is a "principle of representation: stack knowledge into data to make logic simple and robust". Combined with some of my previous experience, I am very sympathetic to this principle, so I learned the data-driven programming related content, here and we share it with you to discuss.
The core of data-driven programming
The core point of data-driven programming is that humans are better at processing data than on program logic. Data is easier to navigate than program logic, so we should shift the complexity of the design from the program code to the data as much as possible.
Is that really the case? Let's take a look at an example.
Suppose there is a program that needs to handle messages sent by other programs, the message type is a string, and each message needs a function to process. First impressions that we might have handled like this:
Copy Code code as follows:
void Msg_proc (const char *msg_type, const char *msg_buf)
{
if (0 = strcmp (msg_type, "Inivite"))
{
Inivite_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "tring_100"))
{
Tring_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "ring_180"))
{
Ring_180_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "ring_181"))
{
Ring_181_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "ring_182"))
{
Ring_182_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "ring_183"))
{
Ring_183_fun (MSG_BUF);
}
else if (0 = strcmp (msg_type, "ok_200"))
{
Ok_200_fun (MSG_BUF);
}
。。。。。。
else if (0 = strcmp (msg_type, "fail_486"))
{
Fail_486_fun (MSG_BUF);
}
Else
{
Log ("Unrecognized message type%s\n", Msg_type);
}
}
The message type above is taken from the SIP protocol (not exactly the same, the SIP protocol borrows from the HTTP protocol), and the message type may increase. Looking at the process may be a little tired, testing the middle of a message there is no processing is also more laborious, and, without adding a message, it is necessary to add a process branch.
According to data-driven programming ideas, this might be the design:
Copy Code code as follows:
typedef void (*sip_msg_fun) (const char *);
typedef struct __MSG_FUN_ST
{
const char *msg_type;//message type
Sip_msg_fun fun_ptr;//function pointer
}msg_fun_st;
Msg_fun_st msg_flow[] =
{
{"Inivite", Inivite_fun},
{"tring_100", Tring_fun},
{"ring_180", Ring_180_fun},
{"ring_181", Ring_181_fun},
{"ring_182", Ring_182_fun},
{"ring_183", Ring_183_fun},
{"ok_200", Ok_200_fun},
。。。。。。
{"fail_486", Fail_486_fun}
};
void Msg_proc (const char *msg_type, const char *msg_buf)
{
int type_num = sizeof (msg_flow)/sizeof (MSG_FUN_ST);
int i = 0;
for (i = 0; i < type_num; i++)
{
if (0 = = strcmp (Msg_flow[i].msg_type, Msg_type))
{
Msg_flow[i].fun_ptr (MSG_BUF);
return;
}
}
Log ("Unrecognized message type%s\n", Msg_type);
}
The following advantages of this idea:
1, the readability is stronger, the message processing flow is at a glance.
2, more easily modified, to add new messages, as long as the data can be modified, do not need to modify the process.
3, reuse, the first scheme a lot of else if in fact only the message type and processing function is different, but the logic is the same. The following scenario is to extract the same logic, and to refer to the outer part of the variable that is easily changed.
Implicit in the thought behind:
Many design ideas behind the principle are actually interlinked, implied in data-driven programming behind the implementation of ideas include:
1, the control of complexity. The goal of controlling complexity is achieved by transferring the complexity of the program logic to the data that is easier to be processed by humans.
2. Isolate and change. As in the example above, the logic of each message processing is immutable, but the message may be variable, separating the easily changing message from the logic that is not easily changed.
3. Separation of mechanism and strategy. Like the 2nd, many places in this book refer to mechanisms and strategies. In the example above, my understanding is that the mechanism is the processing logic of the message, and the strategy is the different message processing (later, I want to write a special article about the mechanism and strategy).
What data-driven programming can be used to do:
As shown in the example above, it can be applied to the design at the function level.
At the same time, it can also be applied to the program-level design, typically using a table-driven method to implement a state machine (written in the following article specifically).
It can also be used in system-level design, such as DSL (I'm not quite sure of my experience at the moment).
It is not what:
1, it is not a new programming model: It is only a design idea, and has a long history, in the Unix/linux community application a lot;
2, it is different from object-oriented design data: "In data-driven programming, data not only represents the state of an object, but actually defines the process of the program; Oo is about encapsulation, and data-driven programming is about writing as little code as possible. ”
Something worth thinking about in a book:
Data is overriding. The correct algorithm is self-evident if the correct data structure is chosen and the organization is organized. The core of programming is data structures, not algorithms. --rob Pike
Programmers are helpless ... Only the jump code, straight up, thinking about the data is the best action. The essence of expression programming. --fred Brooks
Data is easier to navigate than program logic. It is a good practice to transfer the complexity of design from code to data as much as possible. --The author of Unix programming art.
