Bad taste of code

Rebuild Chapter 3 Study Notes

We must cultivate our own judgment to determine when to refactor.

1.1 duplicate code (repeated Code )

If you see the sameProgramStructure, it would be better to combine them into one.

1.2 long method (long function)

Objects with short functions will have a relatively long life.

All the benefits of the indirect layer: Interpretation (readability), sharing (reusability), and selection (?).

Currently, the OO language basically solves the overhead produced by function calls.

"You should be more active in decomposition functions. We follow the principle that whenever we feel that we need to annotate something, we write the things to be explained into a function and use it (rather than the implementation method) name. We can do this for a group or even just one line of code (with complicated logic, hard to understand. Even if the replaced function call action is longer than the function itself, we should not hesitate to do so as long as the function name can explain its purpose. The key lies not in the length of the function, but in the semantic distance between "what" and "how. "

"How to determine which code to extract? A good trick is to look for comments. They usually point out the signal of "semantic distance between code usage and implementation techniques. If the code needs to be annotated to describe its purpose, you should consider refining this code into an independent function and naming it with annotations ."

Complex conditional and cyclic fluids are often signals of extraction.

1.3 large class (over-category)

If you want to use a single class to do too many things, too many instance variables will usually appear in it.

If the class has too much code, it is also an excellent breeding point for "code repetition, chaos, and death.

1.4 long parameter list (too long parameter list)

The program is hard to understand because of the excessive length.

1.5 divergent change (divergent change)

"A class is affected by multiple external changes", encapsulates these changes into a new class. That is, "Put things that are always changing together"

All corresponding modifications to a change in the outside world should only happen in a single class, And all content of this class should reflect this change. The general idea is to encapsulate changes. This is consistent with the idea of the design model.

1.6 shotgun surgery (modified in the pop-up mode)

Different from the divergent change, each change requires small modifications in multiple classes to respond to it. They are scattered in multiple places and are prone to errors.

The main idea here is to focus on changes.

A casual Modification refers to a change that triggers the modification of multiple classes. A casual change refers to a class that is affected by multiple external changes ".

In these two cases, through reconstruction, the "external changes" and "classes to be modified" are ideally in a one-to-one relationship.

1.7 feature envy (Attachment plot)

A function is more interested in data of other classes than the host class. That is, the data of other classes is highly dependent.

1.8 data clumps (data dashboard)

A Data dash refers to data that is always bound together.

A good method of evaluation: delete one of the many data items. Is other data meaningless as a result? If they no longer make sense: You should create a new object for them.

After a new object is created, you can move some operations to the object based on feature envy.

1.9 primitive obsession (basic type paranoid)

Create multiple small but flexible objects.

1.10 switch statements)

To use object-oriented programming, use less switch and case statements. Instead, replace it with polymorphism.

1.11 parallel inheritance hierarchies (parallel inheritance system)

Whenever you add a subclass to a class, you must add a subclass to the other class. Generally, these two classes have the same prefix.

1.12 lazy class (redundant class)

Class is redundant and has no value.

1.13 speculative generality (exaggerated)

This is often the result of over-design: the response to a change that does not happen.

1.14 temporary field (confusing temporary value range)

Variables are valid only in specific circumstances, but not all cases. In many cases, these value fields should not belong to this class, but should be separately extracted into new classes.

1.15 message chains (over-coupled message chains)

The user requests another object from one object, then asks another object from the backend, and then asks another object-the customer is closely coupled with the sailing structure of the search process.

1.16 middle man)

One of the basic features of an object is encapsulation-hiding implementation details from the external world-encapsulation is often accompanied by delegation. The excessive running of the delegate leads to the middle man.

1.17 inappropriate intimacy (intimacy)

The relationship between the two classes is too close. For example, it takes a lot of time to explore the private components of each other.

1.18 alternative classes with different interface (similar class)

The class names are different, but the functions are similar.

1.19 incomplete Library Class (imperfect program Class Library)

The basic library cannot meet the actual needs.

1.20 data class (pure data class)

They have some value domains and functions used to access (read/write) These Value domains, but nothing else.

1.21 refused bequest (rejected gifts)

Unlike the functions and data that inherit the parent class, subclass is often a mistake in the inheritance system.

If the child class reuse the behavior of the parent class but does not want to support the interface of the parent class, the bad taste of refused bequest will be very strong in this case.

1.22 comments (too many comments)

Note is actually a scent. In more cases, it is used as a deodorant: that is, the Code has a bad smell (poorly designed code), and then comment "deodorization ". At this time, we should refactor these bad-taste codes, and then you will find that the comments become redundant.

When you feel that you need to annotate, try refactoring first and try to make all comments redundant-the Code itself is self-Annotated.

Annotations can be used to describe "Why do something", "what do you plan to do something", and "uncertain regions" without recording "How to do it ".