精华内容
下载资源
问答
  • 那么问题来了,在js开发中,如何减少if else语句的使用 代码中嵌套的if/else结构往往导致代码不美观,也不易于理解。面向过程的开发中代码有大量的IF ELSE,在java中可以用一些设计模式替换掉这些逻辑,那么在js中...

    那么问题来了,在js开发中,如何减少if else语句的使用
    代码中嵌套的if/else结构往往导致代码不美观,也不易于理解。面向过程的开发中代码有大量的IF ELSE,在java中可以用一些设计模式替换掉这些逻辑,那么在js中是否也有类似的方法用来尽可能减少代码中的if/else嵌套呢?

    有人认为:if else多就多呗,只要可读性强,维护起来方便。jQuery.fn.init里就是一堆if else判断,难道要质疑jQuery作者的水平了?
    并不是说if else多就不好,关键是看用的地方,jQuery.fn.init里除了if else判断简洁点,难道要改成switch?就算用工厂模式,还不是得做大量的if判断。

    代码整洁强迫症患者必须要来个抛砖引玉:

    1.

    if(a为真){
        a=a
    }else{
        a=b
    }
    可写成:a = a || b
    

    2.

    if(a==b){
        a=c
    }else{
        a=d
    }
    可写成:a = (a==b) ? c : d
    

    3.

    后台接口通常会返回这种数据:

    fruit: 0 // 0=苹果,1=梨子,2=桔子,3=柠檬,4=芒果...
    这时写if...else是最痛苦的。从冲哥那偷来个方法:
    
    var _f = ['苹果','梨子','桔子','柠檬','芒果'];
    shuiguo = _f[fruit];
    

    建议:
    第一步:优化if逻辑
    人们考虑的东西到时候,都会把最可能发生的情况先做好准备。优化if逻辑的时候也可以这样想:把最可能出现的条件放在前面,把最不可能出现的条件放在后面,这样程序执行时总会按照带啊名的先后顺序逐一检测所有的条件,知道发现匹配的条件才会停止继续检测。

    if的优化目标:最小化找到分支之前所判断条件体的数量。if优化的方法:将最常见的条件放在首位。

    if (i < 5) {
        // 执行一些代码
     } else if (i > 5 && i < 10) {
        // 执行一些代码
     } else {
        // 执行一些代码
     }
    

    例如上面这个例子,只有在i值经常出现小于5的时候是最优化的。如果i值经常大于或者等于10的话,那么在进入正确的分支之前,就必须两次运算条件体,导致表达式的平均运算时间增加。if中的条件体应该总是按照从最大概率到最小概率排列,以保证理论速度最快。

    第二步:尽量少使用else
    如果在函数中,可以使用 if + return,先判断错误条件,然后立马结束函数,防止进入 else 分支。

    举个简单的例子,后端返回数据,前端根据状态进行不同操作

    $.ajax().done(function (res) {
        if (res.state === 'SUCCESS') {
            //TODO
        } else if (res.state === 'FAIL') {
            //TODO
        } else {
            //TODO
        }
    });
    

    这里用if else不挺好的么,有啥问题么?不过我个人倾向于switch。

    解决方法:

    1. switch/case

    switch和if else在性能上是没有什么区别的,主要还是根据需求进行分析和选择。

    如果条件较小的话选用if else比较合适。

    相反,条件数量较大的话,就建议选用switch。

    一般来说,if else适用于两个离散的值或者不同的值域。如果判断多个离散值,使用switch更加合适。

    在大多数的情况下switch比if else运行的更加快。

    在大多数情况下,switch的性能不会比if else低。switch的确在实质上跟if else if 完全一样的效果,不过在很多情况下,使用switch要比if else方便不少

    比如经典的值等分支,匹配一些状态常量的时候,比if else结构方便许多,不用反复写xx == yy

    $.ajax().done(function (res) {
        switch (res.state) {
            case 'SUCCESS':
                //TODO
                break;
            case 'FAIL':
                //TODO
                break;
            default :
                //TODO
        }
    });
    

    注意:千万不要忘记在每一个case语句后面放一个break语句。也可以放一个return或者throw。case语句匹配expression是用=而不是

    2.hash 表

    if (key == "Apple") {
        val = "Jobs";
    } else if (key == "microsoft"){
        val = "Gates";
    } else if (key == "Google"){
        val = "Larry";
    } 
    这个也可以用 switch case 解决,不过推荐的方法是 hash 表:
    
    var ceos = {"Apple":"Jobs", "microsoft":"Gates", "Google":"Larry"};
    val = ceos[key];
    

    3.重构,用 OO 里面的继承或者组合

    1.如果是狗,则汪汪
    2.如果是猫,则喵喵
    3.如果是羊,则咩咩
    4.如果是鸭,则嘎嘎
    可以重构一下,改成 OO。

    *定义类: 动物(或者接口)
    *定义方法:叫
    *定义子类:狗、猫、羊、鸭
    *重写方法 ---- 叫
    也就是说将同的判断按照功能,写成函数,这样也便于阅读

    比如我有一个方法根据类型获取名称,用if else会这样

    function getName(type) {
        if (type === 'monkey') {
            return 'monkey name';
        } else if (type === 'cat') {
            return 'cat name';
        } else {
            return 'dog name';
        }
    }
    

    如果写成函数,改成下面的会更好

    function getName(type) {
        var data = {
            monkey: 'monkey name',
            cat: 'cat name',
            dog: 'dog name'
        }
    
        return data[type] ? data[type] : data['dog'];
    }
    

    硬要把设计模式添加到JS里不是不可以,但是要看情况。生搬硬套过来的东西然并卵啊。
    写代码记住三个字即可,短简易。代码短,读起来简单,维护容易,如果在性能和代码长度上二选一,我肯定选代码短,性能不行,加台服务器就是了。而冗长的代码并不是加个程序员就能搞定的。

    保持着这个心态写代码,写出的东西离设计模式也不会差太多了。

    多说一句:存在必有其价值,不能说if else多了就不好,凡事无绝对,适合A的未必就适合B,每个东西都有其实现的场景。同理改写设计模式未必就是最棒的,听起来高大上点而已。

    展开全文
  • 那么问题来了,在js开发中,如何减少if else语句的使用 代码中嵌套的if/else结构往往导致代码不美观,也不易于理解。面向过程的开发中代码有大量的IF ELSE,在java中可以用一些设计模式替换掉这些逻辑,那么在js中...
        

    那么问题来了,在js开发中,如何减少if else语句的使用

    代码中嵌套的if/else结构往往导致代码不美观,也不易于理解。面向过程的开发中代码有大量的IF ELSE,在java中可以用一些设计模式替换掉这些逻辑,那么在js中是否也有类似的方法用来尽可能减少代码中的if/else嵌套呢?

    有人认为:if else多就多呗,只要可读性强,维护起来方便。jQuery.fn.init里就是一堆if else判断,难道要质疑jQuery作者的水平了?
    并不是说if else多就不好,关键是看用的地方,jQuery.fn.init里除了if else判断简洁点,难道要改成switch?就算用工厂模式,还不是得做大量的if判断。

    代码整洁强迫症患者必须要来个抛砖引玉:

    1.

    if(a为真){
        a=a
    }else{
        a=b
    }
    

    可写成:a = a || b

    2.

    if(a==b){
        a=c
    }else{
        a=d
    }
    

    可写成:a = (a==b) ? c : d

    3.

    后台接口通常会返回这种数据:
    fruit: 0 // 0=苹果,1=梨子,2=桔子,3=柠檬,4=芒果...
    这时写if...else是最痛苦的。从冲哥那偷来个方法:

    var _f = ['苹果','梨子','桔子','柠檬','芒果'];
    shuiguo = _f[fruit];
    

    建议:

    第一步:优化if逻辑

    人们考虑的东西到时候,都会把最可能发生的情况先做好准备。优化if逻辑的时候也可以这样想:把最可能出现的条件放在前面,把最不可能出现的条件放在后面,这样程序执行时总会按照带啊名的先后顺序逐一检测所有的条件,知道发现匹配的条件才会停止继续检测。

    if的优化目标:最小化找到分支之前所判断条件体的数量。if优化的方法:将最常见的条件放在首位。

    if (i < 5) {
        // 执行一些代码
     } else if (i > 5 && i < 10) {
        // 执行一些代码
     } else {
        // 执行一些代码
     }
    

    例如上面这个例子,只有在i值经常出现小于5的时候是最优化的。如果i值经常大于或者等于10的话,那么在进入正确的分支之前,就必须两次运算条件体,导致表达式的平均运算时间增加。if中的条件体应该总是按照从最大概率到最小概率排列,以保证理论速度最快。

    第二步:尽量少使用else

    如果在函数中,可以使用 if + return,先判断错误条件,然后立马结束函数,防止进入 else 分支。

    举个简单的例子,后端返回数据,前端根据状态进行不同操作

    $.ajax().done(function (res) {
        if (res.state === 'SUCCESS') {
            //TODO
        } else if (res.state === 'FAIL') {
            //TODO
        } else {
            //TODO
        }
    });
    

    这里用if else不挺好的么,有啥问题么?不过我个人倾向于switch。

    解决方法:

    1. switch/case

    switch和if else在性能上是没有什么区别的,主要还是根据需求进行分析和选择。

    • 如果条件较小的话选用if else比较合适。

    • 相反,条件数量较大的话,就建议选用switch。

    一般来说,if else适用于两个离散的值或者不同的值域。如果判断多个离散值,使用switch更加合适。

    在大多数的情况下switch比if else运行的更加快。

    在大多数情况下,switch的性能不会比if else低。switch的确在实质上跟if else if 完全一样的效果,不过在很多情况下,使用switch要比if else方便不少

    比如经典的值等分支,匹配一些状态常量的时候,比if else结构方便许多,不用反复写xx == yy

    $.ajax().done(function (res) {
        switch (res.state) {
            case 'SUCCESS':
                //TODO
                break;
            case 'FAIL':
                //TODO
                break;
            default :
                //TODO
        }
    });
    

    注意:千万不要忘记在每一个case语句后面放一个break语句。也可以放一个return或者throw。case语句匹配expression是用===而不是==。

    2.hash 表

    if (key == "Apple") {
        val = "Jobs";
    } else if (key == "microsoft"){
        val = "Gates";
    } else if (key == "Google"){
        val = "Larry";
    } 
    

    这个也可以用 switch case 解决,不过推荐的方法是 hash 表:

    var ceos = {"Apple":"Jobs", "microsoft":"Gates", "Google":"Larry"};
    val = ceos[key];
    

    3.重构,用 OO 里面的继承或者组合

    1.如果是狗,则汪汪
    2.如果是猫,则喵喵
    3.如果是羊,则咩咩
    4.如果是鸭,则嘎嘎
    

    可以重构一下,改成 OO。

    *定义类: 动物(或者接口)
    *定义方法:叫
    *定义子类:狗、猫、羊、鸭
    *重写方法 ----  叫
    

    也就是说将同的判断按照功能,写成函数,这样也便于阅读

    比如我有一个方法根据类型获取名称,用if else会这样

    function getName(type) {
        if (type === 'monkey') {
            return 'monkey name';
        } else if (type === 'cat') {
            return 'cat name';
        } else {
            return 'dog name';
        }
    }
    

    如果写成函数,改成下面的会更好

    function getName(type) {
        var data = {
            monkey: 'monkey name',
            cat: 'cat name',
            dog: 'dog name'
        }
    
        return data[type] ? data[type] : data['dog'];
    }
    

    硬要把设计模式添加到JS里不是不可以,但是要看情况。生搬硬套过来的东西然并卵啊。
    写代码记住三个字即可,短简易。代码短,读起来简单,维护容易,如果在性能和代码长度上二选一,我肯定选代码短,性能不行,加台服务器就是了。而冗长的代码并不是加个程序员就能搞定的。

    保持着这个心态写代码,写出的东西离设计模式也不会差太多了。

    多说一句:存在必有其价值,不能说if else多了就不好,凡事无绝对,适合A的未必就适合B,每个东西都有其实现的场景。同理改写设计模式未必就是最棒的,听起来高大上点而已。

    展开全文
  • 如何在代码中减少if else语句的使用

    千次阅读 2016-06-03 19:37:36
    面向过程的开发中代码有大量的if else,在java中可以用一些设计模式替换掉这些逻辑,那么在js中是否也有类似的方法用来尽可能减少代码中的if/else嵌套呢?有人认为:if else多就多呗,只要可读性强,维护起来方便。...

    前言

    代码中嵌套的if/else结构往往导致代码不美观,也不易于理解。面向过程的开发中代码有大量的if else,在java中可以用一些设计模式替换掉这些逻辑,那么在js中是否也有类似的方法用来尽可能减少代码中的if/else嵌套呢?

    有人认为:if else多就多呗,只要可读性强,维护起来方便。jQuery.fn.init里就是一堆if else判断,难道要质疑jQuery作者的水平了?

    并不是说if else多就不好,关键是看用的地方,jQuery.fn.init里除了if else判断简洁点,难道要改成switch?就算用工厂模式,还不是得做大量的if判断。

    常用方法

    代码整洁强迫症患者必须要来个抛砖引玉:

    1. 使用||或
    if(a为真){
        a=a
    }else{
        a=b
    }
    if(a为真){
        a=a
    }else{
        a=b
    }
    可写成:a = a || b
    1. 使用三元表达式
    if(a==b){
        a=c
    }else{
        a=d
    }
    
    if(a==b){
        a=c
    }else{
        a=d
    }
    可写成:a = (a==b) ? c : d
    1. 结合数组

    后台接口通常会返回这种数据:

    fruit: 0 // 0=苹果,1=梨子,2=桔子,3=柠檬,4=芒果…

    这时写if…else是最痛苦的。从冲哥那偷来个方法:

    var _f = [‘苹果’,’梨子’,’桔子’,’柠檬’,’芒果’];
    shuiguo = _f[fruit];
    var _f = [‘苹果’,’梨子’,’桔子’,’柠檬’,’芒果’];
    shuiguo = _f[fruit];
    建议

    第一步:优化if逻辑

    人们考虑的东西到时候,都会把最可能发生的情况先做好准备。优化if逻辑的时候也可以这样想:把最可能出现的条件放在前面,把最不可能出现的条件放在后面,这样程序执行时总会按照带啊名的先后顺序逐一检测所有的条件,知道发现匹配的条件才会停止继续检测。

    if的优化目标:最小化找到分支之前所判断条件体的数量。if优化的方法:将最常见的条件放在首位。

    if (i < 5) {
    // 执行一些代码
    } else if (i > 5 && i < 10) {
    // 执行一些代码
    } else {
    // 执行一些代码
    }

    if (i < 5) {
    // 执行一些代码
    } else if (i > 5 && i < 10) {
    // 执行一些代码
    } else {
    // 执行一些代码
    }
    例如上面这个例子,只有在i值经常出现小于5的时候是最优化的。如果i值经常大于或者等于10的话,那么在进入正确的分支之前,就必须两次运算条件体,导致表达式的平均运算时间增加。if中的条件体应该总是按照从最大概率到最小概率排列,以保证理论速度最快。

    第二步:尽量少使用else

    如果在函数中,可以使用 if + return,先判断错误条件,然后立马结束函数,防止进入 else 分支。

    举个简单的例子,后端返回数据,前端根据状态进行不同操作

    $.ajax().done(function (res) {
    if (res.state === ‘SUCCESS’) {
    //TODO
    } else if (res.state === ‘FAIL’) {
    //TODO
    } else {
    //TODO
    }
    });

    $.ajax().done(function (res) {
    if (res.state === ‘SUCCESS’) {
    //TODO
    } else if (res.state === ‘FAIL’) {
    //TODO
    } else {
    //TODO
    }
    });
    这里用if else不挺好的么,有啥问题么?不过我个人倾向于switch。

    解决方法

    1. switch/case

    switch和if else在性能上是没有什么区别的,主要还是根据需求进行分析和选择。

    如果条件较小的话选用if else比较合适。
    相反,条件数量较大的话,就建议选用switch。
    一般来说,if else适用于两个离散的值或者不同的值域。如果判断多个离散值,使用switch更加合适。

    在大多数的情况下switch比if else运行的更加快。

    在大多数情况下,switch的性能不会比if else低。switch的确在实质上跟if else if 完全一样的效果,不过在很多情况下,使用switch要比if else方便不少

    比如经典的值等分支,匹配一些状态常量的时候,比if else结构方便许多,不用反复写xx == yy

    $.ajax().done(function (res) {
    switch (res.state) {
    case ‘SUCCESS’:
    //TODO
    break;
    case ‘FAIL’:
    //TODO
    break;
    default :
    //TODO
    }
    });

    $.ajax().done(function (res) {
    switch (res.state) {
    case ‘SUCCESS’:
    //TODO
    break;
    case ‘FAIL’:
    //TODO
    break;
    default :
    //TODO
    }
    });
    注意:千万不要忘记在每一个case语句后面放一个break语句。也可以放一个return或者throw。case语句匹配expression是用===而不是==。

    2.hash 表

    if (key == “Apple”) {
    val = “Jobs”;
    } else if (key == “microsoft”){
    val = “Gates”;
    } else if (key == “Google”){
    val = “Larry”;
    }

    if (key == “Apple”) {
    val = “Jobs”;
    } else if (key == “microsoft”){
    val = “Gates”;
    } else if (key == “Google”){
    val = “Larry”;
    }
    这个也可以用 switch case 解决,不过推荐的方法是 hash 表:

    var ceos = {“Apple”:”Jobs”, “microsoft”:”Gates”, “Google”:”Larry”};
    val = ceos[key];
    1
    2
    var ceos = {“Apple”:”Jobs”, “microsoft”:”Gates”, “Google”:”Larry”};
    val = ceos[key];
    3.重构,用 OO 里面的继承或者组合

    1.如果是狗,则汪汪
    2.如果是猫,则喵喵
    3.如果是羊,则咩咩
    4.如果是鸭,则嘎嘎

    1.如果是狗,则汪汪
    2.如果是猫,则喵喵
    3.如果是羊,则咩咩
    4.如果是鸭,则嘎嘎
    可以重构一下,改成 OO。

    *定义类: 动物(或者接口)
    *定义方法:叫
    *定义子类:狗、猫、羊、鸭
    *重写方法 —- 叫
    *定义类: 动物(或者接口)
    *定义方法:叫
    *定义子类:狗、猫、羊、鸭
    *重写方法 —- 叫
    也就是说将同的判断按照功能,写成函数,这样也便于阅读

    比如我有一个方法根据类型获取名称,用if else会这样

    function getName(type) {
    if (type === ‘monkey’) {
    return ‘monkey name’;
    } else if (type === ‘cat’) {
    return ‘cat name’;
    } else {
    return ‘dog name’;
    }
    }
    function getName(type) {
    if (type === ‘monkey’) {
    return ‘monkey name’;
    } else if (type === ‘cat’) {
    return ‘cat name’;
    } else {
    return ‘dog name’;
    }
    }
    如果写成函数,改成下面的会更好

    function getName(type) {
    var data = {
    monkey: ‘monkey name’,
    cat: ‘cat name’,
    dog: ‘dog name’
    }

    return data[type] ? data[type] : data['dog'];
    

    }
    function getName(type) {
    var data = {
    monkey: ‘monkey name’,
    cat: ‘cat name’,
    dog: ‘dog name’
    }

    return data[type] ? data[type] : data['dog'];
    

    }
    硬要把设计模式添加到JS里不是不可以,但是要看情况。生搬硬套过来的东西然并卵啊。

    写代码记住三个字即可,短简易。代码短,读起来简单,维护容易,如果在性能和代码长度上二选一,我肯定选代码短,性能不行,加台服务器就是了。而冗长的代码并不是加个程序员就能搞定的。

    保持着这个心态写代码,写出的东西离设计模式也不会差太多了。

    多说一句:存在必有其价值,不能说if else多了就不好,凡事无绝对,适合A的未必就适合B,每个东西都有其实现的场景。同理改写设计模式未必就是最棒的,听起来高大上点而已。
    转载:轩枫阁

    展开全文
  • 首先我个人不是不提倡写if-else语句 , 不得不说 , 很多时候 , 在写某些逻辑 使用if-else 去做判断 , 代码看起来还是十分直观的 , 但是如果滥用if-else , 形成多层嵌套或者形成, 其中每个case 还包含了大量的逻辑 , ...

    前言

    前段时间在阅读别人所写的代码的时候 , 发现其中一些业务相关的方法体内 , 出现了比较多的if-else语句多层嵌套的情况 . 首先我个人不是不提倡写if-else语句 , 不得不说 , 很多时候 , 在写某些逻辑 使用if-else 去做判断 , 代码看起来还是十分直观的 , 但是如果滥用if-else , 形成多层嵌套或者形成, 其中每个case 还包含了大量的逻辑 , 此时从可读性来说 , 使用if-else就有点得不偿失了 . 而且某些时候 , 可能并不需这么多的if-else , 或者是可以使用其他编码方式从而达到减少的if-else 的效果 .

    减少if-else 的使用的方式有很多 , 例如设计模式层面的策略模式或者是责任链模式 . 而这里跟大家分享一下一些个人在日常编码过程中经常用到的 , 比较简单的 、从编码习惯层面上的方式 , 去一些减少不必要if-else使用 . 由于本人只是一个小菜鸟 , 如果有写得不对的地方 , 恳请批评指正 .

    (想自学习编程的小伙伴请搜索圈T社区,更多行业相关资讯更有行业相关免费视频教程。完全免费哦!)

    一些减少if-else的编码方式

    方式一 : 提前return

    首先展示一段代码示例 :

    if (condition1) {
        if (condition2) {
            return getSomething();
        } else {
            return 0;
        }
    } else {
        return 0;
    }
    

    修改后的代码如下 :

    //这里最好对这个flag所判断的逻辑补充注释进行描述
    boolean flag = !condition1 || (condition1 && !condition2)
    if(flag) {
    	return 0;
    }
    
    if (condition1 && condition2) {
        return getSomething();
    } 
    

    如果存在已知在某些条件下 , 需要返回固定值的逻辑 , 可以将这部分逻辑抽取为一个独立的 if-else block , 并置于其他if-else block的前面 , 当符合该特定条件时 , 直接提前 return 固定值 . 这种方式最直接的效果就是降低if-else的嵌套数量 .

    方式二 : 使用三目运算符

    先上例子 , 这里以一个业务场景为例 :

    查询某条评论的图片URL列表 (如果有 , 评论的图片url列表以JSON数组字符串格式保存在评论表中)

    修改前的代码如下 :

    Comment comment = getById(commentId);
    
    if (Objects.isNull(comment)) {
        throw new RuntimeException("评论不存在或已被删除");
    }
    
    String imgListStr = comment.getImgList();
    if(StringUtils.isEmpty(imgListStr)) {
        return null;
    }
    
    return JSON.parseArray(imgListStr, String.class);
    

    修改后 :

    Comment comment = getById(commentId);
    
    if (Objects.isNull(comment)) {
        throw new RuntimeException("评论不存在或已被删除");
    }
    
    String imgListStr = comment.getImgList();
    return StringUtils.isEmpty(imgListStr)) ?
        null : JSON.parseArray(imgListStr, String.class);
    

    方式三 : 使用Assert断言

    在编写业务代码过程中 , 如果需要对某些特定的条件进行判断 , 且当条件不满足时需要抛出异常 . 对于这种场景 , 除了使用上面三目运算符的示例当中的if方式 , 还可以通过使用Spring Framework 给我们提供的 Assert 工具类进行 .

    其中常用的API 有 :

    • isTrue(boolean expression , String message) :expressio == false时 , 会抛出异常 , 异常的message则为第二个入参 ;
    • void notNull(@Nullable Object object, String message) : 同上 , 当object == null 时 , 会抛出异常;
    • void notEmpty(@Nullable Collection<?> collection, String message) : 同上 , 当集合对象为null或者集合元素为空时 , 会抛出异常 .

    还有其他较多方法 , 可以直接看源码的解析 , 当然实际上isTrue() 已经够用了 , 如果需要更加的语义化 , 可以使用对应的API .
    修改前代码 :

    if (Objects.isNull(comment)) {
        throw new RuntimeException("评论不存在或已被删除");
    }
    

    修改后代码 :

     Assert.isTrue(Objects.nonNull(comment),"评论不存在或已被删除");
     Assert.notNull(comment,"评论不存在或已被删除");
    

    目前Assert工具方法只能抛出单一一种异常 java.lang.IllegalArgumentException , 如果需要自定义所抛出的异常 , 则该方式不适用 .

    方式四 : 使用Optional

    Optional是 java8 的新特性 , 相当于一个对象的容器 , 主要用于对象的null值校验 , 以及在进行校验后可链式地进行后续操作 , 如 : 抛出异常、null替换 等 .

    其中我个人比较常用的几个方法为 :

    • static Optional ofNullable(T value) : 使用Optional 将对象进行包裹 ;
    • T orElse(T other) : Optional中的对象为null时 ,返回入参的对象 .
    • T orElseGet(Supplier<? extends T> other) : Optional中的对象为null时 , 返回Supplier 提供的值 ;
    • T orElseThrow(Supplier<? extends X> exceptionSupplier) : Optional中的对象为null时 , 抛出supplier提供的自定义异常

    代码示例 :

    Message message1 = Optional.ofNullable(getById(messageId))
        .orElseThrow(() -> new RuntimeException("消息不存在!"));
    
    Message message2 = Optional.ofNullable(getById(messageId))
        .orElse(new Message());
    
    Message message3 = Optional.ofNullable(getById(messageId))
        .orElseGet(Message::new);
    

    由于我日常需要的进行空值判断的比较多的场景是从数据库查询数据完毕时 , 需要查询结果进行空值判断 . 由于我所在的公司使用的持久层框架是mybatis , 不像Spirng Boot 2.x 默认版本的JPA 那样DAO层方法支持返回值为Optional , 所以这里如果需要使用Optional , 只能手动去使用上面列举的第一个方法对查询结果进行包装 .

    当然 , IDEA其实已经给我们提供了该包装方式的热键了 , 如下图所示 :
    在这里插入图片描述

    结语

    个人的一些减少if-else 编码习惯分享就这里了 , 这几种方式里面 , 我个人觉得效果最明显的还是第一种 提前return , 很多时候 , 提前return 也可以很好降低一段代码的复杂度 .

    当然如果必须要使用大量的if-else 去控制逻辑时 , 在每个condition 标明一下注释还是一个挺不错的习惯 .

    展开全文
  • 说明 面向过程设计和面向对象设计的区别之一:是否在业务逻辑层...首先面向对象设计不是完全干掉if else语句,只是尽可能的减少冗余的if else语句,不可能完全不使用,判断是编程的基础元素,如果完全不需要使用,面
  • Java中多If else优化 (二)----卫语句

    千次阅读 2018-07-10 12:21:30
    比如一个很复杂的表达式,嵌套了好几层的if - then-else语句,转换为多个if语句,实现它的逻辑,这多条的if语句就是卫语句。 有时候条件式可能出现在嵌套n次才能真正执行,其他分支只是简单报错返回的情况,对于...
  • java编程中if else多层嵌套的优化 if else作为java编程语言不可或缺的条件语句,我们在编码...那怎样可以减少if else条件语句的嵌套?下面我们一起来聊聊 @Override public Result occUdhDupliCheck(UdhMissionApply
  • java如何消除繁琐的if else 语句? 如何无痛降低 if else 面条代码复杂度 用设计模式来代替臃肿的ifelse层层判断 你还在用if else吗? 如这段读取Excel单元格的代码,看着都烦 try { for (int j = main...
  • Java:程序开发中if else多层嵌套的优化

    万次阅读 多人点赞 2019-01-09 11:53:52
    Java:程序开发中if else多层嵌套的优化 if else作为每种编程语言都不可或缺的条件语句,我们在编程时会大量的用到。...下面将会简单谈谈如何减少if else的嵌套。 业务场景:分享一条新闻的标题,内容,链接...
  • Java的小本家2019-09-02 10:38:10 不知大家有没遇到过像...if else作为每种编程语言都不可或缺的条件语句,我们在编程时会大量的用到。但if else一般不建议嵌套超过三层,如果一段代码存在过多的if else嵌套,代...
  • Java语句

    2018-06-19 16:37:05
    卫语句就是把复杂的条件表达式拆分成多个条件表达式,比如一个很复杂的表达式,嵌套了好几层的if - then-else语句,转换为多个if语句,实现它的逻辑,这多条的if语句就是卫语句. 简单的例子如下:   [html]...
  • 3.跳出语句(循环控制语句) 4.嵌套循环 从下次开始,会尽量会直接怼上代码,减少文字 ------------------------------------------------------------------------------------------------------------------ 第...
  • 首先我个人不是不提倡写if-else语句 , 不得不说 , 很多时候 , 在写某些逻辑 使用if-else 去做判断 , 代码看起来还是十分直观的 , 但是如果滥用if-else , 形成多层嵌套或者形成, 其中每个case 还包含了大量的逻辑 , ...
  • 如何解决 if-else 过多的问题

    千次阅读 2020-07-20 00:55:17
    前言 if-else基本上是所有高级语言都有的语句Java,Python,Go,C++。可以说if-else是编程 语言种必须用的。基本上大大小小的需求都...提前return减少不必要的判断,减少If-else嵌套层次。 优化前: if(a != null){
  • Java 卫语气

    2019-08-10 09:01:17
    if-else语句,使用“卫语句 ”代替可以减少层级嵌套。 卫语句: 把复杂的条件表达式拆分成多个条件表达式,比如一个很复杂的表达式,嵌套了好几层的if - then-else语句,转换为多个if语句,实现它的逻辑,这多条的...
  • 如果直接在方法体中使用if...else...或switch...case...,那么该方法内部涉及到了许多方法的调用,后期维护十分不方便。 二:思路 将算法类似的功能使用一个单独的类进行封装,这些类由于相似性,现使其继承自
  • java6:流程控制

    2015-09-28 16:17:14
    Java 流程控制:顺序分支循环分支:if(布尔表达式){语句块}else{语句块}尽量使用肯定条件,减少else减少嵌套packageday06; importjava.util.Scanner; publicclassDemo01{ publicstatic...
  • 本周还学会了使用枚举类(enum Choice{fab,sort})的 使用及switch语句和if...else语句java中的使用。虽然java和C语言中控制流程的语句基本上相同,但是对于while语句中的条件不在可以是简单的条件,...
  • java之异常处理

    2019-10-20 15:59:56
    比如说,我们在程序开发中使用的if-else语句,其实这个就是处理异常的过程,但是这对于代码庞大的程序来说会有一些问题,比如说,代码臃肿:业务代码和异常处理代码放一起,程序员要花很大精力堵漏洞,程序员很难...
  • 第四章 流程控制与数组 ...使用ifelse语句的时候,一定要先处理包含范围更小的情况,这样能减少出错概率 2.2 switch…case…break 语句 需要注意的是,在switch语句后的expression表达式的数据类型只能是byte...
  • Java和C++中,为了减少函数调用次数,在while或者if语句的判断条件那里直接赋值比较方便。但是在Python中下面代码报错了,想请问Python是不允许这种方式的吗? class Fib(object): def __call__(self, num): L ...
  • 最正常的想法无非是在每个方法里面先判断当前对象处于什么状态,也就是说,要采用大量的if else语句或者switch语句。而这样可维护性上面就比较差,试想,如果后期我们需要增添或者减少一个状态,是不是每一处判断对....
  • java基础知识点集合

    2013-12-04 10:20:03
    建议不要省略ifelseelse if后执行体的或括号,即使执行体只有一行代码,也保留或括号会更好的可读性,而且保留花括号会减少发生错误的可能。   switch语句后面的控制表达式的数据类型只能是byte、short、char...
  • 定义:属于java的行为型模式,遵循开闭原则(对扩展开放,对修改关闭),能有效减少面向过程的if-else语句, 策略模式定义了一系列算法,并将每个算法封装起来,使他们可以相互替换,且算法的变化不会影响到使用...
  • 1.通过if-else语句进行异常的处理的机制主要有以下缺点 代码臃肿,加入了大量的异常情况判断和处理代码。 程序员把相当多的精力放在了异常处理代码上,放在了“堵漏洞”上,减少了编写业务代码的时间,必须影响...
  • 减少代码中的if else 等判断语句 实现的选择:策略模式可以提供不同的实现。 策略模式的缺点 策略模式会造成很多策略类 通讯开销很大 必须自行知道所有的实现类有何不同? 因此只有当行为类和角色行为相关的时候才...

空空如也

空空如也

1 2 3
收藏数 55
精华内容 22
关键字:

else语句java减少if

java 订阅