随笔:记一次关于多重嵌套if-else/switch的优化

  最近抽空使用阿里编码规约扫描了前阵子撸的码,发现经常处于一线开发的我们,思维常被局限在局部视角内,低头走了很长夜路,回首沉思,当时自己是受了什么打击才能写出这样的代码Σ( ° △ °|||)︴汗。每次重构,都会发现很多可以优化的地方。

  需求是这样的,用户具备两种类型等级:通用会员等级 和 prime会员等级。根据该两种等级 ,及商品的价格码级别,只有会员的级别达到商品的价格码级别,才会return true(展示该商品给用户查看),否则为false。如用户为prime会员,则以prime会员级别判断,否则用通用会员级别判断。初始代码如下

 

  代码很长,一个方法超过80行,会被阿里编码规约扫出来。。说明下编码规约不提倡超过80行的原因:java文件通过虚拟机(jvm)生成.class字节码文件,每次方法被执行,jvm通过解析.class文件成机器语言执行。流程是这样:java文件->编译生成.class文件->根据.class文件解析成机器语言执行。当代码字节小于8000的方法被执行的次数足够多以后,它会被动态优化并编译成机器码执行,执行速度会大大加快,即JIT编译。而大方法则不会被JIT编译,这是主要原因(另外可能也考虑到行数过长,不利于以后的维护扩展)。

  so。。静静思考了下,优化:根据判断条件组合成key,通过map的组合key去获得判断结果的方法,超过80行的大方法重构如下:

 

转载于:https://www.cnblogs.com/Htian2016/p/11206483.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值