Introduction: What is data-driven programming

Preface:
I recently studied Unix programming art. In the past, I thought it was about unix tools. Now I have carefully read the design principles. Its core is the unix philosophy introduced in chapter 1 and 17 design principles, which will be carried out later. As I have said before, to learn the appropriate materials, one way to determine whether it is suitable is to see if you can read it. I have a sense of mutual hate for this book. 4 ~ If you have 6 years of work experience, you can read it.
Question:
When introducing the Unix design principles, the author wrote "representation principle: Stacking knowledge into data to make the logic simple and robust ". Based on some of my previous experiences, I have a strong resonance with this principle. So I first learned about data-driven programming. I will share this with you and discuss it with you.
Core of data-driven programming
The core starting point of data-driven programming is that humans are better at processing data than program logic. Data is easier to control than program logic, so we should try our best to transfer the complexity of design from program code to Data.
Is that true? Let's look at an example.
Assume that a program needs to process messages sent by other programs. The message type is a string, and each message needs a function for processing. The first impression may be handled as follows: Copy codeCode: 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_1820.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 ("unknown message type % s \ n", msg_type );
}
}

The above message type is taken from the sip protocol (not exactly the same, the sip protocol uses the http protocol for reference), and the message type may increase. The process may be a little tired. It is also difficult to check whether a message in the middle is processed. In addition, if no message is added, a process branch is required.
According to the data-driven programming idea, the design may be as follows:Copy codeThe Code is 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_fun", 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 ("unknown message type % s \ n", msg_type );
}

The following advantages:
1. more readable and clear message processing process.
2. It is easier to modify. To add new messages, you only need to modify the data without modifying the process.
3. Reuse. In the first solution, many else if messages are of different types and processing functions, but the logic is the same. The following solution extracts the same logic and mentions the components that are easy to change.
The thought behind it:
The principles behind many design ideas are actually the same. The Implementation ideas behind data-driven programming include:
1. control complexity. By transferring the complexity of the program logic to the data that is easier for humans to process, the complexity can be controlled.
2. Isolate changes. As in the preceding example, the logic of each message is unchanged, but the message may be changed. In this case, the logic of the message that is easy to change is separated from the logic that is not easy to change.
3. Separation of mechanisms and policies. This is very similar to the second one. Many parts of this book refer to mechanisms and strategies. In the above example, I understand that the mechanism is the message processing logic, and the policy is different message processing (I would like to write an article later to introduce the mechanism and policy ).
What data-driven programming can do:
As shown in the preceding example, it can be applied to function-level design.
At the same time, it can also be applied in program-level design. For example, a table-driven state machine can be implemented (this article will introduce it later ).
It can also be used in system-level design, such as DSL (my experience is somewhat lacking and it is not very definite at present ).
What is it:
1. It is not a brand-new programming model: it is just a design concept and has a long history. It has many applications in the unix/linux community;
2. It is different from the data in Object-Oriented Design: "in data-driven programming, data not only indicates the state of an object, but also defines the process of the program. OO focuses on encapsulation, data-driven programming focuses on writing as few code as possible."
The words worth thinking about in the book:
Data is overwhelming. If a correct data structure is selected and all organizations are well organized, the correct algorithm is self-evident. The core of programming is the data structure rather than algorithms. -- Rob Pike
Programmers are helpless ..... Only by jumping off the code, getting up and thinking carefully about data is the best action. The essence of Expression Programming. -- Fred Brooks
Data is easier to control than program logic. It is a good practice to transfer the design complexity from code to Data. -- Author of unix programming art.