Mind Mapping
Click on the image below to view the larger image.
Conditional logic can be very complex, so this chapter provides some refactoring techniques that are designed to simplify them.
Full Text brief (you can skip the following content directly)
Core refactoring: Decompose conditional--separates "switch Logic" (switching logic) and "Operation Details" (detail).
Multiple tests have the same result: Consolidate Conditional expresssion
Remove the duplicate component from the conditional code: Consolidate Duplicate
Identification Special case: Replace Nested Conditional with Guard clauses
Get rid of nasty control Tags: remove controls Flag
Decompose: Decomposition, separation
Eligible: Suitable, qualified
Fragment: Fragments, fragments
Polymorphism: polymorphic
Unchecked exception: non-controllable anomalies
condition: You have a complex condition (if-else if-else) statement, then
extract the function from the IF, else if, or else three paragraphs respectively.
Consolidate Conditional Expression
condition: You have some condition tests that all get the same results, then
combine the tests into a conditional and refine the condition to be called a separate function.
motivation: 1, the merged conditional code will tell you that "there is actually only one condition check, but there are several parallel conditions that need to be examined"--to make the purpose of the inspection clearer.
2, prepare for Extract method. -Refining the check condition into a separate function is useful for working out the meaning of the code. It replaces the statement "What to do" with the words "why do It".
The "reason for merging" of conditional statements also points to the reason for "Do not merge": if you think that your checks are truly independent and should not be considered the same check, then do not use this refactoring. Because in this case, your code has clearly expressed its meaning.
Consolidate Duplicate Conditional fragments
Status: If you have the same piece of code on each branch of the conditional,
move the repeating code outside the condition.
Status: in a series of Boolean expressions, a variable has the function of "control tag", then
a break statement or RETURN statement replaces the control tag.
Replace Nested Conditional with Guard clauses
Condition: The conditional logic in a function makes it difficult to see the normal execution path, so
use the Guardian statement (Guard clauses) to represent all the special cases.
The two forms of the conditional type are:
1, all branches are normal behavior: use [if ... else ...]
2. The condition is extremely rare: The condition should be checked separately and returned immediately from the function when the condition is true. --Such separate checks are often referred to as "guardian statements"
Replace Nested Conditional with Guard clauses essence: give particular attention to a branch.
Replace Conditional with polymorphism
condition: You have an expression in your hand that chooses different behavior depending on the type of object, then
place each branch of the conditional in a subclass function within a single, and then declare the original function as an abstract function.
Bad taste of this code:
1, it is too long, when the video has a new type, it will become longer.
2, it has obviously done more than one thing.
3, it violates the principle of sole responsibility, because it has several reasons to modify it.
4, it violates the open closure principle, because whenever you add a new type, you must modify it. But perhaps the most troubling is the function of a similar structure (_get type name rank ()) everywhere.
condition: A piece of code needs to make some kind of assumption about the state of the program, so the
assertion (assertion) clearly manifests the assumption.
Mining point:
1, there will often be such code, only when a condition is true, the code can run normally. In fact, the final product of the program will often remove assertion.
2, this assumption is usually not clearly shown in the code, you have to read the entire algorithm to see. -Sometimes programmers write these assumptions in annotations, and assetion is a better technique.
3, assertion is a conditional type, should always be true. If it fails, it means that
the programmer has made a mistake .
4, assertion can be used as the auxiliary of
communication and debugging . --Communication: can help programmers read the assumptions made by the code. Debugging: Helps programmers find bugs, and can catch bugs in the nearest place.
5,
assertion does not change the procedure of any behavior.
6,
assertion value: To help programmers understand the correct operation of the code requirements.
7. It is advisable to use Extract method for assertion conditional type, in order to refine the duplicate code of several places into the same function, perhaps just to clarify the use of the conditional type.
This chapter I prefer "Replace Nested Conditional with Guard clauses" This way, I usually in the code is also often used in this way, and some people give this method named "Guardian clause".
There is another one that I often use in the PHP development of debugging is Var_dump () or Print_r (), I also first found in PHP and assert this way, good!
In the process of learning and practice, I also learned a lot of good ways. But I think in the team development, sometimes the "big picture", according to the team's customary way to code, or you can communicate with the team, get everyone's approval, in the use of this method, so that everyone debugging and reading each other's code more convenient.
