Bad taste of code [4]
Total returned directory
14. Temporary Field (confusing Temporary Field)
1. An instance variable is set only for a specific situation
2. Some instance fields are set only for complex algorithms with less parameter passing.
Extract these variables and related functions into an independent class.
15. Message Chains (over-coupled Message Chains)
If you see that the user requests another object from one object, then the latter requests another object, and then requests another object ...... This is the message chain.
The actual code is a long string of getThis () or a long string of temporary variables.
Use hidden "delegate relationships" (as described later) for refactoring. Of course, it can be used anywhere in the message chain.
16th. Middle Man (Man in the Middle)
Excessive use of delegation.
1. if half of the functions of a class interface are delegated to other classes, you should "Remove the intermediary": Ask the customer to directly call the delegate class.
2. If there are only a few functions, call them directly.
3. If there are other actions in the intermediary, replace the delegate with inheritance, and let the delegate class inherit the delegate class.
17. Inappropriate Intimacy ()
The two classes must be separated if they are too close.
1. You can extract a class and extract the two into this class.
2. You can remove unnecessary associations between classes.
3. Change inheritance to delegate and remove sub-classes from the inheritance system
18. Alternative Classes with Different Interfaces (similar class)
The two functions do the same thing, but the signatures are different. Merge the two functions and rename them based on their purposes.
19. Incomplete Library Class (imperfect Class Library)
Class Library functions are not well constructed and cannot be modified.
1. If you only want to modify one or two functions of the class, you can introduce additional functions.
2. If you want to add a large number of additional behaviors, create a new class to include these additional behaviors and make them subclass.
20. Data Class (pure Data Class)
The so-called Data Class: the Class has only some fields and functions that access these fields.
1. encapsulate a public field
2. encapsulate a collection field
3. Remove the set Method for fields that cannot be modified.
21. Refused Bequest (rejected gifts)
The derived class only uses a few member functions of the base class.
If the subclass reuse the behavior (implementation) of the parent class but does not want to support the interface of the base class, use delegate instead of inheritance.
22. Comments (too many Comments)
This is often the case where a piece of code has long comments that exist because the code is shit.
At this time, we can first find all kinds of "bad taste" and then reconstruct it.
When you feel that you need to write comments, try refactoring first and try to make all comments redundant.
I remember one sentence: the highest level of annotation-code is annotation.
Of course, this does not mean that we should not write comments. Only comments need to be written to the correct location.
Summary
All the "bad taste" here is over. We usually pay attention to these bad tastes when writing code.
"If the diaper stinks, replace it ". This statement also applies to our code.
The series of articles "Bad taste of code" mainly understand and familiarize ourselves with 22 common bad tastes, so that we can analyze and think about programs on a regular basis during the development process, find a place where bad taste has been scattered and refactor it properly to make the code more "beautiful ".
In subsequent articles, I will introduce a series of refactoring techniques to eliminate these bad tastes.
To Be Continued...