Four bad tastes of Code-translated from refactoring

Basic Type paranoid primitive obsession

Most programming environments have two types of data. The record type allows you to structure the data into a meaningful set. The basic type is the bricks you build. Record types always produce a certain amount of additional overhead. This may be a table in the database, or it is very embarrassing to create a table when you want them to exist for only one or two things.

What makes sense about objects is that they blur or even break the boundary between basic types and large classes. You can easily write small classes that cannot be different from the built-in types in the language. Java has basic types of numbers, but character and date are also basic types in other environments, and classes are used in Java.

New contacts are often reluctant to use small objects to deal with small tasks, such as mixed numbers and currency-based money, there are also special strings such as phone numbers and zip codes. You can use "replace data values with objects" for independent data values to move them out of the cave to the intermediate heated object world. If the data value is a type code that does not affect behavior, use "replace type code with Class ". If you have conditional statements that depend on these types of code, use "replace type code with subclass" or "replace type code with status/policy"

If you have a set of fields that should be put together, use the extraction class for processing. If you see these basic types in the parameter list, try to use "introduce parameter object ". If you find that you have selected data from the array, use "replace array with objects"

 

Switch statement

One of the most obvious features of object-oriented code is that it lacks switch statements. The problem with the switch statement lies in repeated code. You often find the same switch statement in different places in the program. If you add a clause, you must locate and modify all the switch statements. The concept of object-oriented polymorphism provides you with a more elegant way to handle this problem.

In most cases, you should consider polymorphism in the switch statement. The problem is where polymorphism occurs. Generally, switch statements are switched Based on the signature. You want a method or class to host the value of the signature. Therefore, we use the extraction method to extract switch statements and move them to the classes that require polymorphism. At that time, you need to decide whether to use "substitute signature with subclass" or "replace signature with status/policy ". When you build an inheritance structure, you can replace conditional statements with polymorphism.

If you only have a few words that affect a single method, and you don't expect them to change, then polymorphism will overdo it. In this case, it is a good choice to replace the parameter with a clear method. If a Condition Clause is null, you can try to introduce "null object ".

 

Parallel inheritance system parallel inheritance hierarchies

The parallel inheritance system is a special casual modification. In this case, each time you create a subclass for a class, you also need to create a subclass for another class. You can identify the bad taste of code because the prefix of the class in one system is identical to the other.

The general strategy for eliminating such duplication is to determine instances in one system to refer to instances in another system. If you use the move method and move field, the system will disappear in the reference class.

 

Lazy class

　　　　Every class you create will spend money to maintain and understand it. A class that is not enough to offset its cost should be eliminated. Generally, this may be the value of a class, but the reconstruction has shrunk it. Or it may be a class added according to the original plan, but the plan was not executed later. In both cases, you can remove these classes in decent ways. If there are not many child classes, try collapse hierarchy. Inline class should be used for almost useless Components