Refactoring: Improving the design of existing code Note 2

Bad taste of the code:

1. Duplicated Method (repeat code)

(1) Two functions of the same class with the same expression with Extract Method (110)

(2) Two siblings of each sibling containing the same expression two classes use Extract method, and then push the into hyperspace class with pull up method (332)

Two siblings of each sibling containing similar expressions two classes are separated by Extract Method with similar and differential portions.

Use form template Method (345) to obtain a Template method design mode.

Different algorithms do the same thing, choose the clearer one, substitute algorithm (139) Replace the other

(3) The unrelated class methods are duplicated. One of these classes uses extract class, which abstracts the repeating code into a separate class and uses the new class in another class.

Or this code should be in one of the classes, not the new class, need to be judged.

2, long method (too long function)

All the benefits that the "indirect layer" can bring: the ability to interpret, the ability to share, and the ability to choose-all supported by small functions.

The longer the program, the harder it is to understand. The short function allows the code reader to often convert the context to see what the subroutine does, but the real key to the short function's easy comprehension is a good name. If you can give a good name to a function, the reader can understand the function by name, without having to look at what is written in it.

One rule to follow: whenever you feel the need to annotate something with a note, we write what we need to say in a separate function and name it for its purpose, not its implementation.

Even if the replacement function call is longer than the function itself, as long as the function name can explain its purpose, it is necessary to do--the key in the function "what" and "how to" the semantic distance between.

If there are a large number of arguments and temporary variables inside the function, the parameters passed to the new function will hinder your function refinement, resulting in almost no improvement in readability--you can use replace temp with Query (120) to eliminate temporary elements. 　　Introduce Parameter object (295) and Preserve Whole object (288) can make the long parameter columns more concise. 　　If there are still too many temporary variables and arguments, replace method with method object (135) "Replace methods with methods objects".　　　　How do you determine which piece of code to refine? Looking for a comment find a condition: decompose Conditional (238) Decomposition condition looking for loops: refining loops and their code into a function

3. Large class (Too Large)

If you want to do too much with a single class, there are often too many instance variables.

Several variables can be refined together into a new class. When refining, you should select variables related to each other in the class and put them together. For example, Depositamount and depositcurrency may be subordinate to the same class.

Typically, if several variables within a class have the same prefix or suffix, this means there is an opportunity to distill them into a component. If this component is suitable as a subclass, you will find that extract subclass is often relatively simple.

If there is too much code in the class, the simplest solution is to get things out of the class, like there are five "hundred lines", and many of them are the same, then perhaps you can turn them into five "10-line functions" and 10 extracted "two-line functions".

As with "having too many instance variables," a class can often be used for Extract class and Extract subclass if it has too much code. Here's a tip: first determine how the client uses them, and then refine an interface for each usage. This may help you see how to break down this class.

If your large class is a GUI class, you may need to move data and behavior to a separate domain object. You may need to keep some duplicate data on both sides and keep the two sides in sync. Duplicate

Observed Data (189)

4, Long Parameter list (too long parameter column)

Because too long parameter columns are difficult to understand, too many parameters can cause inconsistencies, are not easy to use, and once you need more data, you have to modify it. If you pass an object to a function, most of the modifications will not be necessary because you are likely to get more data by adding one or two fields within the incoming object.

If a request is made to an existing object to replace a parameter, then you should activate the refactoring method replace Parameter with Method (292). In this case, an "existing object" may be a field within the class to which the function belongs, or it may be another parameter. You can also use Preserve Whole object (288) to collect a bunch of data from the same object and replace them with that object. If some data lacks a reasonable object attribution, you can use introduce Parameter object (295) to create a "parametric object" for them.

5. Divergent change (Divergent)

If a class often changes in different directions for different reasons, the divergent change appears.

6, Shotgun surgery (shotgun modification)

If you have to make a lot of small changes in many different classes for every change, the bad taste you face is shotgun surgery.

7, Feature Envy (attachment complex)

One of the classic smells is that a function's interest in a class is higher than that of its own class.

8. Data clumps (MUD group)

You can often see the same three or four items in a number of places: the same fields in two classes, the same parameters in many function signatures. The data that is always tied together should really have objects that belong to them.

9. Primitive obseession (basic type Paranoia)

10. Switch statements (switch thriller)

One of the most obvious features of an object-oriented program is to use a switch statement sparingly. Essentially, the problem with the switch statement is repetition. You often find that the same switch statements are scattered across different locations.

11. Parallel Inhertance Hierarchies (parallel succession system)

Whenever you add a subclass to a class, you must also add a subclass to the other class, which is the bad taste.

12. Lazy Class (redundant)

If the income of a class is not worth it, it should disappear.

13, speculative generality (rhetoric of the future)

A device you can't use will only block your way, so move it away.

14. Temporary field (confusing temporary field)

Sometimes you see an object in which an instance variable is set only for a particular case. This code is difficult to understand because you usually think that the object needs all of its variables at all times.

15. Message Chains (over-coupled messaging chain)

If you see the user requesting another object from one object and then requesting another object from the other, then request another object .... This is the message chain.

16. Middle Man (Middleman)

People may overuse the delegate, and perhaps you will see that half of the functions of a class interface are delegated to other classes, which is excessive delegation.

17. Inappropriate intimacy (contempt relationship)

One class accesses a private member of another class too much

18, alternative Classes with Different Interfaces (similar class)

If two functions do the same thing, but have different function names, use the Rename method to rename them according to their purpose.

19. Incomplete Library class (imperfect libraries)

The Library class architect does not have the ability to foresight, so the library is often not well constructed, and it is often impossible for us to modify the class to make it do the work we want. There are two refactoring methods available: (1) If you want to modify only one or two functions of the library class, you can use introduce foreign method; (2) If you want to add a lot of extra behavior, you have to use introduce local extension.

20. Data Class (childlike)

The so-called data class means that they have fields and functions to access (read and write) such fields, in addition to Shipe. The Data class is like a child, and as a starting point it's good, but to get them involved in the whole system like a mature object, they have to take responsibility.

21. Refused bequest (rejected bequest)

Refused bequest refers to the subclasses inheriting the functions and data of the parent class, but the subclass chooses only a few to play and does not need to accept so many things from the parent class. As a traditional practice: you need to create a new sibling class for this subclass, and then use the push down method and the push down field to push all the functions and variables that are not available to that sibling. In this way, the superclass holds only what is shared by all subclasses. But the author does not recommend that you do this every time, this bad taste ten very light, not worth ignoring.

22, Comments (too many comments)

Comments can take us to find all the bad smells mentioned above. After finding the bad taste, we should first remove the bad taste with various refactoring techniques. When we do, we often find that the comments have become superfluous because the code has clearly explained everything.

If you don't know what to do, this is a good time to use annotations. In addition to describing future intentions, annotations can also be used to mark areas that you do not fully grasp. You can write down your own "Why do you do something" in the comments. This kind of information can help future creators, especially those who are forgetful.

Extract Method (110)

Pull up Method (332)

Form Template Method (345)

Substitute algorithm (139)

Replace Temp with Query (introduce) Parameter object (295) Preserve Whole Object (288)Replace method with Method object (135) "Replacing methods with methods objects"decompose Conditional (238) Decomposition conditions

Extract Interface (341)

Duplicate observed Data (189)

Refactoring: Improving the design of existing code Note 2