Identifying the simplicity and flexibility of design is sometimes not easy. Let's start with a simple example. Suppose we need to write a function to implement "home.example.net! A string in the format of {sm = 1} user@other.example.net becomes "home.example.net! User@other.example.net, that is, remove the contents of the curly braces. Note that there may be multiple URLs before curly braces. Figure 1 shows the first implementation method.
- void decoration_remove (char _user_name[])
- {
- char realm [NAME_MAX];
- char user [NAME_MAX];
-
- sscanf (_user_name, "%[^{]", realm);
- sscanf (_user_name, "%*[^}]%s", user);
- sprintf (_user_name, "%s%s", realm, &user[1]);
- return 0;
- }
Figure 1 in this implementation method, the sscanf () function is used, and the regular expression is used in the function to separate the strings before and after curly braces. Finally, the sprintf () the function Concatenates the front and back strings of curly braces into the input parameter _ user_name. Although this implementation can achieve the goal, the author points out in reviewing this function implementation that its implementation is too complex. When the author puts forward this point of view, some people argue that such implementation has better flexibility.
In the author's opinion, the simplicity of the design is not only embodied in less code, but also contains the comprehensibility of concepts, as few knowledge points as possible, and higher program execution efficiency. The above design is simple on the number of lines of code, but it uses unnecessary Regular Expression knowledge, and the use of two sscanf () functions requires more processing time.
To understand whether an implementation is actually flexible, we need to ask ourselves, "What is the basis for adopting a flexible design ?"
Flexibility cannot all be based on self-perception. Instead, we need to find the demand to support flexibility. If the demand does not exist, it means that the so-called flexibility is very likely meaningless, it will even bring us more uncertainty in the future. In the previous implementation, the use of regular expressions cannot bring flexibility at all. If the format of the input string changes one day, we do not need to change the function implementation because regular expressions are used. Once the flexibility of implementation fails, instead we should pursue simplicity. Figure 2 illustrates another implementation.
- void decoration_remove (char _user_name[])
- {
- char *p_char = _user_name, *p_from, *p_to;
-
- while (*p_char != 0) {
- if (*p_char == '{') {
- p_from = p_char;
- }
- else if (*p_char == '}') {
- p_to = p_char ++;
- goto found;
- }
- p_char ++;
- }
- return;
-
- found:
- while (*p_to ++ != 0) {
- *p_from ++ = *p_to;
- }
- }
Figure 2 in the new implementation, it finds the parentheses by traversing the string, remove the content of the curly braces from the original string by moving the characters following the curly braces forward. This implementation is superior to the previous implementation in terms of time redundancy or space redundancy, and does not use regular expressions. Although the implementation of only one function is used as an example to explain the simplicity and flexibility, it seems that there is a big gap with the software design, but it does not affect our thinking simplicity and flexibility. Don't forget that software design will ultimately reflect the implementation of functions.
If flexible design brings simplicity, there will be no balance. But how can we choose between simplicity and flexibility when there is a trade-off between simplicity and flexibility? You can help with the selection by asking yourself a few questions:
1) is the basis for flexible design derived from existing needs? Many designers who adopt flexibility claim that "if it becomes ...... This design will be more flexible. "Such a statement often means that the existing requirements do not require such flexibility. In this case, if "that if" is not possible at all, it means that we do not need the so-called flexibility. However, when "if" is set, we have to ask the second question.
2) is the adoption of flexible design significantly different between the current and future workloads? If the current and future workload are not significantly different from those of flexible design, we should also choose simplicity. On the contrary, choose flexibility. Readers may expect that the focus of balancing simplicity and flexibility is to achieve simplicity as much as possible. In addition to being easier to understand and maintain, a design with simplicity also means that we are not overly designed. In the case of over-design, it may mean waste, or inadvertently create greater complexity. An outstanding design, unless the designer already has the same or similar experience, is difficult to achieve in one step. Do not believe that every flexible design of choice will allow us to build an outstanding software architecture. On the contrary, the author holds that high-quality design is created through gradual evolution of flexibility in the pursuit of simplicity, where demand is needed.
Flexibility design is a beautiful trap in many cases. To avoid this trap, we need to resist the temptation of "flexibility, the solution is to ask yourself the two questions mentioned above. In addition, we should not pursue unnecessary flexibility for the sake of "display". Solving Problems in a straightforward way is not the same as "not professional enough ".
This article from "to Jane Li cloud" blog, please be sure to keep this source http://yunli.blog.51cto.com/831344/475400
