LinuxAid.com.cn 01-06-13 15:53 330P
Axing
We come to raise some examples, focus on how to convert other cohesive transitions to success in cohesiveness. Of course, it is just out of the study of the research, and it is meaningless to distinguish every subroutine is meaningless in practice. In the design of the designed subroutine, we must fully consider how to write a child program better, which is how to do function. Melo, the following is an example of several cohesiveness, wherein both are good, there is a decomposition: a functional cohesive example. For example, a subroutine that calculates an employee and give birthday is a functional cohesive because it completes a job, and it is complete. Example of sequential cohesiveness. Suppose there is a subroutine that calculates the age of employee, retirement time, if it is used to determine the time of the employee to retire, then it has sequential cohesiveness. And if it is calculated by age and retirement, but uses the same birthday data, it only has communication cohesiveness. It is better to determine which bad cohesiveness exists, it is better to determine how it is better to design it. How to make this subroutine become functional cohesiveness? Two subroutines can be established separately, one according to the birthday calculation age, another determination of retirement time according to the birthday, determine the procedure for the retirement time, which, which is functional cohesive, and other subroutines You can also call any of the subroutines, or these two units. An example of communication cohesiveness. For example, there is a print summary report and reinitialize the subroutine of the summary data after completion, this subroutine has communication cohesive, because the two operations are only used to use the same data. As with the preceding example, we consider how the focus is how to turn it into functional cohesiveness, and summarize data should be reinituted nearby, and should not be reinituted in the print subroutine. Divide this subroutine into two separate subroutines. The first print report, the second, reinitializes the data near the code generated or changed. Then, use a higher level subroutine instead of the original communication-related subroutine, this subroutine will call the previous two subprograms. Example of logical cohesiveness. A subroutine will print quarterly spending reports, monthly spending reports and daily spending reports. Specific printing which one will be determined by the incoming control flag, which is logical cohesive because its internal logic is determined by the external control flag of the input. Obviously, this subroutine is not based on only one job and makes it good. How to make this subroutine into functional cohesiveness? Establish three subroutines: a print quarterly report, a print month report, a print day report, improve the original subroutine, let it call one of these three subroutines based on the transfer to control flag. The call subroutine will only call the code without its own calculation code, thereby having functions of functional cohesiveness. And three calling procedures are also obviously functional cohesive. Coincidentally, this subroutine that is only responsible to calling other subroutines is also a transaction center. It is best to name the word "dispatch" or "control" such as DispatchReporPrinting () to indicate that it is only responsible for command temperature adjustment, and it does not work anything. Another example of logical cohesivity. Consider a subroutine responsible for printing a spending report, entering a new employee name, and backing up the database, the specific execution content will be controlled by the incoming control flag. This subroutine has only logical cohesive, although this association looks not logical. To make it a functional cohesiveness, you can divide it into several parts by pressing. However, these operations are somewhat more messy. Therefore, it is best to re-establish a code that calls each subroutine. The reorganization of calling code is easier when you have several subroutines that need to be called. Example of process cohesiveness.
Assume that there is a subroutine that generates the name of the employee, then the address, and finally its phone number. This order is important, just because it is in line with the user's request, the user wants screen input in this order. Another subroutine will read other information about employees. This subroutine is process cohesiveness because it is combined with a particular order instead of any other reason. As before, the answer to how to turn it into functional cohesiveness is divided into several parts, and put these parts separately in the program. To ensure that the function of the recurring subroutine is single, perfect. The calling subroutine should be a subroutine such as getEmployeedata () without a subroutine like getFirstPartofemPloyeedata (). You may also change the subroutine of the rest of the data. In order to obtain functional cohesiveness, it is normal to change several subprograms. At the same time, there are programs for functional and temporary cohesive. Consider a subroutine with completion of a thing to handle all processes, read a confirmation information from the user, and store a record to the data, clear the data field, and add 1 to the counter. This program is functional cohesive because it is only working in a job, it is handled, but it is more precisely that this subroutine is also temporary cohesive, but when a subroutine has two or more Time, generally only considering the strongest cohesiveness. This example presents how to use a name just abstract to describe the program content. For example, this subroutine can be called confirmiffAdJustData (), indicating that this dry program only has accidental cohesiveness. And if it is called CompleteTransction (), it may clearly indicate that this subroutine has only one function and has functional cohesiveness. Process, temporary or possible logical cohesive. For example, one of the top five operations in a complex calculation and returns the intermediate result to the calling subroutine. Since the 5 operations may be used for hours, this subroutine will store the intermediate result in a file when the system is paralyzed, and then this subroutine checks the disk to determine if it has sufficient space to store the final calculation result. And return the disk status and intermediate results to the calling program. This subroutine is probably the process cohesive, but you may also think it has temporary cohesiveness and even logical cohesiveness. However, don't forget the key to the problem is not to argue which is a bad cohesiveness, but how to improve its cohesiveness. The original subroutine is made up of a series of inexplicable operations, and is far from the functional cohesiveness. First, the calling subroutine should not call one, but should call several independent subroutines: L) for the top 5 Step-calculated subroutine; 2) Store intermediate results into a file; 3) Determine the available disk storage. If the tapping subroutine is called computeExtRavageTnumber (), then it should not write the intermediate result to a file, which should never check the remaining space of the disk, which is limited to calculation of some numbers. Careful redesign of this subroutine will have at least a subroutine at one to two hierarchies. For this top task, see Figure 5-L. Figure 5-1 performs task decomposition to obtain functional cohesive examples
