Summary of reading code Daquan (second edition)

This time I read the famous "code Daquan" (second edition ). Although there are many chapters in the book, there are several major parts. I have some simple understanding but have not yet gone into depth. Of course, there are also some brand new experiences, such as the table-driven method. The book is rich and detailed. I have not read too many questions, but many of them feel that they are too simple to understand and need more practices and reading experience. Here we record some of my own experiences, mainly my different views and discussions on some of the arguments in the book, most of which are about object-oriented and structured design; and the learning experience of the new table-driven method.

 

Question 1:

In "7.1 justification for creating a subroutine", it is mentioned that creating a subroutine helps reduce complexity, improve performance, avoid code duplication, and improve readability. I have always had doubts about this argument. Create a function as an example. First of all, I think creating functions is similar to modular design, which increases the performance and complexity. When a function is called, stack operations are required to store input parameters, and the program context must be saved. I have been familiar with MIPS assembly programming. Based on my experience, when performing function switching in MIPS assembly, I need to save the values of multiple registers and perform stack operations, it is mainly manifested in storing values into the stack, saving the return address of the function, taking the returned address from the stack or other places once or after calculation, jump to the corresponding address. In MIPS assembly, the stored work can occupy dozens of lines at a time. If it is a large program, the modular design and code reuse principles are extensively applied, the overhead of these save jobs can be imagined, increasing complexity and performance. Second, if the number of stored contexts is too large, exceptions or errors may occur, increasing the burden on the program running. Furthermore, I think the importance of code reuse and readability improvement remains to be discussed. The so-called code reuse and readability are nothing more than to facilitate reading and maintenance. The writing of a series of functions added for this is neat and clear, but the running efficiency may not be higher. In other words, these are not necessary. Imagine if it was in the era of Ken Thompson, or decades ago when the computer memory was still in the Age of MB computing, and if such a large-scale function call and code reuse were performed, the impact on performance cannot be ignored. The Code Daquan even says that creating subprograms can reduce the complexity on the grounds that information can be hidden by creating subprograms so that you don't have to worry about them any more. This is undoubtedly self-deception. At best, writing subprograms to hide information details can improve the Abstraction Level, expose only interfaces, and reflect the encapsulation and abstraction ideas. However, since the code is still there, no matter whether or not to write a subroutine to hide information, the time complexity is so much. Writing a subroutine does not reduce the time complexity, not to mention the space complexity. If it refers to the complexity of the program, it is beyond review, but it is meaningless to improve the performance. Therefore, after I have been familiar with object-oriented modeling technology and the basic idea of Software Engineering Development, I think this series of norms are designed to help people write software in a more systematic and standardized manner, instead of improving the performance of the software.

Answer 1:

Most of the discussions about subprogram code reuse and function call overhead on the Internet are described as negligible function call overhead under the conditions of modern large-capacity and high-speed computers, the good program readability and maintainability seem to be more important. It is true that the object-oriented abstraction mechanism and encapsulation mechanism can make the program development layers more distinct, so that the program can be designed and developed first. encapsulation ensures the security of the program, avoid others from arbitrarily manipulating the member variables of the class. Code reuse seems useless to me, but it is indeed easy to modify. If repeated code is used in multiple places, once it needs to be modified, code reuse will be convenient, this is similar to the macro design philosophy. The subroutine design only exposes interfaces to users, and does not require users to care about internal implementation. It complies with the general principles of contemporary software development and use. Despite all these discussions, I still think that code reuse needs to be moderate. It doesn't make much sense to blindly split a function into many small functions. Maybe only in the development of software projects will I consider using code reuse to facilitate Pair programming, team programming, and program testing.

 

Question 2:

The use of global variables lists the advantages and disadvantages of global variables in the "Global Data" of the code, but it still does not mention the necessity of using global variables, and the design concept of the class itself ensures that the private variables of the class can be shared by all member methods of the class. It makes sense, but not all languages are object-oriented. Object-oriented languages, such as Java and C #, can indeed define private variables in the class, and then the class methods can share these variables, while implementing global variables (class global) and class encapsulation principles. However, it is difficult to implement this in the C language. After all, the structure closest to the object-oriented language cannot add access control characters to variables.

Answer 2:

In fact, for global variables, I have to lose money. When programming C language programs, implicit errors may occur due to the disorderly modification of global variables, which may not be easy to detect and consume a lot of debugging time. However, when writing a multi-layer recursive program at a time, instead of using global variables, the local variables of the function are used. This causes the function to exit nesting at a layer, which indicates that the value of the variable is not as I thought, and the program cannot be completed within the specified time. It should be said that in object-oriented languages such as Java, global variables are not necessary because of the encapsulation and comprehensiveness of classes. However, global variables are very important in C language, sometimes the use of global variables can greatly facilitate the use of data and the use of identifiers. If you do not use global variables, it is not easy to count the number of times the recursive function runs. Although the static variables of the function can solve the problem, because the recursive function calls itself recursively, static variables can play a certain role and use static variables. Because the scope is within the function, other function processes cannot affect the value of the static variables of the function, it is a good countermeasure. In addition, to solve the recursion problem, you can convert recursion to non-recursion, such as the use of dynamic planning algorithms. At the same time, it is also proposed in the Code Daquan that you can use locks to control access to global variables. Although resources are consumed, global variables can be well controlled to avoid data inconsistency.

 

Question 3 & Answer 3:

Encapsulation issues. This is also a commonplace. In fact, I don't think this question can be totally persuaded by the other party, so I will combine the question and answer. In code Daquan, the base of classes is ADT, and good encapsulation is called a necessary condition for abstraction. According to the book, either both encapsulation and abstraction are possible, or both are lost. The book also advocates avoiding the use of C ++'s youyuan class. I have never liked encapsulation since I started using object-oriented technology. Encapsulation ensures program security to a certain extent, but it greatly limits the freedom of programming. The so-called top masters of the industry undoubtedly put off the shackles of programming, especially the compilation of object-oriented languages, for the "authoritative judgment" of encapsulation, but in fact, ADT has already banned OO programs. The so-called restricted class members can be accessed and declared as private. Since it is an object-oriented program, there must be communication between objects, although loose coupling is not a bad thing. If all class members are declared as private, how can other classes access these class variables? If we use the class member method, will it actually destroy encapsulation? After all, the subroutine has not been declared as private. Until all the data and subprograms are declared as private, the outside world cannot Snoop any internal implementation details of the class, and other classes cannot communicate with the class, right? This is ridiculous to me. It greatly reduces the coupling between modules and adds a lot of trouble to program writing to avoid spying on internal details. When writing a program, for example, you need to view or change the value of a variable of a class, then the encapsulation principle cannot be accessed. Even if a public subroutine is provided to access the private variables of the class, imagine if the member method can access the private variables of the class, what is the significance of private variables? But then I saw in the code book that the book believes that, for example, a class has three float-type private variables X, Y, and Z, and the class encapsulates these three variables, then the get and set methods of the three variables are exposed, which does not undermine encapsulation, Because outsiders do not know what your internal details are, I don't know what variables are involved in the underlying implementation of your class. This solves the problem of communication between other classes and the class. Although the details are concealed, It seems ridiculous. A bunch of private variables actually define the set and get methods. I only think this is sad, although it seems that the data details are encapsulated externally.

 

Question 4 & Answer 4:

In the design and implementation of classes, combination and inheritance are often mentioned, especially inheritance, and even regarded as one of the three main characteristics of object-oriented. However, in my opinion, combination is much more convenient than inheritance. I do not know whether it is because I am not easy to learn. I have never understood the significance of inheritance, except for the use of polymorphism. Polymorphism is indeed a very useful and gorgeous technology. Here, let alone polymorphism to look at inheritance. In the past, when training an object-oriented modeling course, the instructor specified that an inheritance level must be established in the program, and all interfaces, abstract parent classes, or non-Abstract parent classes must be attempted. After my attempt, I felt that inheritance had even brought about a greater obstacle to programming than encapsulation. In other words, inheritance is not widely used, especially in less-large programs. Due to the encapsulation of classes and the loose coupling principle, the relationship between classes is not very close, and the combination can better utilize various types of resources. Of course, in large programs, such as a company's management system, there are various types of employees, and these employee classes can be inherited in a unified manner, which is a good example of code reuse. In this way, we cannot simply deny inheritance. I am deeply touched by a few words in the discussion of inheritance in code Daquan. The first sentence is "either use inheritance and describe it in detail, or do not use it ". . Before writing inheritance, you should consider whether there are enough child classes. The Sharing Relationship between them is worth writing a parent class to achieve code reuse, in many cases, it is unnecessary to create a parent class between two classes. At the same time, the book also makes sense to "avoid making the inheritance system too deep. Inheritance itself is a relatively advanced technology, which is prone to unexpected situations. The logic of multi-layer inheritance has been complicated to take multi-layer inheritance instances for analysis in university classes to clarify students' understanding of inheritance. Not to mention multi-level inheritance, multi-level inheritance is even more terrible, so that Java has canceled this c ++ feature. When a technology is easy to confuse, people need to use it with caution, or this technology should be discussed and considered by people.

 

Question 5 & Answer 5:

I was surprised at the table-driven method, because the long-term use of the IF else made me feel a little bored, and I saw the idea of the table-driven method, you can use the lookup table to complete the judgment of the logical part, which makes the logical judgment more structured. Of course, since tables are involved, data storage and query will become the biggest problem. If the query speed is fast, the storage structure must be more complex. For example, to make the query more convenient, you can store some other information while storing the data, which increases the space usage. In the Table-driven method, direct access to a table can be directly accessed just like a hash table. Although complex internal implementations are hidden, it is convenient for users to query and use, however, the storage issue is worth considering. Index access tables can reduce space usage to a certain extent, and create a large index table instead of a large primary query table to facilitate query and maintenance, which is similar to hash tables. To my surprise, I also raised a step-by-step access table in the Code Daquan, which further solved some problems that may occur when accessing the table by indexing. I have to say that these master ideas are clever. The step-by-step Access Table determines whether the data is valid by judging the specific range. This judgment scope is not just a point. In fact, I did not think of it. When evaluating the score level, tiered access is undoubtedly more effective than indexed access. Of course, in tiered access, lookup ranges do not necessarily follow the order, because the ranges are arranged in a certain order, binary Search can reduce the time complexity. As mentioned in the book, index access may not be able to implement tiered access, but requires non-consecutive key values for indexing. If it is a continuous value, you should still use tiered access.

Summary of reading code Daquan (second edition)