JavaScript设计模式之终章：重构
重构
模式和重构之间有着一种与生俱来的关系。从某种角度来看，设计模式的目的就是为许多重构行为提供目标。
1 提炼函数
如果一个方法过长，不得不加上若干注释才能让这个函数显得易读一些，那这些函数就很有必要进行重构。
如果在函数中有一段代码可以被独立出来，那我们最好把这些代码放进另外一个独立的函数中。这是一种很常见的优化工作，这样做的好处主要有以下几点。
- 避免出现超大函数。
- 独立出来的函数有助于代码复用。
- 独立出来的函数更容易被覆写。
- 独立出来的函数如果拥有一个良好的命名，它本身就起到了注释的作用。
比如一个按钮提交过程，要经历获取参数，前端校验，后端校验，后端真实执行（handleExecute()）执行几大部分，那意味着这个方法有必要提炼：
btn.addEventListenner('click',(e)=>{
let params=getParams();
const valid=new Valid(params);
if(valid.isValid().flag){
handleSubmit({
api:'...',
success:(result)=>(handleSuccess(result)),
faild:(err)=>(handleFaild(err))
});
}else{
handleFaild(valid.errMsg)
}
})不管怎么说，业务逻辑会变得很清楚。也便于跟踪问题。
2 合并重复的条件片段
假设上面的案例中handleSubmit，页面操作无论成功或失败都要触发刷新：
const handleSubmit=({api,handleSuccess,handleFaild})=>{
http.post(api,(result)=>{
if(result.errno=0){
handleSuccess();
}else{
handleFaild();
}
loadPage();
})
}在这里，loadPage就适合放到handleSubmit中。而不必分别放到handleSuccess和handleFaild中。
3 条件分支提炼为函数
在上面的valid方法中，可能包含很复杂的逻辑。如果你把它写在btn的回调中，是很恶心的。
btn.addEvevtListener('click',(e)=>{
let params=getParams();
// 校验
var flag=true;
var msg='';
if(params.a==''){
flag=false;
msg='a不得为空'
}else if(params.b==''){
flag=false;
msg='b不得为空'
}else{
// ....
}
if(flag){
//...
}
})所以需要把这块内容封装到valid对象中。
4 合理使用循环
假设有这么一段代码：
const bbb=()=>{
try{
aaa(1);
}catch(err){
try{
aaa(2);
}catch(err){
aaa(3)
}
}
}重构时可考虑这样：
const bbb=()=>{
const arr=[1,2,3]
arr.forEach((item)=>{
try{
return aaa(item)
}catch(err){}
})
}5 让函数从条件循环中及时退出
嵌套的条件分支语句绝对是代码维护者的噩梦，对于阅读代码的人来说，嵌套的if、else语句相比平铺的if、else，在阅读和理解上更加困难，有时候一个外层if分支的左括号和右括号之间相隔500米之远。用《重构》里的话说，嵌套的条件分支往往是由一些深信“每个函数只能有一个出口的”程序员写出的。
实际上，如果对函数的剩余部分不感兴趣，那就应该立即退出。引导阅读者去看一些没有用的else片段，只会妨碍他们对程序的理解。
以第三节的valid代码为例子，你可以这样封装：
const valid=(params)=>{
return !!params.aaa && !!params.bbb;
}6 传递对象参数代替过长的参数列表
笔者工作中，常看到某些大佬写的方法中，动辄十几个参数，然后来一堆魔术变量通通传进去：
getXXX(a,b,c,d,e,...,h)在使用的时候，一不小心就漏传或搞反了。
这时推荐使用对象的方式传递参数，如果这样，因为写框架的时候就一定会看重对象的命名。事实上也起到了注释的作用。
7 减少参数数量
由第六点衍生的话题就是：减少参数用量。如果调用一个函数时需要传入多个参数，那这个函数是让人望而生畏的，我们必须搞清楚这些参数代表的含义，必须小心翼翼地把它们按照顺序传入该函数。而如果一个函数不需要传入任何参数就可以使用，这种函数是深受人们喜爱的。所以工作中也应予以避免。
首先，能够相互计算出的变量，不要放到参数中。
其次你可以根据业务需求的重复度，"内置"一套配置，传入参数则部分地复写这个内置配置。
8 减少三目运算符
不推荐在嵌套中盲目使用三目运算符。（看死人）
9 减少链式操作
链式操作很好读，但是debug非常不方便。因此不推荐在不稳定的业务中调用链式操作。
10 分解大型类
假如你的valid函数特别复杂，同样需要考虑用策略模式分解成插件的形式。不要将所有逻辑写到一个方法中。