在工作中，我们时常会看见很多条件判断的逻辑，其中有层级很短，代码也很少的情况，我们都能得心应手地处理。但需求总是捉摸不定，随着判断逻辑的深入，代码的复杂性会提高，可读性就会严重下降，造成后期不可维护的状态，让人看见就头皮发麻。

如下代码

代码是临时写的，但却可以映射到平时开发的代码逻辑中。层级和代码量虽然不多，但却已经开始有上头的感觉了。每次变更需求时，我们都需要依次查看每一个分支是不是会受到影响，总需要看完整个流程才能进行修改。

设计模式之策略模式：将定义的一系列算法封装起来，封装的算法具备一定的独立性。 如同一个黑盒子，调用不需要知道其内部具体实现逻辑，只需要知道通过调用这个黑盒子可以获取想要的结果。

分析上面代码，a===1，a===2，b===3 等做的逻辑算法是毫无关系的，我们在修改某一个逻辑代码时，并不需要去关系其他算法。

第一步，使用变量封装方法，可以看：上一篇：变量封装。

第二步，将一层层的代码逻辑拆分出来，以平铺的形式展示。

大家可以清晰的看到，代码被规整并独立的展现出来了，逻辑也相互独立，在后期的某一个算法逻辑变更或者需求补充时，也能快速的修改。

总结一下：在平时开发中，当代码中的判断逻辑越来越多时，就需要警觉地开始封装和抽取一些公共代码，不要总是想着后期优化。因为你根本就没有后期，开发完后一个需求，下一个需求就在来的路上了

可以多多关注一下哦，后期会以故事的形式，结合设计模式来活灵活现地处理一些我们常见需求场景。当然其中也会穿插一些代码重构的方法，让我们不知不觉中代码质量就提上去了，也养成一些好习惯