Refactoring-Replace the comparison of several types of code (Replace type code ...)

There are some specific refactoring methods for Type encoding in refactoring. There are three methods: Class, subclass, and status/policy mode. Here we analyze and compare them.

Description: The type code is a constant or variable. Generally, there are multiple possible values. If you do not understand this, let's take a look at the following.

First, use classes to eliminate type code. This type of code generally has A defined constant value, such as blood type (A, B, O, etc.), but the specific class behavior will not be different because of the different encoding values, that is to say, these codes only reflect the information of a class. However, you can also set and query these types. When they exist as parameters, we may provide the defined alias (const int A = 0;) as parameters, however, the compiler may still follow the numerical value (# define 0 A) or prompt the variable name at most, but we may not know the source of the error, if A separate class is used to encapsulate these values as static members of the class, A complete name is provided for use. For example: BloodGroup:, this is better to understand than A single A. In addition, if the compiler reports an error, it will also locate the BloodGroup class. In short, I think this refactoring method is to increase the readability of the Code, remember the appropriate condition: does not affect the behavior of the class.

The second type is the type code that affects the behavior of the class. For example, the following code:

If (a = 1)...; else if ....

Switch (I) {case 1:; case 2 :;...}

As you can see, the type code in this case has brought different behaviors to our class, and we also find that the value of the type encoding does not change during running, at this time, a major feature of object-oriented polymorphism is helpful. We create a subclass for this class, and set the method used for encoding of this type as a virtual method, which implements different implementations in the subclass. There is a problem here, that is, condition judgment will exist somewhere, but there are multiple advantages of sub-classes: First, it conforms to the object-oriented idea, and second, we only need to judge the condition in one place, if this is not the case, we may need to judge the condition everywhere. Finally, the modification to the subclass does not affect the behavior of other subclasses.

Well, if the type code has an impact on the behavior of the class and its status changes during the lifetime, you should use the third method: status or policy mode, these two models clearly indicate that they are dedicated to dealing with multi-condition and state changes. At this time, the original object has a member. This object is a pointer or reference pointing to a subclass. This pointer is variable at runtime, in this way, the type of the original object is not changed to meet the requirements. For example, employees have many levels and different levels have different behaviors, while their levels can be changed. We use the level as an employee's attribute. By changing the level to different levels of sub-classes, we can change the employee's identity and Behavior needs. In fact, after restructuring by status/policy mode, you can also perform multi-State reconstruction by alignment.

In addition, a query table must be created to prevent the switch from generating different subclass names. The type encoding query is provided to obtain the name of the generated subclass, finally, this subclass object is generated based on the Type name (I know JAVA can implement it), which ensures more flexible code, but there is always a need for a corresponding place, but it is better than matching in the code.

Okay. Here is a brief introduction.