"Refactoring – Improving the design of existing code" reading notes----code bad taste "3"

Saturday, appropriate to go out and relax, back to continue our restructuring of the topic. Today is a bad taste of "3", a lot of friends with my private messages, so that I put the bad taste out, and then out of the method. In fact, this is reasonable, many times, "found" far more important than "How to do". In terms of design patterns, Gof's design patterns are believed to have been known to many people. Specific design patterns should be how to achieve AH believe that a lot of people are back memorized, but the problem often lies in when you should use this design pattern. Refactoring is also the same, manipulation steps are dead, the key is to find out when to refactor. So, I decided to continue to have a bad taste, all the bad taste out of the way we learn. Okay, get to the point:

"8" Data clumps (Mud Regiment)

Data items like a child, like a bunch of pairs of stay in a piece, like StartPoint and endpoint, you can see similar users in many classes, and start,end this situation, in two classes have the same field, many functions have the same parameter, You can see the same three or four data in many places, but for these coupled data, you really should give them an object of their own, which has several benefits:

1) Reuse, yes, the magic of object-oriented is reuse, when we bind these data items together to form an object, we don't need to emphasize their coupling relationship in different places, we just need to simply declare one of their objects.

2) Let them have their own behavior, let these data items have their own objects and you also give them the ability to own their own behavior. For example, for StartPoint and endpoint, if you declare an object of their own rangepoint, you can increase their own behavior, such as findpoint--to detect whether the point is between their two points. You do not need to repeat the implementation of this method in the different places where they appear, and you can actually reuse it in a meaningful way.

3) Simplify the list of parameters, once they have been bound to an object, you can shorten the argument list of their previous function, you pull them off to another object by extract class, use introduce Parameter object or preserve Whole object to shorten the length of their argument list. Simplify the function call, even if you refine the new class to use only his part of the field in the function you do not mind too, as long as a new object can replace two or more fields you earn.

A useful way to do this is to delete one of these data items, and then see if the remaining data items have no meaning if they are separated from it. If it doesn't make sense, then your refactoring opportunities are really coming. Reducing the number of fields and parameters can remove some bad taste, but more importantly, you can see if there is a feature Envy by refining the new class, which can help you to point out the behaviors that can be transferred to the new class, so that all the small classes have their own behavior, You can make the original host class more humble, and make the division between classes and classes clearer.

"9" Primitive obsession (basic type Paranoia)

Like C + + and other languages, there are two kinds of data, one is the basic type of atomic level, such as int,double, and so on, one is a class type composed of these custom types, such as Qstring,qlineedit, and so on, the people who started to learn the face object, including me, Often, most of the time, you are reluctant to object to a few small functions that need to be refined on small tasks. For example, values and currencies we would not like to go to create a money class, asked on the StartPoint and endpoint we do not want to build a Rangepoint class and so on. You can use Replace Data value with object to replace a previously separate value with an object, entering the world of objects, with so many benefits mentioned above. If the data value you want to replace is a type code, and it does not affect the behavior , you can use replace type code with class to refactor. If the type code participates in the relevant conditional expression, you can use replace type code with subclass or replace type code with State/strategy. You can use extract Class if you have a data mud group that is always in the same place as the 8th. If you see the basic type data in the argument list, you can try introduce Parameter object, and if you find that you are picking data from an array, try replace array with Object.

"10" switch statements (switch horror appearances)

The author uses "Thriller" to describe the Swtich statement, indeed, there is no need to have swtich in object-oriented, polymorphism gives more elegant solution than Swtich. The Swtich statement itself represents repetition, and you need to write this long string of Swtich when you need to make a type judgment, and when you want to add new types you need to look for all these swtich, which is very difficult to maintain. Most of the time, when you see a swtich statement, you should consider using polymorphism to solve it gracefully. The question is, where is this polymorphic supposed to appear? Swtich statements are often related to type codes, and all you have to do is look for functions or classes related to these type codes. The Extract method should be used to extract the Swtich statement into a separate function, and then use the Move method to move it to the class that needs polymorphism. Next you need to consider whether to use replace type code wtih subclass or replace type code with State/strategy. Once this inheritance structure is complete, you can use the Replace condiional with polymorphism to gracefully resolve it.

Of course, some students will say I only in a very small function need to make a choice to do swtich judgment, then you need to do the measurement, these types of code will not be used all the time, this string of Swtich code will not appear in other places, if you are sure not, so many states do not need. You can use replace Parameter with Explicit methods to refactor this time. If one of your choices is NULL, you can use introduce null object to replace if judgment and gracefully resolve.

"11" Parallel Inheritance hierarchies (parallel succession system)

Parallel inheritance hierarchies is actually a special case of shotgun surgery. This means that when you add a subclass to a class, you must add subclasses to other classes at the same time. There is a simple way to judge that when you find that the inheritance system prefix of a class is identical to the one of the other inheritance system, you can smell the bad taste.

The general strategy for solving this approach is to let an instance of an inheritance system refer to an instance of another inheritance system. Then, using the Move method and move Fiield to the referenced end, you can completely break down the inheritance system of the reference end, and make it a single inheritance system.

"12" Lazy class (redundant Class)

Although the object-oriented world gives us the charm of the object, it is not the more the class the better. Although joining an indirect layer can bring a variety of conveniences, all classes are needed to be understood and maintained by people. For classes that don't really work, or because some refactoring causes it to be worthless, or when developers plan some classes to deal with changes in advance, they don't actually happen. For any of these reasons, let this class disappear, reducing your workload while reducing the workload of others, as it is likely that the person who will maintain the code in the future is your own . If the subclass does not do enough work, you can use collapse hierarchy to break the inheritance system, and for almost useless components, you can use the inline class to deal with them.

"Refactoring – Improving the design of existing code" reading notes----code bad taste "3"