Program structure
Author: lover_P
[preface]
Originally planned this time to make up the algorithm knowledge, write some text less. But today, suddenly, the program structure is sent, and this article cannot be written.
[text]
The so-called program structure refers to "Structured Programming", "Object-Oriented Programming", which is usually said. Usually, the most common program structure includes:
Non-structured program structured program is object-oriented
Of course, there are many program structures such as "component" programs and "aspect" programs, etc., these are what I don't know, it is inconvenient to say. Usually a non-structural procedure is mentioned, people will naturally think of assembly language procedures; at the same time, C language can also write some unstructured procedures. The structured procedures are much more, almost when the senior language is just appearing, all senior languages are structured, such as Fortran, Pascal, C, etc. As for the object-oriented program, I don't have to say it. Now the mountains are all-oriented to object-oriented sounds, and there are many programming languages, such as C (which is not pure object-oriented), Java, C #, etc.
What I think here is not the application of these languages, but the dialectical relationship between these program structures (and supporting their programming languages).
Non-structured procedures are none of today's multi-programmers, think this is a bad programming style. However, non-structural programming languages represented by assembly languages are the most direct expression of machine behavior, and these programs written in these languages can usually run on a specific platform at the highest efficiency. Of course, this also has the greatest risk and pay the greatest effort. However, non-structured procedures can also reflect the structured side. For example, almost all assembly languages provide language configuration such as Call / RET, Proc / Endp to support structured programs. Therefore, when writing programs for efficiency, we should use these language characteristics while pursuing efficiency, making the program more structured, which is important for code maintenance. Even if you work on a very low-level platform, the assembly language of the platform does not support Call / RET, we should also achieve structured purposes with a clear code by using jump instructions.
At the beginning of the structured programming language, people are deeply attracted. Indeed, the clear code intention, the clear program structure makes the programming is no longer a torment, and it is a gospel for code maintenance personnel. Therefore, structured program design ideas sweep people thinking with Thunder, and structured programming language is like rainfall. However, when everyone blindly pursues structured, I think we should make flexible thinking according to the scope of the problem. If we use structured programming language to use structured programming languages in order to pursue lower risks and higher maintenanceability, we should consider introducing unstructured ideas in structured procedures, such as using global variables to avoid function calls. Macro, use macro instead of function call to reduce call overhead, etc. Of course, these are very dangerous, requiring high language control capabilities to complete. Also, if we want our code to have a higher reusability, we can also consider introducing object-oriented ideas into structured programming, such as saving data by structures, etc., in a separate library A specific type of structural definition of specific operations, etc. Of course, this is also dangerous, we should not excessively simulate the object-oriented program structure in the structured program, otherwise it will be counterproductive, make the code become a mess, unable to readability.
Finally, the object-oriented swept is more than 20 years. It is currently the most advanced programming structure (other as "component", "aspect", etc. However, in which we can still find a non-faceted object. Typically, an object has only its public members and interface members are truly "object-oriented", which is equivalent to a small library, and there is no shortage of structuring programs and even non-structured procedures. For example, we usually use some private member functions (methods) to assist public members to complete specific tasks. Then, these members constitute a structured program in an object, sometimes, in order to efficiency, we implement some data as a private data member, as if the global variable in this small library is the same, this is mutual between private member functions When you call, you can reduce the actions of some of the parameters. This is not a non-structured thought. Together with Hu, it probably said that in a certain program structure, it is reflected in the structure of another or several procedures. In actual programming, we should flexibly select a program structure according to the problem to be solved, and flexibly use language characteristics to moderately reflect the idea of other structures to achieve efficiency and readability and maintain the most maintenanceability. Good balance. Of course, this is a trade-off process, but also requires a strong program writing ability. Still do a lot of exercise, especially paying attention to exercise flexibility.
