Refactoring note-the bad taste of the Code (below), refactoring the taste of the note code

Refactoring note-the bad taste of the Code (below), refactoring the taste of the note code

This article is in the study of the summary, welcome to reprint but please note the Source: http://blog.csdn.net/pistolove/article/details/42083495

In the refactoring note-the bad taste of the Code (I), 11 of the 22 bad tastes are introduced. This article will introduce the remaining 11 bad tastes. The reason why I divided it into two articles is that the 22 methods described in one article are too long to be read by readers. (PS: After understanding and familiarizing ourselves with the "bad taste" of these codes, we will start to refactor them in a targeted manner. But before restructuring, we seem to have something missing! By the way, we still lack a test environment! During the development process, most programmers may ignore the construction of a test system. However, writing excellent test programs can greatly improve the programming speed of programmers, and ensure that the program is relatively "stable" and "reliable ". In the next article, we will introduce how to build a testing system and improve programming speed ).

The remaining 11 bad tastes are as follows. (If you want to stick to and learn refactoring, I hope you can read this article with patience; if you don't want to, please turn off the web page; otherwise, it is a waste of your time ).

(12) Redundancy

Every class you create has to be understood and maintained by someone, and these jobs are all costly. If the income of a class is not worth its value, it should disappear. This often occurs in projects: a class is originally worthy of its own value, but restructuring makes it shrink and does not do so much work; or developers plan some changes in advance, and add a class to cope with these changes, but the changes did not actually happen.

Whatever the reason, we should make this class solemn. If some sub-classes do not do enough work, we can try to "fold the inheritance system" and combine the superclass and sub-classes as one, which will reduce the maintenance time. For components that are almost useless, you should move all the features of this class to another class and then remove the original class.

(13) talking about future

We often say, "I want to do this one day," and try to handle unnecessary things with various hooks and special circumstances. Once this happens, the bad taste will pop up. Talking about future results often makes the system more difficult to understand and maintain. If all devices are used, it is worth doing so; if not, it is not worth doing. An unusable device will only block your path and disrupt you. Let's move it away.

If an abstract class does not have much function, you can combine the superclass and subclasses. Transfers unnecessary delegates to another class and removes the original class. If some parameters of the function are not used, the parameter is removed. If the function name has redundant abstraction meanings, you should rename it to make it more realistic.

(14) confusing temporary Fields

Sometimes you will find that an instance variable in the class is only set for a specific situation. Such code is hard to understand, because you usually think that an object needs all its variables at all times. When a variable is not used, it will drive you crazy to guess its purpose.

You can use the new classes to create a home for this poor orphan and then put all the Code related to this variable into this new home.

You can also use "replace Null with Null Object" to create a Null object when "variable is invalid" to avoid writing conditional code.

(15) 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. This means that the customer code will be closely coupled with the navigation structure in some functional functions. Once the relationship between objects changes, the client must modify the relationship accordingly.

In this case, we can hide the "delegate relationship" and create all functions required by the customer in the service class. You can reconstruct a message chain in different locations. Theoretically, any object on the message chain can be reconstructed. However, in this way, a series of objects are often changed to "man-in-the-middle ". Generally, a better choice is: first observe what the final object obtained by the message chain is for, and then see whether the code using this object can be extracted into an independent function through the extraction method, then, push the function into the message chain.

(16) intermediary

We all know that one of the basic features of an object is encapsulation-hiding its internal details from the external world. Encapsulation is often accompanied by delegation. For example, if you tell the Boss whether you have time to attend a meeting, he "delegates" The message to his notebook before answering you. However, you do not need to know whether the Boss uses a traditional notepad, an electronic notepad, or a secretary to record your appointment.

People may use delegation excessively. You may see that half of the functions in a class interface are delegated to other classes, which means excessive delegation. At this time, we should remove the intermediary and directly deal with the real owner. If there are only a few functions that are "not practical", you can put them into the caller. If there are other actions in the intermediary, you can turn it into a subclass of the actual responsibility object. In this way, you can expand the behavior of the original object without having to bear so many delegate actions.

(17) relationship

Sometimes you will see two classes that are too close and spend too much time exploring the private components of each other. If this happens between two "people", we will be a guard, but for classes, we want them to strictly abide by the rules.

Maybe, just like an ancient lover, the category of excessive friends must be broken up. You can use the "Move method" and "move field" to draw a line between them, thus reducing the number of friends. If the two classes are really keen on fit, you can extract the two in common to a safe place for them to use the new class openly. Alternatively, you can hide the "delegate relationship" to allow another class to share their thoughts.

(18) similar classes

If two functions do the same thing but have different signatures, You can rename them based on their purposes.

But this is often not enough. You can move some behaviors into the class repeatedly until the two protocols are consistent.

(19) imperfect database classes

Reuse is often regarded as the ultimate goal of objects. However, we think that the meaning of reuse is often overestimated-most objects only need to be enough. However, it is undeniable that many programming technologies are built on libraries. Database builders do not have the capabilities of crowdsourced security testing, so we cannot blame them for this.

Fortunately, we have two tools dedicated to this situation. If you only want to modify one or two functions of the library class, you can use "introduce additional parameters" to modify them. If you want to add a large number of additional actions, you have to use "introduce local extensions (create a new class to include these additional functions. Let this extension be a subclass or package class of the source class) to modify.

(20) pure data

Pure data classes refer to the fields they own and functions used to access (read/write) these fields. Such classes are just a data container that does not speak, and they are almost controlled by other classes excessively.

These classes may have public fields early on, so they should be encapsulated before others notice them. If these classes contain the fields of the container class, check whether they are properly encapsulated. If not, encapsulate them. For fields that should not be modified by other classes, all set-value functions of the field should be removed.

(21) rejected gifts

Subclass should inherit the functions and data of superclasses. But what if they do not want to or do not need inheritance? They get all the gifts, but only a few of them are available!

This may mean that the inheritance system is incorrectly designed. You need to create a new sibling class for this subclass, and then push all unused functions to that sibling class. In this way, the superclass only hold things shared by all sub-classes. You often hear the suggestion that all super classes should be abstract.

(22) Too many comments

Don't worry. It doesn't mean you should not write comments. In terms of smell, annotation is not a bad taste. In fact, it is still a scent. There is often a situation where you see a piece of code with long comments and find that these comments exist because the code is very bad. It is surprising that this situation occurs frequently.

Annotations can show us the various bad tastes mentioned earlier in this article. After finding the bad taste, we should first remove the bad taste with a variety of reconstruction methods. After the annotations are completed, we find that the comments have become redundant because the Code has clearly explained everything.

If you need annotations to explain what a piece of code has done, try to extract the code into a separate function. If the function has been extracted, but you still need annotations to explain its behavior, try to rename it. When you feel that you need to write comments, try refactoring first and try to make all comments redundant.

The two articles related to "bad taste of code" are mainly about understanding and familiarizing ourselves with 22 common bad tastes, so as to encourage us in the development process, the ability to analyze and think about programs on a regular basis, find places where bad tastes have been scattered, and properly refactor them to make the code more "beautiful ". In subsequent articles, we will introduce various refactoring techniques caused by bad taste in a more detailed manner. Each method corresponds to an article. Each article describes how to remove bad taste and describes some simple examples, this allows you to learn and understand more clearly.

I hope this article will help you. If you have any questions, you can discuss and communicate.