[Reading Notes-reconstruction and mode] Bad code taste ~

<Reconstruction and mode>:

Refactoring, that is, improving the existing code design, requires you to first know what kind of code needs to be improved.

The book shows 12 types of bad code:

 

1. Repeat code 2. method too long 3. conditional logic is too complex 4. basic Type infatuated 5. improper exposure 6. solution spread 7. similar Category 8. 9. class is too large 10 branch statement 11 combination explosion 12 weird solution.

Another bad taste list of code:

Type	Description
Duplicated code (Repeated code)	If you see the same program structure in more than one location, you can be sure: try to combine them into one, and the program will become better.
Long Method (Too long function)	All benefits of the "indirect layer"-interpretation, sharing, and selection capabilities are supported by small functions. We follow the principle that whenever we feel that we need to annotate something, we write the things to be explained into an independent function and use it (rather than the implementation method) name.
Large Class (Too large class)	Do not use a single class to do too many things. This is also the principle of "single responsibility" for objects.
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. The parameter columns of functions in object-oriented programs are usually much shorter than those in traditional programs.
Divergent change (Divergent changes)	If a class often changes in different directions for different reasons, divergent change appears.
Shotgun surgery (Elastic bullet modification)	If you encounter a change, you must make many small changes in many different classes. The bad taste you face is shotgun surgery.
Feature envy (Attachment complex)	A function is more interested in a class than in its own class. The most common focus of this kind of sentiment is data. Our principle is: to determine which class has the data most used by this function, and then put this function and that data together. The most fundamental principle is to put things that are always changing together. Efforts should be made to keep changes happening only in one place.
Data clumps (Data dashboard)	A good way to judge is to delete one of the numerous data items. In doing so, is other data meaningless? If they are no longer meaningful, this is a clear signal: You should create a new object for them. All classes will form a small society, and each class will play its value in it.
Primitive obsession (Basic type paranoid)	One of the greatest values of objects is that they blur (or even break) The boundaries between basic data and large classes.
Switch statements (Switch thrilling appearance)	Use less switch (or case) statements. The concept of polymorphism in the object-oriented model can provide an elegant solution.
Parallel inheritance hierarchies (Parallel inheritance system)	Every time you add a subclass to a class, you must also add a subclass to the other class. Then, PIH appears. The general strategy to eliminate this repeatability is to allow an inherited system instance to reference another inherited system instance.
Lazy class (Redundant)	If the income of a class is not worth its value, it should disappear.
Speculative generality (Talking about the future)	If the only user of a function or class is a test case, delete them together with the test case. However, if they are used to help test cases detect legitimate functions, they must be left with a knife.
Temporary Field (Confusing temporary field)	Sometimes you will see an object where an instance variable is set only for a specific situation. Such code is hard to understand, because you usually think that an object needs all its variables at all times. If a variable is not used, you can guess that the purpose of setting it will drive you crazy.
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 ......, This is the message chain. Generally, a better choice is: first observe what the final object obtained by the message chain is.
Middle man (Man-in-the-middle)	One of the basic features of an object is encapsulation-hiding its internal details from the external world. Encapsulation is often accompanied by delegation. However, do not over-use delegation.
Inappropriate intimacy (Relationship)	Sometimes you will see two classes that are too close and spend too much time exploring the private components of each other. The relationship between classes must be broken up. Inheritance often leads to excessive intimacy. If you think you should let the child live alone, please let him leave the inheritance system.
Alternative classes with different interfaces (Similar class)	Two functions do the same thing, but they have different signatures, so they must be retained.
Incomplete Library Class (Imperfect class libraries)	Database Class builders do not have the capabilities of crowdsourced security testing, so we cannot blame them for this. The trouble is that we cannot modify the class so that it can complete the work we want to complete. We need to find another solution to the problem.
Data class (Pure data)	Data class is like a child. It serves as a good starting point, but to make them participate in the work of the entire system as mature objects, they must take responsibility.
Refused bequest (Rejected gifts)	If the sub-classes reuse the superclass behavior (implementation), but do not want to support the superclass interface, the bad taste of refused bequest will become strong. We don't mind rejecting the implementation of super classes. However, if we refuse to inherit the superclass interface, we do not agree.
Comments (Too many comments)	Annotation is a good programming habit, but it is incorrect to mask bad code with annotations.