分解条件表达式Decompose Conditional Expression
image.png
- 动机：复杂的条件逻辑导致复杂度的上升。必须编写代码来检查不同的条件分支，根据不同的条件做不同的事，然后，很快就会得到一个相当长的函数。大型函数本书就会使代码的可读性下降，而条件逻辑则会使代码更难阅读。
- 做法：对条件判断和每个条件分支分别运用提炼函数手法。
合并条件表达式 Consolidate Conditional Expression
image.png
- 动机：有时我会发现这样一串条件检查：检查条件各不相同，最终行为却一致。如果发现这种情况，就应该使用逻辑与逻辑或将它们合并为一个条件表达式。“实际上只有一次条件检查，只不过有多个并列条件需要检查而已”。而如果有多个条件，每个条件检查后的结果不一样，就不能合并而需要拆分了。
以卫语句取代嵌套条件表达式Replace Nested Conditional with Guard Clauses
image.png
image.png
- 卫语句：在多个条件表达式中，如果某个条件及其罕见，就应该单独检查该条件，并在该条件为真时立刻从函数中返回。这样的单独检查常常被称为“卫语句”。
- 动机：卫语句表示给某一条分支以特别的重视，如果它真的发生了，需要做一些必要的工作，然后退出。if else语句对分支的重视是相等的。
以多态取代条件表达式Replace Conditional with Polymorphism
image.png
- 动机：复杂的条件逻辑是编程中最难理解的东西之一，很多时候，我发现可以将条件逻辑拆分到不同的场景，从而拆解复杂的条件逻辑。这种拆分有时用条件逻辑本身的结构就足以表达，但使用类和多态能把逻辑的拆分表述的更清晰。
- 这里强调的是复杂逻辑，在实际开发中，通常简单的ifelse 或switch就能解决大部分逻辑。
引入特例Introduce Special Case
image.png
- 动机：一种常见的重复代码是这种情况：一个数据结构的使用者都在检查某个特殊的值，并且当这个特殊值出现时所作的处理也都相同。如果我发现代码库中有多处以同样方式应对同一个特殊值，我就会想到把这个处理逻辑收拢到一处。
- 做法：使用“特例”模式：创建一个特例元素，用以表达对这种特例的共用行为的处理。这样我就可以用一个函数调用取代大部分特例检查逻辑。
- 特例有几种表现形式。如果我只需要从这个对象读取数据，可以提供一个字面量对象，其中所有的值都是预先填充好的。如果还需要更多行为，就需要创建一个特殊对象，其中包括所有共用行为所对应的函数。特例对象可以由一个封装类来返回。
引入断言Introduce Assertion
image.png
- 如果你发现代码假设某个条件始终为真，就加入一个断言明确说明这种情况。
Replace Control Flag with Break
image.png
- 动机
