JavaScript设计模式与开发实践_第二十二章_代码重构

模式和重构之间有着一种与生俱来的关系。从某种角度来看，设计模式的目的就是为许多重构行为提供目标

22.1 提炼函数

我们希望函数有着良好的命名，函数题内包含的逻辑清晰明了。如果一个函数过长，不得不加上若干注释才能让这个函数显得易读一些，那这个函数就很有重构的必要

如果在函数中有一段代码可以被独立出来，那么我们最好把这个代码放进另一个独立的函数中去

• 避免出现超大函数 - 独立出来的函数有助于代码复用
• 独立出来的函数更容易被覆写
• 独立出来的函数如果有一个良好的命名，它本身就祈祷了注释的作用

22.2 合并重复的条件片段

如果一个函数体内有一些条件分支语句，而这些条件分支语句内部散步了一些重复的代码，那么就有必要进行合并去重工作。

22.3 把条件分支语句提炼成函数

复杂的条件分支语句是导致程序难以阅读和理解的重要原因，而且容易导致一个庞大的函数。

将整个条件分支语句分离出来成为一个函数

22.4 合理使用循环

在函数题内，如果有些代码实际上负责的是一些重复性的工作，那么合理利用循环不仅可以完成同样的功能，还可以使代码量更少。

提前让函数退出代替嵌套条件分支

使用嵌套条件分支的代码：

提前退出：

22.6 传递对象参数代替过长的参数列表

有时候一个函数可能接受多个参数，而参数的数量越多，函数就越难理解和使用。
使用该函数的人首先要理解全部参数的含义，在使用的时候还要小心，以免少传了某个参数或者把两个参数搞反了位置。

22.7 尽量减少参数数量

能够在函数内部通过计算得来的数值就不要通过参数传递进来

var draw = function(width,height,square){};

传递了三个参数，但是实际上square这个参数是可以由width*height计算得来的。

var draw = function(width,height){
    var square = width * height;
};

22.8 少用三目运算符

有些人喜欢使用三目运算符来代替传统的if..else。理由是三目运算符性能高，代码量少。然而这两个理由都很难站得住脚。
三目运算符与if..else的效率之差完全可以忽略不计，在实际开发中，即使把一段代码循环一百万次，使用三目运算符和使用if..else的时间开销也是处在同一个级别里面
相比损失代码的可读性和可维护性，三目运算符节省下来的代码量也可以忽略不计。

如果条件分支逻辑简单且清晰，这无碍我们使用三目运算符
var global = typeof window !== "undefined" ? window:this;
如果条件分支逻辑非常复杂，那还是按部就班使用if..else吧。
使用if..else阅读代码相对容易，修改的时候也比修改三目运算符周围的代码更加方便

22.9 合理使用链式调用

经常使用jQuery的程序员习惯链式调用方法
如果链式调用的方法并不会造成太多阅读上的困难，也确实会省下一些字符和中间变量，但省下的字符数量同样是微不足道的。

链式调用带来的坏处就是在调试的时候非常不方便，如果我们知道一条链中有错误出现，首先要把这条链拆开才能加上一些调试log或者增加断电，这样才能定位错误出现的地方。

如果链条的结构相对稳定，后期不易发生修改，那么使用链式调用无可厚非。但如果该链条很容易发生变化，导致测试和维护困难，那么还是建议使用普通的调用方式。

22.10 分解大型类

类中的某一个方法如果实在是太大了，那么实际上完全有必要将它作为一个单独的类存在，

var Spirit = function(name){
    this.name = name ;
};
Spirit.prototype.attack = function(){

}

var Attack = function(spirit){
    this.spirit = spirit;
}
Attack.prototype.list = {}

Attack类是从Spirit中分离出来的，Spirit类通过向Attack类中传递实例相互关联。

面向对象设计鼓励将行为分布在数量合理的更小对象中。

22.11 使用return退出多重循环

在一个函数体中有一个两重循环，下面是两种退出方式

令人头晕目眩，更简单的方法是在需要种植循环的时候直接退出整个方法

当然，如此退出循环会使return后面的代码不能继续执行。

解决办法：将循环后面的代码放到return后面，如果代码比较多，就应该把它们提炼成一个单独的函数。