Refactoring notes-bad taste of code (bottom)

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

In the refactoring note-the bad taste of the code (above) describes 11 of the 22 bad flavors, this article will introduce the remaining 11 bad flavors. The reason why it is divided into two articles, is because an article introduced 22 methods appear too long, worried that the reader is difficult to adhere to the reading. PS: After understanding and familiarity with the "bad taste" of these "codes", we start to target refactoring, but before refactoring, we seem to be missing something. Yes, we still lack a test environment. In the process of development, most programmers may neglect to build a test system, but it is not easy to write good test procedures, can greatly improve the programmer's programming speed, and ensure that the program is relatively "stable" and "reliable." In the next article will be introduced: Build test system, improve programming speed.

The remaining 11 bad flavors are shown below. (If you want to persist and learn refactoring, hopefully you will be able to read this article patiently)

(12) Redundant class

Every class you create requires someone to understand it and maintain it, all of which cost money. If the income of a class is not worth it, he should disappear. This is often the case in a project where a class is inherently worthy of its own, but the refactoring makes it shrink and doesn't do much work, or the developer plans some changes in advance and adds a class to cope with the changes, but the changes don't actually happen.

Whatever the reason, let this class be solemnly justified. If some subclasses do not do enough work, we can try to "collapse the inheritance system", combining the superclass and subclasses together, which will reduce maintenance time. For those components that are almost useless, you should move all the attributes of the class to another class, and then remove the original class.

(13) Rhetoric of the future

We often say, "I think I need to do this one day" and thus try to deal with unnecessary things with hooks and special circumstances. Once that happens, the bad taste emerges. The result of the rhetoric of the future often makes the system more difficult to understand and maintain. If all the devices are used, it is worth it, and if not, it is not worth it. A device that can't be used will only block your way and give you trouble, so move it away.

If an abstract class does not actually have much effect, you can combine the superclass and subclasses together. Transfer unnecessary delegates to another class, and eliminate the original class. If some parameters of the function are not used, then the parameters are removed. If the function name has an extra abstract meaning, it should be renamed to make it realistic.

(14) Confusing temporary fields

Sometimes you will find that an instance variable in a class is set only for a particular case. This code is hard to understand because you usually think that the object needs all of its variables at all times. When a variable is not being used, it will make you mad to guess what it was set up for.

You can use the refining new class to create a home for this poor orphan, and then put all the code associated with that variable into the new home.

You might also use the Replace null value with a null object to create a null object if the variable is not valid, thereby avoiding writing out the conditional code.

(15) Over-coupled message chains

If you see the user requesting another object from one object and then requesting another object from the other, then request another object .... This is the message chain. This means that the customer code will be tightly coupled with the navigation structure in some function functions. Once the relationship between objects changes, the client has to make corresponding changes.

At this point we can hide the "delegate relationship" and build all the functions required by the client on the service class. You can do this refactoring at different points in the message chain. In theory, you can refactor any object on a message chain, but doing so tends to turn a series of objects into "middlemen." Usually a better choice is to look at what the final object of the message chain is for, and see if you can extract the code that uses the object into a separate function by extracting it, and then push the function into the message chain.

(16) Intermediaries

We all know that one of the basic features of an object is encapsulation--hiding its internal details from the outside world. Encapsulation is often accompanied by a delegate. For example, if you tell boss if you have time to attend a meeting, he will "entrust" the message to his notepad before you can answer it. However, you don't need to know whether bosses use traditional notebooks or electronic notebooks or secretaries to record their appointments.

People may overuse delegates. You might see that half of the functions in a class interface are delegated to other classes, which is excessive delegation. It is time to remove the middleman and deal directly with the real person in charge. If there are only a few of these "do-not-do" functions, you can put them in the call side. If the middleman has other behaviors, you can turn it into a subclass of the responsible object, so that you can extend the behavior of the original object without having to bear so many delegate actions.

(17) Contempt relationship

Sometimes you see two classes that are too close and spend too much time exploring each other's private components. If this happens between the two "people", we are the Guardian priests, but for the class, we want them to be strictly their symbolisms.

Perhaps like the ancient lovers, the excessively contempt class must be torn apart. They can be cut off by "move methods" and "move fields" to reduce contempt behavior. If two classes are really in the same spot, you can refine the similarities to a safe place and let them use the new class in a magnanimous way. or let the other class pass on the love for them by hiding the "delegate relationship."

(18) Similar classes

If two functions do the same thing, they have different signatures and can be renamed according to their purpose.

This is often not enough, however, that you can repeatedly move certain behaviors into a class until the protocols agree.

(19) Imperfect Library class

Reuse is often considered the ultimate purpose of an object. But we think the meaning of reuse is often overestimated--most of the objects are just enough. However, there is no denying that many programming techniques are built on the basis of the library. Library class Builders do not have the ability to foresight, and we cannot blame them for this.

Fortunately, we have two tools to deal with this situation. If you want to modify only the one or two functions of the library class, you can use the "introduce additional parameters" to modify them. If you want to add a lot of extra behavior, you have to use "introduce local extensions (create a new class so that it contains these extra functions.) Make this extension a subclass or wrapper class for the source Class) "to modify.

(20) Childlike data classes

Childlike data classes are those that have fields and functions to access (read and write) These fields, in addition to Shipe. Such a class is simply a data container that does not speak, and is almost certain to be manipulated by other classes over trivial.

These classes may have public fields early, and if so, they should be encapsulated before others notice them. If these classes contain the fields of the container class, you should check that they are properly encapsulated, and if not, wrap them up. For fields that should not be modified by other classes, you should remove all the set-valued functions for that field.

(21) rejected bequest

Subclasses should inherit the functions and data of the superclass. But what if they don't want or need to inherit? They get all the gifts, but only choose a few to play.

This could mean an inheritance system design error. You need to create a new sibling class for this subclass, and then push all the unused functions down to the brother. In this way, the superclass holds only what is shared by all subclasses. You will often hear the suggestion that all hyper-classes should be abstract.

(22) Too many comments

Don't worry, it's not that you shouldn't write notes. In the sense of smell, the note is not a bad taste, in fact it is still a fragrance. Often, you see a piece of code with a long comment, and then find out that the comments exist because the code sucks. The number of occurrences of this situation is surprising.

Comments can lead us to find the various bad smells mentioned earlier in this article. After finding the bad taste, we should first remove the bad taste with various refactoring techniques. When we're done, we find that the annotations have become redundant because the code clearly illustrates everything.

If you need a comment to explain what a piece of code is doing, try extracting the code as a separate function, and if the function has been refined, but still needs a comment to explain its behavior, try renaming it. When you feel the need to write comments, try refactoring first, and try to make all comments redundant.

The two articles related to the "bad taste of code" are mainly about understanding and familiarity with the 22 common bad flavours, so that we can constantly analyze and think about the process during development, look for places where the bad taste has been dispersed and refactor them appropriately, making the code more "beautiful". In the following article, we will introduce the various reconstruction techniques caused by the bad taste in detail. Each of these techniques will correspond to an article, each of which will describe the removal of bad taste, and will give you some simple examples to illustrate, so that you can learn and understand more clearly.

I hope this article will be of some help to you. There are problems that can be discussed and communicated.

before refactoring the notes, the article reads as follows:

Refactoring Notes-Introductory article

Refactoring notes-bad taste of code (UP)