# 特定场景下取代if-else和switch的方案
# look-up表代替if-else
- 比如大家可能会遇到类似下面的需求：比如某平台的信用分数评级，超过700-950，就是信用极好，650-700信用优秀，600-650信用良好，550-600信用中等，350-550信用较差
function showGrace(grace) {
let _level='';
if(grace>=700){
_level='信用极好'
}
else if(grace>=650){
_level='信用优秀'
}
else if(grace>=600){
_level='信用良好'
}
else if(grace>=550){
_level='信用中等'
}
else{
_level='信用较差'
}
return _level;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
运行肯定没有问题，但是有些其它问题，比如：
万一以后需求，改了比如650-750是信用优秀，750-950是信用极好。这样就整个方法要改。
方法存在各种神仙数字：700，650，600，550。日后的维护可能存在问题。
if-else太多，看着有点强迫症
所以下面用look-up表，把配数据置和业务逻辑分离的方式实现下
function showGrace(grace) {
let graceForLevel=[700,650,600,550];
let levelText=['信用极好','信用优秀','信用良好','信用中等','信用较差'];
for(let i=0;i<graceForLevel.length;i++){
if(grace>=graceForLevel[i]){
return levelText[i];
}
}
//如果不存在，那么就是分数很低，返回最后一个
return levelText[levelText.length-1];
}
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
这样的修改，优点就是如果有需求修改，只需要修改graceForLevel，levelText。业务逻辑不需要改。
为什么这里推荐配数据置和业务逻辑分离
1. 修改配置数据比业务逻辑修改成本更小，风险更低
2. 配置数据来源和修改都可以很灵活
3. 荐配置和业务逻辑分离，可以更快的找到需要修改的代码
...未完待续