Refactoring note-the bad taste of the Code (on), restructuring the taste of the note code

Refactoring note-the bad taste of the Code (on), restructuring 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/42041757

In the refactoring entry, I briefly introduced the definition, why, and when to refactor the refactoring. I think you have a good understanding of how refactoring works. But you may not know much about the bad taste in the code. The bad taste may be invisible, the developer may be lazy, or it may be caused by other factors. In any case, the bad taste in the Code is not very good for the program, it will lead to program decay, or even deterioration. It is really necessary for developers to understand and understand these bad tastes and their scenarios. Find the bad taste of the current program and refactor the code to eliminate the bad taste, improve the code quality, and improve your own level.

Let's take a look at 11 of the 22 bad taste situations that often occur during development. Among them, the first four bad tastes are inevitable in most development processes; the latter several bad tastes also often appear in the program. We should discover and eliminate them.

(1) duplicate code

Repeated code is the case where the most frequently-occurring bad taste is not the same. If you see the same code in more than one place, you can be sure: to combine them into one, the code will become better. The simplest duplicate code is "two functions of the same class contain the same expression". At this time, we can extract the duplicate code using the extraction method, then let the two locations call the extracted code.

Another common case is that "two sibling child classes contain the same expression." At this time, you only need to extract the two classes and then push the extracted code into the superclass. If the code is similar but not completely the same, the similarity and difference must be separated by the extraction method to form a separate function. If some functions do the same thing using different algorithms, you can replace the rest with a clear one.

(2) too long Functions

Programmers like short functions. Objects with short functions will be better and longer-lived. People who are not familiar with object-oriented technology often feel that the object program has only an infinite number of delegates and does not perform any computing at all. After living with such programs for a few years, you will know the value of these small functions.

We should actively break down functions and turn long functions into multiple short functions. This principle is generally followed: whenever you feel that you need to annotate something, write the things to be explained into an independent function and name it for its purpose. Do not be too troublesome. You can do this for a group or even just one line of code, even if the replaced function call action is longer than the function itself, as long as the function name can explain its purpose, you should not hesitate to do so. The key lies not in the length of the function, but in the semantic distance between the function "what" and "how.

(3) Too large class

If you want to use a single class to do too many things, too many instance variables will usually appear in it. Once so, repeated code will come one after another.

Several variables can be extracted to the new class. When refining, you should select variables related to each other in the class and put them together. Generally, if several variables in the class have the same prefix or suffix, this means they have the opportunity to be extracted into a component.

Like "too many instance variables", if there are too many code in the class, it is also the source of code repetition, chaos, and eventually death. The simplest solution is to remove unnecessary items from the class. If there are five "Hundred-line functions", many of them have the same code, maybe you can convert them into five "Ten-row functions" and ten "double-row functions ".

(4) too long parameter Columns

At the beginning of learning programming, it may be "passing everything required by the function with Parameters ". This is understandable, because we can only select global data, and global data is evil. Object Technology tells us that if you don't have anything you need, you can always call an object to you. With an object, you do not need to pass all the things required by the function to it as parameters. You just need to pass it enough to allow the function to obtain its own things.

Too long parameter columns are hard to understand. Too many parameters may cause inconsistency and difficulty in use. Once more data is needed, you have to modify them. If you pass an object to a function, most modifications are unnecessary, because it is very likely that you only need to add one or two requests to get more data.

(5) divergent changes

We hope that the software can be easily modified-after all, the software should have been "soft. Once the modification is required, we hope to jump to a certain point in the system and only make the modification here. If you cannot do this, you will find one of the two closely related pungent flavors.

If a class often changes in different directions for different reasons, the variant occurs. It mainly refers to "a class is affected by various changes ". When you look at a class and say, "Well, if you add a new database, you must modify these three functions. If a new tool is available, you must modify these four functions ." At this time, it may be better to divide this object into two parts, so that each object can be modified because of a change.

(6) Haze bullet Modification

If every change happens, you must make many small changes in many different classes. The bad taste you face is the haze-style modification. It mainly refers to "one change causes multiple classes to modify accordingly ". If the code to be modified is distributed around, it is not only difficult to find them, but also easy to forget an important modification.

In this case, all the required code can be put into the same class. If there is no suitable class to place the code, create one. You can usually use inline classes to put a series of related behaviors into the same class.

(7) Attachment plot

As we all know, the main point of object technology is that it is a technology that encapsulates data and data operations. There is a classic smell: a function is more interested in a class than in its own class. In many cases, we can see that a function calls almost half a dozen value functions from another object to calculate a value. The therapy is also obvious: Move this function to another location, where it should go. '

Sometimes a function often uses several classes. Where should it be placed? The processing principle is usually: To determine which class has the data most used by this function, and then put this function and that data together.

(8) data dashboard

If we describe data items in a more visual way, I think "children" is a good choice. data items are like children who like to stay together in groups. Three or four identical data items are often seen in many places: the same fields in two classes and the same parameters in many function signatures. The data that is always tied together should have their own objects.

In this case, you can first find out where the data appears in the form of fields, extract them into an independent object, and then focus on the function signature, and use the parameter object for it to lose weight. The direct advantage of this is that many parameter columns can be shortened to simplify function calls. A better method is to delete one of the many data items. Is other data meaningless? If they are no longer meaningful, this is a clear signal that a new object should be generated for them.

(9) Basic Type paranoia

In most programming environments, there are two types of data: the structure type allows you to organize the data into meaningful forms, and the basic type is the block that constitutes the structure type. However, please remember that the structure will always bring additional overhead. They may represent tables in the database. It may be difficult to create a structure type for only one or two tasks.

One of the greatest values of objects is that they blur or even break the boundaries between basic data and large classes. If you have a set of fields that should always be put together, you can extract them into an independent class. If you see basic data in the parameter column, you can introduce the parameter object for processing. If you find that you are selecting data from an array, you can use an object instead of an array for processing.

(10) thrilling appearance of Switch

One obvious feature of object-oriented programs is that switch statements are rarely used. Essentially, the problem with switch statements lies in repetition. You often find that the same switch statement is scattered in different places. If you want to add a new case statement for it, you must find and modify the switch statements used. The concept of polymorphism in the object-oriented model can provide an elegant solution.

Most of the time, when you see the switch statement, you should consider replacing it with polymorphism. Switch statements are often selected based on the type code. You need "functions or classes related to the type code". Therefore, you should extract the switch statement into an independent function, move it to the class that requires polymorphism.

(11) Parallel Inheritance System

The parallel inheritance system is actually a special case of the haze-style modification. In this case, each time a subclass is added to a class, a subclass must also be added to another class. If you find that the class name prefix of an inheritance system is exactly the same as the class name prefix of another inheritance system, this bad taste will be sniffed out.

The general strategy to eliminate this repeatability is to allow an inherited system instance to reference another inherited system instance.

This article briefly introduces 11 bad tastes of 22 types of code. Through understanding these bad tastes, We are prompted to regularly think about whether there is a bad taste in the code we write during the development process, once the bad taste is found, we should start refactoring, rather than watching the code slowly rot. If you can finish reading this article, I think you will also insist on regular cleaning of bad taste in the code to improve the quality of the code and improve your own level.

I hope this article will help you. If you have any questions, you can discuss them together.