Classmates who are familiar with the RAD development tool know that the procedures that "foreigners" "legacy" are a pain. Change these procedures is a painful. In the process of changing the procedure, some "prehistoric mistakes" were painful in pain. It is not good to have a small amount of money, and the taste of being wronged is not good. Therefore, the classmates are careful when they change the procedures, and the global variable is absolutely can't move. It is clear that the original function can meet the requirements, but still write a comparative insurance. Who knows how to change the timeline bomb?
So, the program is getting more complicated and more bloated. The development team leader has countermeasures, and each team is responsible for a few modules, time long, knowing the roots, dare to open the knife for yourself. But the personnel mobilize, and the employee leaves is inevitable, and a person is responsible for fixing several procedures. It is difficult to last. I don't talk about these, assuming that a classmate is responsible for a few modules in the company. What is the development of how he developed?
Therefore, in the final analysis, we must make the procedure easily understood, easy to be modified, is easy to expand, is the ultimate goal. Everything is difficult, start with yourself.
Let's take a look at it, what is the procedure of others, what is hampered in reading and revision?
1, global variable. global variable is a nasty thing. Suppose we have seen this now: Boolean; // Whether to show the price of the price, the style is good, the style is very good, with a note, prefix, the name is also good. But this variable is not a "master". If it is a document of the document: Treceiptinfo.displayInprice, we can understand, if it is the properties of the system parameter class: Tsysparams.Displayinprice, we understand, but now it It belongs to the entire program, so we don't know its exact scope.
Therefore, the issue brought by global variables is that it does not have exact meanings and often misunderstandings. It does not belong to an object and may be modified throughout the program.
2, the program code is distributed in different regions. Assuming that we now have a program code such as a function of modifying the order. According to our usual understanding, this is a very single function, it should be implemented: inspection user rights ↓ 效 效 用户 输入 输入 用户 Enter parameters for SQL ↓ ↓ ↓ 调 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 程序 If it is more than a longer, it should be divided into several processes, but by the same function, this can make us understand clearly. However, in our program, check the user permission is implemented in the control, the test user input may be in Query.BeforePost inside, SQL is written in the form file (which program will be processed for SQL For example, add procurement group permissions), Applyupdate is completed in the query.Afterpost event, and the first value of some fields may be in the Query.AFterInsert event, or may even in the Query.OnnewRecord event, or even in the database trigger do. In other words, we check this process, go to a variety of different places to see, change, it is really painful. Of course, if we have a function called UpdateOrder to invoke these procedures, then how much can help understand, but, and slow, this involves events, the event is called, query1afterpost is query1AFTERPOST, it is not called CommitQuery1 private way, So it is likely to contain other program code (in addition to applyupdate and commitdate), you changed it, it might buried a timed bomb. 3. Event traps Because the flowchart is not from the painting. Event driver, the interface-driven RAD method subverts our programming method. Remember when writing the DOS program, the program process is very simple, because it is a line, there is a loop, there is a conditional steering statement, so the program is clear and easy to understand, the code optimization is also easy. . In the Windows era, the RAD era is completely different. Suppose we design to modify the order of the order according to the idea of the DOS program. ↓ ↓ ↓ 用户 用户 用户 用户 号 号 号 号 号 号 表 表 ↓ ↓ 修 明 表 表 表 表 表 表 表 表 表 表 表 ↓ ↓ 程序 程序 修 修 修
But actually, this process is no way to construct. The order is there at the beginning, not you have already pressed the modification. The query condition input box is always there, not you have selected the query. You can move records in DBGRID, although you don't do it next. You can enter query conditions and then delete an order, although there is nothing related to these two actions. Usually we overchange the value of Amount in the onchange event in Qty and Price fields, now we know, this is one of the reason why the code is unclear. Because of this process, it should be done after the user has changed, but why don't we put it here? Oh, because this is not commensurate with the query control of the Query control. For the Query control, the value of the other field in the onchange event is recommended. Look, our program solves special problems, Query controls solve conventional issues. Query's event definition does not affect its own code specification, but affects the code specification of our program. (to be continued)
