网站首页 > java教程 正文
背景描述
最近在开发项目时,我遇到了一个需要从 Hyperlink 对象中获取 link 属性的小需求。这个过程中我需要判断 Hyperlink 对象是否为 null,以防止出现空指针异常。面对这种情况,有两种常见的处理方式。一种是使用 Optional.ofNullable() 方法,另一种则是使用传统的 null 检查。这两种方法分别对应以下代码片段:
// 通过Optional.ofNullable()判断是否为null
String link = Optional.ofNullable(hyperlink)
.map(Hyperlink::getLink)
.orElse(null);
// 传统方法判断是否为null
String link = hyperlink != null ? hyperlink.getLink() : null;
那么,在这种情况下,究竟该选择哪一种方法来判断 null 值更合适呢?
代码分析
两段代码都能够实现从 Hyperlink 对象获取 link 属性,并防止出现空指针异常(NullPointerException)。我们可以从代码风格、可读性和性能多个角度进行分析。
1、使用 Optional.ofNullable()
String link = Optional.ofNullable(hyperlink)
.map(Hyperlink::getLink)
.orElse(null);
这种方法使用了 Optional.ofNullable(),结合 map() 来处理可能的 null 值。它的优势在于:
- 简洁优雅:链式调用的方式使代码更加简洁,容易理解,尤其适合团队已经熟悉并经常使用 Optional 的情况。
- 防止空指针异常:Optional 是一种现代化的编程风格,能有效避免空指针异常,特别适用于复杂的嵌套检查。
然而,Optional 的底层实现涉及包装和解包操作,在高频调用场景下可能会带来一定的性能开销。此外,如果团队中有些成员不熟悉 Optional,可能需要额外的学习成本。
2、使用传统的 null 检查
String link = hyperlink != null ? hyperlink.getLink() : null;
使用传统的三元运算符直接判断 null,这种方式的优势包括:
- 易于理解:这种写法简单直观,几乎不需要解释,特别适合那些对 Optional 不熟悉的团队成员。
- 性能更优:直接的 null 检查避免了 Optional 的包装和解包操作,性能上会稍好,尤其在对性能要求较高的场景下更具优势。
具体选择哪种方式,取决于项目的实际情况,这里提供一些建议:
- 项目要求:如果项目对性能有严格要求或团队不熟悉 Optional,那么传统的 null 检查更为合适。
- 团队代码风格:我觉得到底怎么用,还是要看项目,项目用啥咱们就用啥,不要特立独行,如果项目有硬性要求,就按照要求来;如果没有要求,就参考之前的代码风格;如果是新项目,可以使用第二段代码,这么简单易懂,写起来肯定没错。
拓展:空集合判断
在 Java 开发中,判断集合是否为空是一个非常常见的操作。通常有两种方式可以实现这一点:
- 使用原生方法:list == null || list.isEmpty()
- 使用工具类方法,如 Spring 的 CollectionUtils.isEmpty() 或 Apache Commons Lang3 的 CollectionUtils.isEmpty()
那么,究竟哪一种方法更好呢?在大多数情况下,我更建议使用第一种原生方法,原因如下:
1、更简洁直观
使用 list == null || list.isEmpty() 的写法更加直观易懂,符合大多数人的代码风格。它不依赖任何外部库,只使用了 Java 原生的集合操作方式。因此,在不需要大量使用 Spring 或其他第三方库的场景下,这种方法更加适合。
如果代码需要在不同项目中复用或发布为公共类库,选择原生方法可以减少对外部库的依赖,使代码更容易维护和移植。
2、减少依赖外部库
CollectionUtils.isEmpty() 是 Spring 或 Apache Commons Lang3 中提供的工具类方法。尽管这些工具类在大型项目中非常有用,但在某些场景下,减少对外部库的依赖显得尤为重要。
例如,在一个不广泛使用 Spring 的项目中,使用 Java 原生方法可以让代码更独立,降低对外部库的耦合度。如果项目需要减少 Spring 的依赖,选择原生方法无疑是更好的做法。
3、性能上的微小优势
从性能角度来看,list == null || list.isEmpty() 比 CollectionUtils.isEmpty() 略微有些优势。虽然这种性能差异在大多数场景下是微不足道的,但在追求极致性能的情况下,直接使用原生方法可以减少一次静态方法调用。工具类的方法内部通常也只是对 null 和 isEmpty() 进行判断,因此,直接使用原生方法更加直接和高效。
4、保持项目的一致性
在整个项目中保持一致的代码风格是至关重要的。如果你的项目广泛使用工具类,那么在所有相关代码中保持使用工具类的方法有助于代码的统一性和可维护性。
如果项目中已经大量使用了 CollectionUtils.isEmpty(),那么继续使用工具类可以保持一致性;反之,如果项目中没有依赖这些工具类,那么选择原生方法就更合适。统一的代码风格不仅有助于团队协作,还能减少后期的维护成本。
原文:https://juejin.cn/post/7409467432900427827
作者:洛小豆
猜你喜欢
- 2024-12-08 干掉复杂的工具类,国产Java工具类库 Hutool 很香!
- 2024-12-08 100个Java工具类之44:集合工具类Apache之ListUtils
- 2024-12-08 100个Java工具类之25:Java工具包Hutool(下)
- 2024-12-08 100个Java工具类之40:对象工具类Apache之ObjectUtils
- 2024-12-08 JDK8中新增的Optional工具类真的很好用哦,建议收藏
- 2024-12-08 100个Java工具类之8:java.util包下的Collections
- 2024-12-08 100个Java工具类之24:强大的Java工具包Hutool(上)
- 2024-12-08 Java常用的几种属性拷贝工具类使用总结
- 2024-12-08 开源谷歌java工具类-guava(非常实用)
- 2024-12-08 Arrays工具类常用方法【Java编程基础】
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- java反编译工具 (77)
- java反射 (57)
- java接口 (61)
- java随机数 (63)
- java7下载 (59)
- java数据结构 (61)
- java 三目运算符 (65)
- java对象转map (63)
- Java继承 (69)
- java字符串替换 (60)
- 快速排序java (59)
- java并发编程 (58)
- java api文档 (60)
- centos安装java (57)
- java调用webservice接口 (61)
- java深拷贝 (61)
- 工厂模式java (59)
- java代理模式 (59)
- java.lang (57)
- java连接mysql数据库 (67)
- java重载 (68)
- java 循环语句 (66)
- java反序列化 (58)
- java时间函数 (60)
- java是值传递还是引用传递 (62)
本文暂时没有评论,来添加一个吧(●'◡'●)