Restructuring Reading Notes (10) -- Chapter 10 simplifying function calls

Chapter 10 simplified function calls

1. Rename method p273

A good function name is more important than you think. It is not easy to create a "known and known" name for a function, and experience is required. To become a real programmer, the level of name is crucial, so you need to pay attention to it. If you are in a special field (strong professionalism), you can get help from professionals. Do not think that the name is just a trivial matter. It is not worth consulting professionals. A good name will greatly improve the quality of your programs.

"That's all about it." It's the demon's call, the path to chaos, and an extremely irresponsible attitude. Remember, your code is first written for humans, and then for computers.

2. Add parameter p275

Add parameter is a common refactoring technique. The motivation for using this refactoring is simple: you must modify a function, and the modified function requires information that is not available in the past. Therefore, you need to add a parameter to the function. But in general, a too long parameter column is a bad taste (Data clumps ). Therefore, before restructuring this project, we need to consider the following questions:

1) Are there any better options besides adding parameters?

2) Is it possible to get the required information through a function?

3) check if the existing parameters require introduce parameter object?

3. Remove parameter p277

There is nothing to say about this reconstruction. It is worth noting that many programmers are reluctant to remove unnecessary parameters. The reason is: they don't bring any problems, they keep it, and they won't be used in the future (bad taste of code: exaggerated about the future type ). This is also the devil's temptation. You must drive it out of your mind! Do not corrupt your code.

In addition, you must be careful when using this Refactoring for Polymorphism functions. In this case, another (or multiple) implementation of the multi-state function may use this parameter, so you do not need to remove it.

4. Separate the query function from the modification function (separate query from modifier) p279

This is a very important refactoring.

If a function returns an object's status value and modifies the object's status, this is a bad signal. We call it a function that has both returned values and side effects. There is a good programming rule:No function with returned values should have any side effects.

After this reconstruction, there are two other things worth noting:

1) if necessary, rename method is easier to understand.

2) After reconstruction, a large number of repeated code may appear in the query function and modification function. If necessary, use "substitute algorithm" to remove duplicate code. In addition, we will question the efficiency of the Code after reconstruction. In the old saying, the efficiency problem is a task in the performance optimization stage.

5. Make the function carry the parameter (parameterize method) p283

A parameterized function is a repeat code that is different from a single (or some) parameter and restructured by refining the function. Therefore, the main point of this refactoring is to find code with repetition based on "a small number of values can be regarded as parameters.

6. Replace parameters with explicit functions (replace parameter with explicit methods) p285

Replace parameter with explicit methods is the opposite of parameterize method.

This is a meaningful refactoring. After reconstruction, the interface can be clearer and easier to use-this is a very valuable code.

7. Keep the object intact (preserve whole object) p288

If you extract several values from an object and use them as parameters for a callback function call, you should pass the entire object instead.

The benefits of doing so are:

1) In case (?? Haha ??) In the future, the called function requires new data items, which can be obtained from this object, so you do not need to modify the function interface, the required information can be obtained directly from the parameter object.

2) preserve whole object can also improve code readability. Too long parameter columns are always difficult to use.

3) More importantly, if you implement a refactoring like preserve whole object, you may find that a function uses a large number of parameters from another object, so is there a problem where this function is stored? Consider using the move method to move the function to another class that is more suitable for its placement.

Of course, I often find that I am not willing to use this refactoring because

1) "passing the entire object will aggravate the dependency between objects ".

2) passing the entire object will make the interface look more blurred and add more call restrictions.

8. Replace parameter with methods (replace parameter with methods) p292

The object calls a function and passes the result as a parameter to another function. The function that accepts this parameter can also call the previous function. This item should be used for reconstruction, so that the parameter receiver can remove the parameter and directly call the previous function.

9. Introduce the parameter object (introduce parameter object) p295

Usage: some parameters always appear at the same time. Replace these parameters with an object. This item is used to process the bad taste of code, "Data clumps" and "long parameter list )".

Now, we can summarize the methods for shortening the reconstruction of parameter columns?

1). Keep the object complete (preserve whole object );

2). Replace parameters with functions (replace parameter with methods );

3). Introduce the parameter object (introduce parameter object ).

But to be honest, I think the bad taste of "too long parameter columns" is not particularly bad or unbearable. Therefore, I usually seldom use the above refactoring methods, because in my opinion, the above refactoring methods will lead to small problems such:

1). Keep the object intact (preserve whole object): This makes it difficult to call interfaces, and adds Association and coupling between classes.

2) Replace parameters with functions (replace parameter with methods): reduces the flexibility and independence of interfaces, making subsequent refactoring (such as moving interfaces) difficult.

3). Introduce the parameter object (introduce parameter object): it will lead to a pure data class bad taste.

Too long parameter columns do have the disadvantages of strong procedural code. In addition, in Object-Oriented Programming, most of the parameters required by a function can be found in its host class. If a function requires a lot of information that cannot be found in its host class, the bad taste of "feature envy" begins to emerge, in this case, consider moving method reconstruction.

10. Remove the setting method P300.

If a field in the class should be assigned a value when the object is created, and then it will not be changed, all the set-value functions of the field should be removed.

The code must be able to express your intent.If you provide a setting function for a field, this implies that the value of this field can be changed. If you do not want this field value to change after the object is created, do not provide it with a value function (if possible, declare this field as const ). In this way, your intention is clear and you can exclude the possibility of modifying its value.

Avoid calling functions such as "setxxx ()" In constructor. If necessary (for example, a certain operation is required or multiple constructor calls the same code ), you should also use "initializexxx ()" to better express your intent.

11. Hidden functions (hide method) p303

Minimize the visibility of all functions.Check as frequently as possible to reduce the visibility of a function. Public -- "protected --" private

We may feel that such a reconstruction is of little value, but it does not take much time, and it makes sense in the long term.

12. Replace the constructor with factory Method)

The most obvious motivation for replacing constructors with factory functions is to replace type codes with factory functions when using derived subclasses. In this case, the constructor should be declared as private.

In addition, factory functions are also the basis for changing a value object to a reference object.

13. encapsulate downcast)

In C ++, the upward Transformation (upcast) is secure; the downward Transformation (downcast) always means that the design is not elegant enough. When writing interfaces for the customer's code, we should try to encapsulate the transformation actions in the Local interface to avoid requiring the customer code to perform the transformation actions.

14. Replace the error code with exception)

Actively use assertions.

15. Replace the exception with test)

For some normal or corrected errors, use the Condition Statement for judgment and check. However, I found that we abused the "judgment check" function in many cases where we should have used assertions. I should have used assertions, but I used if () return; I need experience to use assertions just right!