Software Architecture ———— Refactoring

Types of software Evolution

Software evolution is like biological evolution, some mutations are beneficial to species, and some are harmful.

The key to differentiate the type of software evolution is whether the quality of the program is increased or decreased in this process. The second is that this evolution is the result of the process of the construction of the show sea, or the maintenance process of modification.

Introduction to Refactoring

The most critical strategy to implement the basic principles of software evolution is refactoring.

Reasons for Refactoring

1, code duplication , repetitive code is almost representative of the original design of a thorough decomposition of a thing. Whenever you need to make a change to a place, you have to do it in another place--repetitive code will always put you in the awkward position of a two-line operation.

2, a lengthy subroutine , one of the improvement methods is to enhance its modularity.

3, the cycle is too long or nesting too deep

4, the cohesion is too poor class , if there is a class to write a lot of unrelated things, then this class should be split into multiple classes, each class is responsible for a set of internal interrelated tasks.

5. the interface of the class failed to provide a consistent level of abstraction .

6 . parameter list with too many parameters

7, the internal modification of the class is often limited to a certain part , the change causes the same modification of multiple classes, if the same group of classes are often found to modify, which indicates that the code in these classes should be re-organized, so that the modification only affects one of the classes.

8, the same changes to the inheritance system , each time for a class to add a derived class, you will find that you have to do the same thing to another class. This is a special kind of modification that should be avoided.

9, the relevant data used at the same time is not organized in a class way , if the same set of data are often manipulated, you should think about whether the data and its operations should be organized into a class.

10. The member function uses more features of other classes than it does with its own class , suggesting that the subroutine should be placed in another class central and then called in the original class.

11. excessive use of basic data types

12. A class is idle , and sometimes refactoring of code can cause an existing class to have nothing to do. If a class looks like a misnomer, you should consider whether to pass the functionality of the class to other classes and then completely delete the class.

13. a series of sub-procedures for transmitting data

14, the intermediary object can do nothing , if the majority of the code in a class just to call the member functions in other classes, consider whether to remove such an intermediary, instead of calling other classes directly.

15, some similar to other classes too close , if you need to make the program more manageable, and minimize the impact on the surrounding code, then (information hiding) is probably the most powerful tool.

16, Sub-program naming improper , as long as you see this problem should be modified immediately.

17, the data members are set to public , please seriously consider it is hidden behind the accessor subroutine.

18. a derived class uses only a very small subset of the member functions of the base class, which typically indicates that a derived class is created only because the base class happens to have a subroutine that the class needs, not a logical derivation. Therefore, a more complete encapsulation should be considered: to convert the derived class from "Is-a" to "has-a" in relation to the base class.

19. comments are used in difficult-to-understand code , do not write a document for poor code, you should rewrite the code.

20, the use of global variables

21, Some code in the program seems to be used sometime in the future , so the advanced design should try to avoid, unless the thought is very thoughtful (generally will not appear). The way to prepare for future needs is not to write castles in the castle, but to show the code that satisfies the current needs as clearly and plainly as possible, so that future programmers can understand the intent of the program.

Specific refactoring

Data-level refactoring

1, equipment name constants instead of mysterious values

2, is the variable name and add clarity to convey more information

3, the expression of the internal connection

4. Replace the expression with a function

5. Introduction of intermediate variables

6. Replace a multi-purpose variable with multiple single-use variables

7. Using local variables instead of parameters for local use

8. Transform the underlying type data into a class

9. Convert a set of type codes to class or enum type

10. Convert a set of type codes to a base class and their corresponding derived classes

11. Converting an array to an object

12. Package the cluster

13, the use of data classes to replace traditional records

Statement-level refactoring

1. Decomposition of Boolean expressions

2. Convert complex Boolean expressions into named and accurate Boolean functions

3. Duplicate code fragment of the non-pass part of the combined conditional statement

4. Use break or return instead of loop variable to exit

5, in the nested IF-ELSE statement once know the answer will return immediately, rather than to assign a return value

6, using polymorphism to replace conditional statements

7. Creating and using null objects instead of detecting null values

Sub-program-level refactoring

1. Extracting sub-programs or methods

2, the sub-program in the code to connect

3. Converting lengthy subroutines to classes

4. Replacing complex algorithms with simple algorithms

5. Adding parameters

6. Delete Parameters

7, separate the query operation from the modification operation

8. Merging similar subroutines, distinguishing their functions by parameters

9, the behavior depends on the parameters of the sub-program split apart

10. Pass the entire object rather than the attribute member

11. Passing attribute members rather than entire objects

12, packaging downward transformation of the operation

Refactoring of class implementations

1. Convert a Value object to a Reference object, if you are creating and maintaining multiple, identical, large complex objects, change the way objects are used, just keep one copy, and then refer to it elsewhere.

2. Convert the Reference object to a value object, and if you have made multiple references to a small, simple object, set these objects as value objects.

3. Replace virtual function with data initialization

4, change the position of member function or member data, move the data to the base class, move the child function into the base function

5. Extracting special code as a derived class

6. Combine similar code into a base class, and if two derived classes have similar code, combine the code and place it in the base class.

Refactoring of class interfaces

1. Place the member function in another class

2. Turn a class into two

3. Delete Class

4. Removal of the delegation relationship

5. Remove the Middleman

6. Replace inheritance with entrustment

7. Replace the delegate with inheritance

8. Introduction of external member functions

9. Introduction of Extension classes

10. Encapsulation of exposed member variables

11. For class members that cannot be modified, delete the associated set () member function

12. Hide member functions that are not used outside of the class

13. Package Not applicable member function

14. Merging the base classes and derived classes that implement very similar

System-Level refactoring

1. Create an explicit index source for data that cannot be controlled

2, want one-way of the class contact to the bidirectional class contact, if two classes, and they each need to use each other's function, but only one class can access another class. At this point, you should modify the two classes so that they can be called from one another.

3, the two-way contact is changed to one-way contact, if the two classes, each other know each other, but actually only one class needs to access another class, at this point you need this transformation.

4, replace the error handling code with an exception or the reverse direction of the transformation, which depends on the strategy of error handling.

Secure refactoring

Refactoring is a powerful technique for improving the quality of code, but using it improperly, refactoring can cause a lot of trouble. Here are some tips:

1, Save the initial code: To prevent the wrong change can not be restored

2, the pace of reconstruction should be smaller

3. Only one refactoring at a time

4. Make a list of things to do

5, set up a parking lot, during a refactoring process, you may find that another refactoring is required. While embarking on this new refactoring, acquiring and discovering a third refactoring will bring many benefits to the program. In order to deal with these unimportant and immediate modifications, it is advisable to set up a "parking lot" that lists the modifications that need to be made at some point in the future and can now be put aside.

6, multi-use restore point, at the time of refactoring, it is easy to show that the code does not follow the assumption of normal operation of the situation. In addition to saving the initial code, the restore point should be set in several places in the refactoring. This allows you to revert to a previously operational state if the changed program is not running.

7. Using Compiler warning message

8. Re-Test

9. Add Test Cases

10. Check the changes to the code

11. Adjust the reconstruction method according to the risk level of reconstruction

Refactoring policy

1. Refactoring when adding subroutines

2. Refactoring when adding classes

3, in the repair of defects in the time of reconstruction

4. Focus on Error-prone modules

5. Focus on highly complex modules

6, in the maintenance environment, improve the hands are processing the code

7. Define the boundaries between clean code and poor code, and then try to move the code across this boundary