世界那么大,景点那么多。有些时候,换个方式,换个角度,换个陪同,都会有不一样感觉与收获。写代码也亦如此。
1.前言
相信很多人有这样的经历,在项目比较忙的时候,都是先考虑实现,用当时以为最好的方式先实现方案,在项目不忙的时候,再看下以前代码,想下有什么更好的实现方案,或者优化方案。笔者也不例外,下面就和读者们分享一下自己最近在特定场合下,代替if-else,switch的解决方案。如果大家有什么想法,欢迎在评论区内留言,大家多多交流。
2.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.万一以后需求,改了比如650-750是信用优秀,750-950是信用极好。这样就整个方法要改。
2.方法存在各种神仙数字:700,650,600,550。日后的维护可能存在问题。
3.if-else太多,看着有点强迫症
所以下面用look-up表,把配数据置和业务逻辑分离的方式实现下
function showGrace(grace) {
let graceForLevel=[700,650,600,550];
let levelText=['信用极好','信用优秀','信用良好','信用中等','信用较差'];
for(let i=0;i
if(grace>=graceForLevel[i]){
return levelText[i];
}
}
//如果不存在,那么就是分数很低,返回最后一个
return levelText[levelText.length-1];
}
这样的修改,优点就是如果有需求修改,只需要修改graceForLevel,levelText。业务逻辑不需要改。
为什么这里推荐配数据置和业务逻辑分离
1.修改配置数据比业务逻辑修改成本更小,风险更低
2.配置数据来源和修改都可以很灵活
3.荐配置和业务逻辑分离,可以更快的找到需要修改的代码
如果还想灵活一些,可以封装一个稍微通用一点的look-up函数。
function showGrace(grace,level,levelForGrace) {
for(let i=0;i
if(grace>=level[i]){
return levelForGrace[i];
}
}
//如果不存在,那么就是分数很低,返回最后一个
return levelForGrace[levelForGrace.length-1];
}
let graceForLevel=[700,650,600,550];
let levelText=['信用极好','信用优秀','信用良好','信用中等','信用较差'];
使用推荐配置数据和业务逻辑分离形式开发,还有一个好处,在上面例子没体现出来&#