《重构》读书笔记（九）——第九章 简化条件表达式

 第九章 简化条件表达式

1、 分解条件表达式（Decompose Conditional）通常与提炼函数（Extract Method）一起使用。

      “编写短小的函数”。

2、合并条件表达式（Consolidate Conditional）

      合并条件表达式，使用Extract Method将条件表达式提炼成一个独立的函数，并为函数取一个意义清晰的名字，大部分情况下这都可以大大提高代码的可读性。

      当然，并非所有这种情况都得合并，如果你认为这些检查的确彼此独立，的确不应该被视为同一次检查，那么就不要合并！

3、合并重复的条件片段（Consolidate Duplicate Conditional Fragments）

      重复代码是万恶之源！

4、 移除控制标记（Remove Control Flag）P245

      在以前的结构化编程原则中，大家都提倡”每个子程序只能有一个入口和一个出口“。现代编程语言已经强迫我们”单一入口“，但是”单一出口“原则会使你加入讨厌的控制标记和难于阅读的代码结构。

5、以卫语句取代嵌套的条件表达式（Replace Nested Conditional With Guard Clauses）P250

      使用卫语句的时候，经常在卫语句内返回一个明确值，因为这样我们可以一目了然地看到卫语句返回的失败结果。

6、以多态取代条件表达式（Replace Conditional With Polymorphism）

      在面向对象术语中，听上去最高贵的词非“多态（Polymorphism）”莫属。你手上有一个条件表达式，它根据对象类型的不同而选择不同的行为。这时应该用“以多态取代条件表达式”重构之。

      正因为有了多态，所以你会发现：”类型码的switch语句“以及”基于类型名称的if-then-else语句“在面向对象程序中很少出现。

      多态能够给我们带来很多好处。如果同一组条件表达式在程序的许多地点出现，那么使用多态的收益是最大的。

7、引入空对象（Introduce Null Object）

      Null Object模式。

8、引入断言（Introduce Assertion）

      使用断言。 

      注意，不要滥用断言。请不要使用它来检查“你认为应该为真”的条件，请只使用它来检查“一定必须为真”的条件。你应该常常问自己：如果断言所指示的约束条件不能满足，代码是否仍能正常运行？如果可以，就把断言扔掉。