继续更新有关重构的博客，前三篇是关于类、函数和数据的重构的博客，内容还算比较充实吧。今天继续更新，本篇博客的主题是关于条件表达式的重构规则。有时候在实现比较复杂的业务逻辑时，各种条件各种嵌套。如果处理不好的话，代码看上去会非常的糟糕，而且业务逻辑看上去会非常混乱。今天就通过一些重构规则来对条件表达式进行重构，让业务逻辑更为清晰，代码更以维护和扩展。
今天博客中的代码示例依然是Swift班，在对条件表达式重构时也会提现出Swift的优雅之处，会用上Swift特有的语法及其特点，比如使用guard来取代if-let语句等。如果你的需求的业务逻辑及其复杂，那么妥善处理条件表达式尤为重要。因为对其妥善处理可以提高代码的可读性，以及提高代码的可维护性。说这么多还是来些示例来的直观，下方会根据一些Demo来着重分享一些条件表达式的部分重构规则，当然今天博客中没有涵盖所有的条件表达式的重构规则，更详细的部分请参见经典的重构书籍。
今天所分享的代码段也将会在github上进行分享，分享地址在本篇博文的后方。废话少说了，进入今天的主题。
一.Decompose Conditional(分解条件表达式)
顾名思义，分解条件表达式说白了，就是当你的条件表达式比较复杂时，你就可以对其进行拆分。一般拆分的规则为：经if后的复杂条件表达式进行提取，将其封装成函数。如果if与else语句块中的内容比较复杂，那么就将其提取，也封装成独立的函数，然后在相应的地方进行替换。
下方代码段就是我们将要重构的代码段。因为本篇博客的主题是对条件表达式的重构，所以我们要对象下方的if-else的代码块进行重构。至于下方代码片段中其他不规范以及需要重构的地方我们暂且忽略。因为我们本篇博客的主题是条件表达式的重构。接下来我们就要对下方代码片段中的条件表达式进行分析了。因为下方这段代码毕竟是一个Demo，在这儿我们可以做个假设，假设if后边的表达式比较复杂，然后在if语句块和else语句块中都有一些复杂的处理，代码看上去的大体样子如下所示。
基于对上述代码的结构的假设，接下来我们将要对其进行重构。说白了，就是让将条件表达式中的比较复杂的模块进行拆分与提取。下方代码段就是我们重构后的结构，就是将我们假设比较复杂的模块进行封装，然后在条件表达式中使用函数进行替换。这样的话，在看条件表达式就比较清晰。当然，我们这个Demo的条件表达式不够复杂，并且if和else的逻辑块所做的东西不多。不过我们可以假设一下，如果在比较复杂的情况下，这种重构手法是比较实用的。具体的大家就看重构前与重构后的区别吧。
二、Consolidate Conditional Expression(合并条件表达式)
“合并条件表达式”这条规则也是比较好理解的，因为有时候会存在这样的情况，也就是一些条件表达式后的语句体执行的代码块相同。说白了也就是不同的条件有着同样的返回结果。当然一般在你程序设计之初不会出现此问题，因为在我们设计程序时，如果不同的条件返回相同的结果，我们肯定会将其合并的。不过当你在多个版本迭代，多个需求要增加，或者在别人的代码上进行需求迭代的时候，该情况是很有可能发生的。
说这么多，也许有些抽象，那么就直接看下方需要重构的Demo了。当然，下方的Demo中，我们为了测试，其中的条件比较简单。我们假设每个条件表达式是在不同的需求迭代中或者修改bug时添加的，从而造成了下方这种情况（当然下方的情况有些夸张，这也是为了突出要合并条件的情况）。
在上述夸张的Demo中一眼就能看出来如何进行重构了（在日常开发迭代中，因为业务逻辑的复杂性或者多次迭代的原因，往往不是那么一目了然）。接下来我们就要对不同条件，但返回相同结果的部分进行合并。下方就是我们合并后的结果，重构手法就是讲不同的条件表达式使用&&或者||等布尔运算进行合并。
合并后，如果条件比较复杂，那么我们就可以使用本片博客中的第一部分使用的重构规则进行再次重构。下方代码段是进行第二次重构，就是对比较复杂的表达式进行函数封装，具体如下所示。还是那句话，Demo有些夸张，不过用来演示该重构规则也是不错的，思想就这个思想，具体在日常开发中的使用场景还是需要进行琢磨和推敲的。
三、Consolidate Duplicate Conditional Fragments(合并重复的条件片段)
第二部分合并的是条件表达式，本部分是合并的是重复的条件片段。什么叫合并重复的条件片段呢？这种情况也是一般不会在设计程序之初所出现，但是随着时间的推移，项目不断迭代更新，或者需求变更和迭代更新等等，在项目后期维护时比较容易出现重复的条件片段。在开发中是比较忌讳重复的代码的，如果出现重复的代码，那么说明你的代码应该被重构了。
下方代码片段中if与else中有着相同的语句，就是这个print语句。当然这个示例也是比较夸张的，但是足以说明问题。如果你在开发业务逻辑比较复杂的条件表达式时，要谨慎的检查一下有没有下方这种情况。也就是出现了重复的条件片段。这种情况在需求迭代或者变更中是及其容易出现的。当然下方只是我们这儿列举的一个夸张的示例。
对于这个示例而言，我们不难看出，去代码的重复化。将print语句移到条件之外。但是要学会举一反三呢，重要的是重构手法和思想。在真正的项目中，如果你要提取重复的代码段一般还要结合着其他重构手法，比如将重复的部分先提取成一个独立的模块（独立的类或者方法），然后在条件中使用，最后再去重复话。这样一来，重构的思路就比较清晰了。虽然今天的示例比较简单，但是足以表达这个思路。下方是重构后的代码。如果你对下方代码看着不爽的话，完全可以根据之前我们介绍的重构手法“使用查询来替代临时变量”，将下方的代码继续重构，在本章博客中就不做过多介绍了。
四、Remove Control Flag(移除控制标记)
“移除控制标记”这一点还是比较重要的，我平时在代码开发中有时候也会使用到标记变量，来标记一些事物的状态。使用标记变量最直观的感受就是不易维护，不易理解。因为在需求变更或者迭代中，你还得维护这标记变量。如果维护一个标记变量简单的话，那么维护多个标记变量就没这么容易了。而且在你的程序中使用标记变量时，不易理解，并且会显得逻辑混乱。当然这是我的直观感受，在写程序时，我尽量会避免使用标记变量。
当然，下方又是一个有点夸张的例子，但是该例子可以说明问题。下方代码中我们使用了一个flag标记变量，当然下方代码没有什么意义了。在平时开发中我们会使用一些标记变量来标记一个或者一些数据的状态，或者一些控件的状态，再次为了简化示例，我们就简单的引入了一个flag标记变量。下方代码不难理解，当i为20时，我们就翻转标记变量的状态，然后if中的语句块就不被执行了。
虽然下方代码片段是我写的，但是我个人看着超级的不舒服。引入的这个flag增加了代码的逻辑复杂度，让代码变得不那么直观。我个