java – 从getter返回之前检查null是不好的做法？
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了java – 从getter返回之前检查null是不好的做法？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2273字，纯文字阅读大概需要4分钟。
内容图文
我想防止getter返回null值,如下面的例子.这是一种不好的做法吗？
例1
public Integer getMinutes() {
if (minutes == null)
minutes = 0;
return minutes;
}
例2
public List getTasks() {
if (tasks == null)
tasks = new ArrayList();
return tasks;
}
解决方法:
简短的回答是：这取决于.
更具体地说,如果没有看到整个班级并理解其设计,这个问题就无法以一般方式回答.空检查是一个实现细节,适用于某些设计,但在其他设计中可能是一种气味.
一般来说,方法必须符合他们的合同,仅此而已.因此,从API设计的角度来看,这个问题是无关紧要的.您可以根据一长串现有最佳实践设计API,然后设计适合的实现.其中一个设计最佳实践是,在返回Collection时,不应将特殊情况“零元素”转换为null.也就是说,如果您的方法可以合理地返回一个空集合,它应该返回一个空集合,而不是像null这样的特殊值.这几乎总是简化客户端代码并删除整类潜在的NPE.这并不意味着你不能在内部使用null来标记“零元素”,但它暗示如果你这样做,你应该在返回时执行转换(如在你的例子中).
因此,如果你的getTasks()方法指定它总是返回一个(可能是空的)列表,那么在你的例子中使用null检查是一个合理的实现选择.在您的具体示例中,它可能不是最佳选择,因为JDK提供了类似Collections.emptyList< T>()的方法,它允许您廉价地重复使用单例空列表实例,因此您不会在内存中保存任何内容,CPU节省是值得怀疑的1.
此外,通过使用“null表示空列表”约定,您需要所有内部方法都必须检查tasks == null,否则使用getTasks()方法.在集合对象的特定情况下,我通常更喜欢使用Collections.empty *方法而不是null来表示空列表2.类似的推理适用于Integer情况,因为Integer.valueOf(0)在all compliant JVMs上返回单个对象.
除了这些特定情况之外,当然有理由使用空值检查来表示缺失或默认元素,特别是当没有好的“空”元素出现或性能很重要时.您会发现这种模式在设计良好的库(例如Java运行时和Guava)中经常使用.所以你不能说这是一个不好的做法.这是一种需要仔细评估的做法.
1使用这些Collection.empty *方法也适用于您的示例.在null的情况下,您可以考虑直接返回Collections.emptyList(),而不是按需创建新的ArrayList.这是否合适取决于整体类设计,例如,该列表是否可变.
2 Collehes.emptyList()是否比显式空检查更快实际上是一个复杂的问题.如果空列表非常罕见以至于它们通常不会在给定进程中发生,则emptyList()方法可能更快,因为当空列表的频率变为零时,其成本(当获取器)变为零.另一方面,当空列表确实发生时,它可以为使用List的所有方法创建多态调用站点：每个这样的站点都可以看到特殊的“空列表”实现和ArrayList.这可能会减慢代码速度,但很大程度上取决于内联决策.因此,与通常的性能考虑一样,确切的答案很复杂,您需要分析细节是否重要.
内容总结
以上是互联网集市为您收集整理的java – 从getter返回之前检查null是不好的做法？全部内容，希望文章能够帮你解决java – 从getter返回之前检查null是不好的做法？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。