Refactoring notes-bad taste of code (UP)

In the introduction to refactoring, the definition of refactoring, why refactoring, and when to refactor are briefly introduced. I think you've got a better understanding of how refactoring works. But you probably don't know much about the bad taste in the code. The bad taste may be produced in the invisible, or it may be the result of lazy developers, or other factors may be caused. In any case, the bad taste in the code is not a benefit to the program, it can cause the program to rot and even go bad. For developers, it is really necessary to understand and familiarize themselves with these bad tastes and to understand the scenarios they produce. For the current program, find the bad taste, refactoring the code to eliminate bad taste, improve code quality, improve their level.

Let's get to know and learn about 11 of the 22 bad taste situations that are often present in development. Among them, the first four kinds of bad taste is unavoidable in most development process, and several kinds of bad taste will appear in the program frequently. We should discover their existence and eliminate them.

(1) Duplicate code

repetitive code is the most frequent occurrence of bad taste. If you see the same code in more than one place, you can be sure that the code will get better if you find ways to combine them. The simplest repetition code is "two functions of the same class have the same expression", this time can be extracted to extract the duplicate code, and then let these two locations are extracted from the piece of code.

Another common scenario is that the "two siblings of each sibling have the same expression", which simply extracts the methods from the two classes and pushes the extracted code into the superclass. If the code is just similar and not exactly the same, then it is necessary to separate the similar and the difference parts by the extraction method to form a single function. If some functions do the same thing with different algorithms, you can replace the rest with a clearer one.

(2) A function that is too long

Programmers are fond of short functions. objects that have short functions will live better and longer. People who are unfamiliar with object-oriented technology often feel that there are only an infinite list of delegates in the object program, and there is no computation at all. You will only know the value of these small functions after living together with such programs for several years.

The function should be actively decomposed to make the long function a number of short functions. This is generally followed by the principle that whenever you feel the need to annotate something with a comment, write what you need to say into a separate function and name it for its purpose. Don't be too troublesome. You can do this for a group of even a short line of code, even if the replacement function call action is longer than the function itself, as long as the function name can explain its purpose, do not hesitate to do so. The key is not the length of the function, but the semantic distance between what the function "does" and "How to do".

(3) Oversized classes

If you want to do too much with a single class, there are often too many instance variables in it. Once this happens, the duplicated code is followed.

Several variables can be refined together into a new class. When refining, you should select variables related to each other in the class and put them together. Typically, if several variables within a class have the same prefix or suffix, this means there is an opportunity to distill them into a component.

As with "Too many instance variables", if there is too much code within a class, it is the source of code duplication, confusion, and eventual death. The simplest solution is to eliminate the extra stuff inside the class. If there are five "hundred lines", and many of them are the same, then perhaps you can turn them into five "10-line functions" and 10 extracted "two-line functions".

(4) The parameter column is too long

When I first learned to program, it was probably all "passing all the things that a function needs in a parameter." This is understandable as well, since it is only possible to select global data, and global data is evil. Object technology tells us that if you don't have what you need, you can always call an object to you. With an object, you don't have to pass everything you need to the function as a parameter to it, just pass it enough to allow the function to get its own stuff.

Too long parameter columns are difficult to understand, too many parameters can cause inconsistencies, are not easy to use, and once more data is needed, you have to modify it. If you pass an object to a function, most of the modifications will not be necessary because it is likely that you will get more data with just one or two additional requests.

(5) Divergent variation

We want the software to be easily modified--after all, the software is supposed to be "soft". Once we need to change, we want to be able to jump to a point in the system and make changes only at that place. If you can't do this, you'll sniff out one of two closely related pungent flavors.

If a class often changes in different directions for different reasons, divergent changes occur. It mainly refers to "a class affected by a variety of changes." When you look at a class and say, "Well, if you add a new database, you have to modify these three functions, and if a new tool is present, you have to modify these four functions." "Then it might be better to divide the object into two, so that each object can be modified for just one change."

(6) Haze-style modification

If every encounter changes, you have to make many small changes in many different classes, and the bad taste you face is the haze-style modification. It mainly refers to "a change that causes multiple classes to be modified accordingly". If the code you need to modify is scattered around, it's not only hard to find them, it's easy to forget some important changes.

This situation can put all the required code into the same class. If there are no suitable classes to place the code at the moment, create one. An inline class can often be used to put a series of related behaviors into the same class.

(7) Attachment plot

It is well known that the whole point of object technology is that it is a technique of "wrapping data and manipulating it into data". There is a classic smell: functions are more interested in a class than they are in their class. In many cases, you can see that a function calls an almost half-dozen accessor from another object in order to calculate a value. The therapy is also obvious: move the function to another location and move to where it should go. ‘

Sometimes a function uses several classes of functionality, so where exactly should it be placed? The principle of processing is usually to determine which class has the most data to be used by this function, and then put this function and the data together.

(8) Data Mud Regiment

If I use the image of something to describe the data item, I think "child" is a good choice, data items like children, like to stay together in droves. You can often see the same three or four items in a number of places: the same fields in two classes, the same parameters in many function signatures. These data that are always tied together should really have their own objects.

In this case, you can find out where these data appear as fields, refine them into a separate object, and then turn your attention to the function signature and use the parameter object to lose weight. The direct benefit of this is that many parameter columns can be shortened to simplify function calls. A better way to judge this is to delete one of the many data. Does this other data lose its meaning? If they no longer make sense, this is a clear signal: a new object should be created for them.

(9) Basic type Paranoia

Most programming environments have two kinds of data: struct types allow you to organize your data into meaningful forms, and the basic types are building blocks that form the structure type. But keep in mind that structure always brings some extra overhead. They may represent tables in a database, and it can be cumbersome to create a struct type for just one or two things.

One of the great values of objects is that they blur or even break the boundaries between the basic data and the larger classes. If you have a set of fields that should always be put together, you can extract them as a separate class. If you see basic data in the parameter sequence, you can introduce a parameter object for processing. If you find yourself picking data from an array, you can use an object instead of an array for processing.

Switch thriller appearances

One of the more obvious characteristics of object-oriented programs is the use of switch statements less. Essentially, the problem with a switch statement is repetition. You often find that the same switch statements are scattered in different places. If you want to add a new case statement to it, you must find the switch statement you are using and modify them. The concept of polymorphism in object-oriented can bring elegant solutions to this.

Most of the time, when you see a switch statement, you should consider replacing it with polymorphism. The switch statement is often selected based on the type code, and you want the function or class associated with the type code, so you should refine the switch statement into a separate function and move it to the class that requires polymorphism.

(11) Parallel succession system

Parallel succession system is a special case of haze-type modification. In this case, whenever you add a subclass to a class, you must also add a subclass to the other 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 is sniffed out.

The general strategy for eliminating this repetition is to have an instance of an inheritance system refer to an instance of another inheritance system.

This article simply introduces the 22 kinds of code bad taste of 11, through the understanding of these bad taste, prompting us in the development process, constantly thinking about the bad taste in the code we write, once the bad taste, we should start refactoring, rather than watching the code slowly decay. If you can continue to complete the article, I think you will also insist on regular cleanup of bad taste in the code, improve the quality of the code, improve their level.

Refactoring notes-bad taste of code (UP)