Restructuring Reading Notes (4)-Chapter 3 bad taste of code

Chapter 3 bad taste of code

In a sense, understanding "When should be restructured" and "when to stop refactoring" is more important than "Know How To refactor!

In this chapter, the author tries to explain "the timing and occasion of refactoring" through a metaphor such as "bad taste of code ". No one can give a precise measurement of when to refactor. Understanding and understanding this standard requires our intuition. This is also related to the actual situation of the project, such as quality requirements, expected service life, and security requirements. Therefore, we must cultivate our own judgment and learn to determine how many instance variables in a class are too large, and how many lines of code in a function are too long.

1. Duplicated code (repeated code )*****

Code duplication is the source of all evil.

If two unrelated classes have repeated code, you should consider using a refining function to extract the repeated code into an independent class, and then use the new class in another class. However, the function where the repeated code is located may indeed belong to only one class, the other class should only call it, or the function may belong to the third class, the other two classes should reference the third class. You must decide where the function is to be placed, and make sure that it will not appear anywhere else after it is placed. At this time, please forget the idea that you can put it anywhere!

2. Long method (long function )**

Generally, a function is too long and does not cause any serious problems. If a function is running many unrelated tasks, this is a manifestation of "not single responsibility". We need to use a refined function to reconstruct it, allows the code in the function to collaborate at the same task level.

If the function has a single responsibility, but the code is too long, consider using the replace method with method object method to refactor it. We often do this and get good results.

The function is too long to understand. In fact, you can always make it short.

3. Large Class (large class )****

Too many instance variables. Separated.

1) Sometimes the class does not use all instance variables at all times. In this case, we should refine the class or refine the subclass for reconstruction.

2) If the class contains too much code, it usually means that the code is repeated. At this time, you can also use the refining class and refining subclass to reconstruct it.

3) if the large class is a GUI class, data and behavior can be separated into an independent class. You can use the repeated observation data method for reconstruction.

4. long parameter list (too long parameter column )**

Most of the things required by a function can be found in the host class of the function. Furthermore, it is not very difficult to process the "too long parameter columns.

5. Divergent change (divergent change )***

A class is affected by various changes. Reconstruction goal: Meet the single responsibility principle.

6. Shotgun surgery (elastic bullet changes )***

A change will cause modifications to multiple classes.

7. Feature envy (Attachment )****

A function is more interested in a class than in its own class.

8. Data clumps (data dashboard )****

The concept is represented by a class.

9. Primitive obsession (basic type paranoid )****

The concept is represented by a class.

10. Switch statements (switch shocking appearance )*****

Polymorphism is the natural killer of switch statements.

11. Parallel inheritance hierarchies (parallel inheritance system )****

Another type of repetition. Let the instance of one inheritance system reference the instance of another inheritance system.

12. Lazy class )****

Redundant classes are just like redundant code and must be removed decisively.

13. Speculative generality (coming soon )***

Don't tell others, "what if I want to use it ?".

14. Temporary Field (confusing temporary field )****

1) Sometimes you will see an object where an instance variable is set only for a specific situation. When a variable is not used, it is crazy to guess its original purpose. In this case, you can use the refining class to create a new home for this poor orphan and put all the variables and Code related to it into this new home.

2) there is another situation that can easily lead to this bad taste: a complex algorithm in the class requires several variables. To avoid too long parameter columns, these variables are often used as member fields of the class. However, these fields are valid only when the algorithm is used. At this time, we need to use the refining class to extract these variables and related functions into an independent class.

In my code, such bad taste often exists.

15. Message chains (over-coupled message chains )**

Hide proxy and add man-in-the-middle.

16. middle man (man in the middle )**

In most cases, we think that delegation is better than inheritance, but not all.

17. Inappropriate intimacy ()***

The two classes are too close and spend too much time exploring the private parts of each other.

18. Alternative classes with different interfaces (similar class )***

Refine the super class (base class ).

19. Incomplete Library Class (imperfect Library Class)

Add additional functions to introduce local extensions. This is not so much a refactoring technique as a coding technique.

20. Data class (naive data class)

If a class only has no data, it may be a child at first, but it needs to be reconstructed to help him grow up-he should assume the responsibility he should bear.

21. Refused bequest (rejected gifts)

Generally, delegation takes precedence over inheritance.

22. Comments (too many comments)

When you feel that you need to write comments, try refactoring first and try to make all comments redundant. That is, we should try to write "self-explanatory code ". There are two purposes for the annotation: one is to describe future plans, and the other is to record "Why do things ".